Elektronikus közhiteles nyilvántartások Megvalósítási tanulmány
Készítette:
Szentgáli Ádám (Stubenvoll Bt.)
1.1 Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Tartalom
I. Az EKNY adatbank, szolgáltatásai és a webes közzétételi környezet 1
Bevezető......................................................................................................................... 8 1.1 A Megvalósítási Tanulmány célja ......................................................................... 8 1.2 Az EKNy informatikai rendszerének feladatkörei................................................. 8 1.2.1 A közhiteles adatok megjelenítése................................................................. 8 1.2.2 Az egységes elérhetőséghez szükséges feldolgozások .................................. 9 1.2.3 Az adathozzáférési felület biztosítása............................................................ 9 1.2.4 Az adatkezelés biztonsága ............................................................................. 9 1.3 A dokumentum .................................................................................................... 10 1.4 Verziókezelés....................................................................................................... 11 2 A rendszer tervezésének szempontjai .......................................................................... 13 2.1 Adatbiztonság ...................................................................................................... 13 2.1.1 A közhiteles adatok integritásának biztosítása ............................................ 14 2.1.2 Az adatok illetéktelen hozzáférés elleni védelme........................................ 14 2.2 Rendelkezésre állás.............................................................................................. 15 2.3 Teljesítmény......................................................................................................... 17 3 Adatbank szolgáltatások .............................................................................................. 18 3.1 Naplózás............................................................................................................... 18 3.1.1 Célja ............................................................................................................. 18 3.1.2 Adatmódosulások......................................................................................... 19 3.1.3 Gyanús felhasználók tevékenységei ............................................................ 19 3.1.4 Bizalmas területek hozzáférései................................................................... 20 3.1.5 A naplók kiértékelése................................................................................... 20 3.2 Archiválás ............................................................................................................ 21 3.2.1 Az adattár mentése....................................................................................... 21 3.2.2 Az adattár visszaállítása............................................................................... 21 3.3 Hozzáférési jogosultságok ................................................................................... 22 3.3.1 Jogosultságok az informatikai rendszer szintjén ......................................... 23 3.3.2 Alkalmazás-szintű jogosultságok ................................................................ 24 3.3.3 Az adatlekérdezés jogosultságának vizsgálata ............................................ 25 3.3.4 Keresési jogosultság .................................................................................... 25 3.4 Az adatforgalom titkosítása ................................................................................. 26 3.5 Katasztrófa-kezelés.............................................................................................. 26 4 Adatgyűjtési szolgáltatások ......................................................................................... 28 4.1 Saját kezelésben levő adatbázis ........................................................................... 28 4.1.1 Adatfrissítés ................................................................................................. 28 4.1.2 Osztott hozzáférés több adatgazda esetén.................................................... 30 4.1.3 Adatlekérdezés............................................................................................. 30
Stubenvoll Bt
2 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
4.2 Helyi másolat – tükör – biztosítása...................................................................... 30 4.2.1 Adatfrissítés ................................................................................................. 31 4.2.2 Adatlekérdezés............................................................................................. 32 4.3 Hozzáférés programozási interfészen keresztül................................................... 32 4.4 Web-link biztosítása ............................................................................................ 32 4.5 Off-line információ biztosítása ............................................................................ 33 4.6 Statikus adatok..................................................................................................... 33 4.7 Az adatgyűjtési módok összehasonlítása............................................................. 34 5 Webes közzétételi környezet ....................................................................................... 35 5.1 Üzleti logika......................................................................................................... 35 5.1.1 Technológiai megfontolások........................................................................ 35 5.1.2 Adatkeresési funkciók.................................................................................. 36 5.1.3 Jogosultságok kezelése ................................................................................ 37 5.1.4 Adathozzáférés, lekérdezés.......................................................................... 37 5.1.5 Naplózás....................................................................................................... 38 5.1.6 Konzisztencia-vizsgálat ............................................................................... 38 5.1.7 Rendszerhiba jelzés és riasztás .................................................................... 38 5.2 Megjelenítés......................................................................................................... 39 5.2.1 Dinamikus oldalak ....................................................................................... 39 5.2.2 Statikus oldalak............................................................................................ 39 5.2.3 Tartalom alapú keresés ................................................................................ 40 5.2.4 Adminisztratív tevékenységek felületei....................................................... 40 6 Architektúra ................................................................................................................. 41 6.1 Az EKNy rendszer ............................................................................................... 41 6.1.1 Rendelkezésre állás...................................................................................... 41 6.1.2 Sebesség....................................................................................................... 41 6.1.3 Karbantarthatóság ........................................................................................ 42 6.2 Hardver ................................................................................................................ 42 6.2.1 Raid vagy SCSI winchestertárolás............................................................... 42 6.2.2 Memória kapacitás....................................................................................... 42 6.2.3 Processzorsebesség ...................................................................................... 43 6.2.4 Hálózati kapcsolat sebessége ....................................................................... 43 6.2.5 Topológiai elhatárolódás.............................................................................. 43 6.2.6 Internet biztonság......................................................................................... 43 6.3 Szoftver................................................................................................................ 43 6.3.1 Operációs rendszer....................................................................................... 44 6.3.2 Adatbázis ..................................................................................................... 44 6.3.3 Alkalmazás szerver ...................................................................................... 44 6.3.4 Web szerver ................................................................................................. 45 6.4 A javasolt architektúra áttekintése....................................................................... 45 6.5 Hardver architektúra ............................................................................................ 46 6.5.1 Adatbázis szerver és tükrözött adatbázis szerver......................................... 47 6.5.2 Kapcsolódó adatbázis szerverek .................................................................. 47 6.5.3 Alkalmazás szerver és tükrözött alkalmazás szerver................................... 47 6.5.4 Tűzfal és tükrözött tűzfal ............................................................................. 48 6.5.5 Web szerver és tükrözött Web szerver ........................................................ 48
Stubenvoll Bt
3 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
6.5.6 Internet és a felhasználók............................................................................. 48 6.6 Szoftver architektúra............................................................................................ 49 6.6.1 Adatbázis szerver......................................................................................... 50 6.6.2 Tükrözött és saját adatok ............................................................................. 50 6.6.3 Kapcsolódó adatbázis szerver...................................................................... 50 6.6.4 Alkalmazás szerver ...................................................................................... 50 6.6.5 Tűzfal ........................................................................................................... 51 6.6.6 Web szerver ................................................................................................. 51 6.6.7 Internet ......................................................................................................... 51 II. Az adatmodell 7
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
1 Bevezető 1.1
A Megvalósítási Tanulmány célja
Az Elektronikus Közhiteles Nyilvántartások projekt célja egy olyan informatikai rendszer megvalósítása, amely az egészségügyben nyilvántartott közhiteles adatokat megjeleníti, és az egészségügy és szociális szektor szereplői – ellátottak, ellátók, intézmények és irányítók – részéről a közhiteles egészségügyi adatokra irányuló legkülönbözőbb szintű és jogosultságokat igénylő lekérdezéseket egységes felületen fogadja és megválaszolja. A Megvalósítási Tanulmány célja ezen informatikai rendszer logikai tervének kidolgozása. A megvalósítandó EKNy rendszer korszerű megoldását a forrás-adatbázisok egységes adatmodellre való konverziója és az arra jogosultak számára, interneten keresztüli, szabályozott és ellenőrzött, de azonnali lekérdezési lehetőség biztosítása jelenti. Ennek érdekében a rendszer a közhiteles adatokat részben maga kezeli, részben pedig a létező közhiteles adatbázisokkal különböző – e dokumentumban részletezett – kapcsolatokat épít fel. A közvetlen cél az adatmodell, valamint a müködtetési és publikációs technikai specifikáció elkészítése, nem tévesztve szem elől a távlati célokat, többek között az egészségügyi és szociális szektor résztvevőinek az eKormányzat jelenlegi és kiterjesztett szolgáltatásaihoz való hozzásegítését.
1.2
Az EKNy informatikai rendszerének feladatkörei
Az Elektronikus Közhiteles Nyilvántartások informatikai rendszere az alábbi fő feladatköröket látja el: 1. 2. 3. 4.
A közhiteles adatok megjelenítése Az egységes elérhetőséghez szükséges feldolgozások Az adathozzáférési felület biztosítása Gondoskodás az adatkezelés biztonságáról
1.2.1 A közhiteles adatok megjelenítése Jelenleg a közhiteles egészségügyi adatok különféle adattárakban, különböző szervezetek kezelésében állnak rendelkezésre. Az EKNy rendszer aszerint, hogy az egyes adattárak milyen műszaki és jogi lehetőségeket biztosítanak, kapcsolatot létesít ezen adattárakkal, és saját adatbázist épít fel, az adatokról másolatot készít, hozzáférési csatornát nyit meg a forrás-adatokhoz vagy elérési információt nyújt a kérelmezőnek.
Stubenvoll Bt
8 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Itt jegyezzük meg, hogy a közhiteles adattárak azonosításával, feltérképezésével két további projekt foglalkozik az eEgészség program keretében: „A létező közhiteles nyilvántartások felmérése” (25. számú projekt) és „A közhiteles nyilvántartások jogi környezetének feltérképezése” (26. számú projekt). Az e projektekkel való együttműködés során kialakított jegyzék az egészségügy közhiteles adattárairól a Függelékben olvasható és e dokumentum a továbbiakban erre a jegyzékre támaszkodik.
1.2.2 Az egységes elérhetőséghez szükséges feldolgozások Megfelelő szoftver-technológia segítségével biztosítjuk, hogy a konkrét adatelérési információ elváljék az adatkezelés logikájától. Ez azt jelenti, hogy az adatok konkrét tárolása teljesen elkülönül a programozási logikától, és megfelelő keretrendszerek biztosítják az adatokhoz történő hozzáférések irányait, melynek következtében az EKNy rendszer logikájában az adatokhoz való hozzáférés csupán konfiguráció kérdése.
1.2.3 Az adathozzáférési felület biztosítása A kérelmező az adatokhoz egységes, internetes felületen keresztül férhet hozzá. Ez a felület gondoskodik a kérelmező azonosításáról, a lekérdezéshez megkívánt adatok fogadásáról, a jogosultság ellenőrzéséről illetve a válasz-adatok átadásáról. Az egységes felület nem magától értetődő igény, mivel az EKNy rendszer felhasználói igen tág spektrumot ölelnek fel. Ennek egyik végén az egyszerű állampolgár helyezkedik el, aki például informálódni kíván arról, hogy egy adott egészségügyi szolgáltató rendelkezik-e adott szakképesítéssel, egy adott kezelés elvégzésére jogosult-e. Ezt az információt minden különösebb azonosítás nélkül, az internet használata során megszokott módon és egyszerű ügykezeléssel meg kell kapja. Ugyanez a felület kezeli azonban azt a – a spektrum másik végén elhelyezkedő – transzplantációs kérelmet is, amely egy frissen elhunyt betegnek szervátültetésére vonatkozó hiteles nyilatkozatára irányul, mely szükséges ahhoz, hogy szervét egy átültetésben felhasználják. E kérelem csak akkor válaszolható meg, ha az egy előzőleg lajstromba vett intézmény regisztrált programjától, és a megfelelő jogosultságokkal rendelkező személytől érkezik, ráadásul az adatokat a személyiségi jogok fokozott védelme miatt titkosítva kell továbbítani.
1.2.4 Az adatkezelés biztonsága Ez az EKNy rendszer sarkalatos pontja, tekintettel a szóban forgó adatok kényes voltára. A biztonsági kérdéskör igen széleskörű, a hozzáférési jogosultság kifinomult kezelésétől az adatforgalom titkosításán keresztül a naplózási feladatokig számos feladatot ölel fel, melyekre a későbbi fejezetekben részletesen kitérünk. Gondoskodni kell a műszaki meghibásodás vagy rosszindulatú adatrongálás következtében fellépő adathibák korrigálásáról, az adatkonzisztencia szükség esetén való helyreállításáról, illetve az ezzel
Stubenvoll Bt
9 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
kapcsolatos tervezési elvek figyelembevételéről és eljárásrendi teendők megfogalmazásáról is. Ugyanakkor, mint arra az előző pont példájában már rámutattunk, a jogosultságok kezelése az EKNy rendszerben igen tág határok között kell történjék, tekintettel egyrészt az adatok, másrészt a kérelmezők széles spektrumára. Az adatok szempontjából figyelembe kell vegyük a •
személyes – nem személyes
jellegű adatok szerinti osztályozást – legyen példa erre az orvostörzs és a gyógyszertörzs adattárainak szembeállítása –, más szemszögből nézve azonban utalnunk kell arra, hogy nem csak a személyes adatokat kell megfelelő védettséggel kezelni, mert például a fejkvóta vagy a finanszírozási algoritmusok csak a Minisztérium és az OEP megfelelően feljogosított képviselői számára lehetnek hozzáférhetőek, azaz meg kell különböztetnünk a •
nyilvános – nem nyilvános
kategória szerinti osztályozást is.
1.3
A dokumentum
Az EKNy Megvalósítási Tanulmány elkészítése során elvégzett tevékenységek a következő termékekben öltenek testet: M1 M2 M3 M4 -
Adatmodell, Adatbank szolgáltatások, Technikai specifikáció, Üzemeltetői képzési terv.
A Tanulmány ugyanakkor e tartalmakat a logikai felépítésnek megfelelően az alábbi tagolásban jeleníti meg: I. Az EKNY adatbank, szolgáltatásai és a webes közzétételi környezet Az EKNy rendszer tervezési szempontjainak, valamint a megvalósítás strukturális modelljének ismertetése • • • •
Stubenvoll Bt
A rendszer kialakítását meghatározó igények Az EKNy adatbank szolgáltatásainak meghatározása A meglevő, egészségügyi és szociális közhiteles nyilvántartásokhoz való kapcsolódás változatai, adatgyűjtési funkciók Az EKNy webes közzétételi környezete iránti követelmények meghatározása
10 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
•
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
A fentiekből következő, a hardver és szoftver architektúrával szemben támasztott igények és ezek konzekvenciái.
II. Az adatmodell Adatmodellezési, adatbázis-tervezési ajánlás A meglevő egészségügyi és szociális közhiteles nyilvántartások adatmodellje Az EKNy rendszer javasolt közös adatmodellje Számszerűsített követelmények az adatbázissal és adatgyűjtő szolgáltatásaival szemben III. Az EKNy kialakítása A konkrét EKNy adatmodell figyelembevételével kialakított tervezési specifikáció és a műszaki-informatikai megvalósítással szemben támasztott követelmények • • • • • • • •
1.4
Az EKNy adatbank-funkcióinak ismertetése Mennyiségi és teljesítmény-követelmények Az egészségügyi és szociális szektor közhiteles nyilvántartásai kezelésének egyedi követelményei Az EKNy webes közzétételi felület funkciói A rendszer architektúra platform-független specifikációja Az adatgyűjtés HW, SW és kommunikációs eszközeinek/csatornáinak kiépítési ajánlása A jövőbeni fejlesztésre vonatkozó ajánlások EKNy info-kommunikációs technológiai képzési terv
Verziókezelés
Az EKNy Megvalósítási Tanulmány első, általános része (Az EKNY adatbank és adatgyűjtő szolgáltatásai és a webes közzétételi környezet) 2004 áprílis 13.-án előzetes kiadásra került. A projekt, valamint az eEgészség Programm csatlakozó projektjei azóta elért eredményei az 1.0 kiadásban rögzített egyes megállapításokat néhány részletet tekintve túlhaladták, ezért a jelen, immár teljes verzió első részében is végeztünk módosításokat, valamint a dokumentum struktúráját is megváltoztattuk.
Stubenvoll Bt
11 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
I. rész Az EKNy adatbank, szolgáltatásai és a webes közzétételi környezet
Tanulmányunk első részében áttekintjük mindazon szempontokat, melyeket egy, a feledatkiírás feltételeinek megfelelő informatikai rendszer eleget kell tegyen. Ennek során tekintettel leszünk mindazon követelményekre, melyek az egészségügy és szociális szféra közhiteles nyilvántartásainak egységes kezelése és hozzáférése során felmerülhetnek. Vizsgálatainkat az előre nézés igényével végezzük. Mind a funkcionalitás, mind az architektura felvázolásánál egy, a szféra egészét lefedő és valamennyi szóbajöhető nyilvántartást felölelő rendszerben gondolkozunk és eltekintünk a jelenlegi hézagos és helyenként ellentmondásos jogi szabályozás, szervezeti kötöttségek és napi gyakorlat okozta korlátoktól. Célunk ezzel az, hogy az EKNy rendszer megvalósítása kellő bölcsességgel vegye figyelembe e szempontokat akkor is, ha a mai, konkrét helyzet kivánalmaiból következő rendszerleírás – amelyet a III. részben ismertetünk – ma még egy ennél egyszerűbb architekturájú, korlátozottabb funkcionalitású EKNy tervét írja le.
Stubenvoll Bt
12 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
2 A rendszer tervezésének szempontjai Egy informatikai rendszer megtervezésénél célszerű a top-down megközelítés alkalmazása, melynek során először kívülről, a felhasználó szemszögéből nézve tekintjük a rendszert és annak minőségi jellemzőire, szakmai funkcióira, kezelésére és egyéb ’látható’ tulajdonságaira helyezzük a hangsúlyt. Csak miután ezeket tisztáztuk és rögzítettük, foglalkozunk a rendszer informatikai kérdéseivel, belső struktúrájával, melynek kialakítása és finomítása során sohasem veszítjük szem elől a korábban már rögzített igényeket. Az EKNy rendszer tervezése során ennek a logikának megfelelően először az általános minőségi és funkcionális igényeket, elvárásokat fogalmazzuk meg absztrakt szinten a 2. fejezetben, mely megállapításokat már a 3. fejezettől kezdve szem előtt tartunk. A 3. fejezet az EKNy adatbank szolgáltatásait, a 4. fejezet az adatgyűjtési szolgáltatásokat és az 5. fejezet az EKNy webes közzétételi környezete kívánt működését, funkcióit tekinti át, megfelelve az EKNy rendszer három, már röviden érintett funkcionális szintjének. Végül a 6. fejezetben az informatikai megvalósítás szemszögéből vesszük sorra megállapításainkat, lefordítjuk azokat a tervezési döntések nyelvére és mindezek összegzéseként felvázoljuk az EKNy rendszer megvalósításához javasolt – még mindig logikai szintű – hardver és szoftver architektúrát. Ebből a logikai architektúrából kiindulva, a konkrét és számszerű követelményeket figyelembe véve lépésenként fogunk azután eljutni a rendszer technikai specifikációjára, melyet a javasolt adatmodell megfogalmazását követéen ismertetünk.
2.1
Adatbiztonság
A közhiteles nyilvántartások törvény által kimondott szabályozás alá tartoznak, tartalmuk az adott kérdésben perdöntő és megkérdőjelezhetetlen, így minőségüket és integritásukat a lehető legmagasabb szinten kell biztosítani. Hozzájárul ehhez, hogy az EKNy rendszerből lekérdezhető adatok olyan személyes adatokat tartalmaznak, melyekhez történő illetéktelen hozzáférés személyiségi jogokat sérthet és komoly visszaélési lehetőségekre is módot adhat, ezért szükséges kiemelt prioritással kezelni a rendszer és a kezelt adatok biztonságát. Az egészségügyi és szociális környezet közhiteles nyilvántartásaira vonatkozó jogi szabályozásokat az eEgészség program 26. számú projektje, „A közhiteles nyilvántartások jogi környezetének feltérképezése” tárja fel, mely projekt megálapításait az EKNy rendszer tervezése során messzemenően figyelembe veszünk. Ennek megfelelően az adatbiztonság kérdését igen széles körűen értelmezzük és több szinten igyekszünk megvilágítani. A következőkben sorra vesszük az EKNy rendszerre alkalmazandó fontosabb szempontokat, hangsúlyozva, hogy a felsorolt intézkedések nem mindig sorolhatók egyértelműen egyik vagy másik csoporthoz, természetes, hogy a csoportok egymást átfedik.
Stubenvoll Bt
13 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
2.1.1 A közhiteles adatok integritásának biztosítása Ide tartozik minden olyan tervezési megfontolás, funkció és ügyrendi intézkedés, amely azt a célt szolgálja, hogy az EKNy rendszer a lekérdezésekre minden esetben helyes választ adjon. Ezek 1. A primer adattárak és az EKNy rendszer közötti forgalom védelme • Az adatforgalom titkosítása • Az adatfrissítési forgalom naplózása • Az EKNy rendszer bemenő portjainak hozzáférés elleni védelme Ezen intézkedésekkel biztosítjuk, hogy például a HBCS vagy a finanszírozási algoritmusok adatainak azEKNy adattárába történő felmásolása – tükrözése – során a másolat garantáltan pontos legyen, ne lehessen rosszindulatú beavatkozással a másolatba célzottan torzított adatokat felvinni. 2. A rendszeren belüli adatok változtatás elleni védelme • Belső adattöbbszörözés (tükrözés) • Az adatfrissítés naplózása • A frissítési információ tárolása, a változtatás visszaforgathatósága 3. Az adatsérülések felderítésére szolgáló eszközök és eljárások • Frissítés naplózása • Az adatbázis belső karbantartó funkciói, konzisztencia-ellenőrzés A 2. és 3. pontban felsorolt védelmek a tudatos adattorzítás felderítésére szolgálnak, például ha egy kívülről betört felhasználónak mégis sikerülne egy helyben tárolt adatot megváltoztatni – például egy orvos jogosultsági körét kibővíteni –, akkor ez a lépés rövid idő alatt napfényre kerüljön. 4. Az adatsérülések helyreállításának eszközei és eljárásai • Az adattár tartalmának tükör-adattárból való helyreállítása • Az adatváltoztatás visszaforgathatósága frissítési információból • Az adattartalom szelektív, ellenőrzött módosítása Amennyiben kiderült, hogy az EKNy rendszer adattartalma megsérült, ezen – a sérülés jellegének és mértékének függvényében megválasztott funkciók segítségével – ismét helyreállítható a közhiteles adattár integritása.
2.1.2 Az adatok illetéktelen hozzáférés elleni védelme Ebbe a csoportba azok az intézkedések és informatikai eljárások tartoznak, melyek segítségével biztosítható, hogy csak a törvény által megszabott jogosultsággal rendelkező kérelmező juthasson hozzá a kért EKNy adatokhoz.
Stubenvoll Bt
14 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
1. Felhasználói jogosultságok kezelése • •
Jogosultsági rendszer kialakítása és naplózása Megfelelő jogosultság-ellenőrzés a kérelmezői felületen
Mivel az EKNy rendszer webes felületén keresztül minden közhiteles adat elérhető, a felhasználói jogosultságokat szükséges központilag, egységes rendszerben kezelni és ellenőrizni. Vonatkozik ez az olyan jogosultságokra illetve lekérdezésekre is, mint pl. a TAJ adatokra irányuló kérelmezés, ahol az OEP mint adatgazda gondoskodik a jogosultságok ellenőrzéséről és az EKNy rendszer csak az ehhez szükséges felhasználói adatokat továbbítja az OEP felé, majd a lekérdezés eredményét az OEP-től a felhasználónak. 2. Hozzáférések naplózása, illetve monitorozása • •
Teljes ill. szelektív naplózás ill. monitorozás A naplók automatikus illetve szelektív kiértékelése, riasztási rendszer alkalmazása
Az EKNy rendszer egyik igen fontos üzemviteli feladata a folyamatos monitorozás, illetve a hozzáférési naplók kiértékelése, az anomáliák, gyanus hozzáférések, hozzáférési kísérletek felderítése. Ennek a tevékenységnek kellően gondos ellátása döntő fontosságú a közhiteles adatok védelmének szempontjából és az ESKI számára lényeges központi funkciót definiál az egészségügyi és szociális szektor közhiteles adatai minőségvédelmében. 3. Az Interneten keresztüli hozzáférés, illetve csatlakozás védelme • • •
Titkosított csatorna használata (SSL) Adatok védelme tűzfal segítségével Betörési kísérletek naplózása
Az SSL-technika teljes mértékben polgárjogot nyert az elmult években az Internetes kommunikáció adatvédelmében. Használata feltétlenül célszerű a közhiteles adatok illetéktelenek általi hozzáférésének megakadályozására.
2.2
Rendelkezésre állás
Az EKNy rendszer célkitűzéseiből következik, hogy az év 365 napján, napi 24 órában fogadnia kell a lekérdezéseket. A rendszerrel szemben tolerálható működési kieséseket – melyet maximális eseti és összes évi kiesés formájában, perc illetve perc/év egységben szokás specifikálni – az EKNy adatbázis kialakításánál fogjuk rögzíteni. Ennek biztosítására számos tervezési eljárás, műszaki megoldás és az üzemvitelben alkalmazandó szabály játszik szerepet:
Stubenvoll Bt
15 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
1. Az informatikai rendszer fizikai egységének védelme mind emberi, mind természeti fenyegetéssel szemben • •
Az EKNy rendszer berendezéseinek, adatcsatlakozásainak stb. megfelelő kialakítása és elhelyezése Az EKNy rendszer fizikai felügyelete
Feltétlenül javasoljuk, hogy az ESKI az EKNy rendszert megfelelően védett és felügyelt épületben illetve helyiségekben üzemeltesse. 2. Rendszertervezési- és kivitelezési megfontolások • • • •
Szünetmentes üzemeltetési környezet biztosítása Redundáns hardver- és szoftver-architektúra alkalmazása Hatékony rendszerhiba-jelzési és riasztási rendszer bevezetése Megfelelő minőségű elemek és berendezések alkalmazása
3. Hatékony karbantartás és hibajavítás elősegítése • • • •
Ügyeleti rendszerben dolgozó karbantartó szolgálat megszervezése A gyors szoftver-hibajavítás szerződéses biztosítása Hardver-javítás és szoftver-update a gyártó részéről való szerződéses biztosítása Az EKNy rendszer programrendszere fejlesztői know-how hosszú távú szerződéses biztosítása
A fenti, 2. és 3. pont olyan, többségében szervezési és szerződési pontot vet fel, melyeket az ESKI az EKNy rendszer felállítása során szem előtt kell tartson az üzemvitel biztonsága és hosszútávú biztosítása érdekében. 4. Eljárások kidolgozása, melyek lehetővé teszik a meghibásodott vagy javítás alatt álló rendszer korlátozott működését Ez részben az EKNy rendszer tervezésével, architekturájával szemben fogalmaz meg egy speciális elvárást, másrészt viszont az üzemeltetési eljárási rend kialakításakor kell gondoskodni a megfelelő procedúrák kidolgozásáról. 5. Katasztrófa-kezelés • •
A „legnagyobb tervezett katasztrófa” definiálása Katasztrófa-terv készítése, ennek keretében megfelelő adat-helyreállítási, műszaki és intézkedési terv kidolgozása
Arra az esetre, ha bekövetkeznék egy, az EKNy rendszert károsító katasztrófa, előre gondoskodni kell a kár lehetőség szerinti minimalizálásáról. Az ESKI a katasztófa-kezelés Stubenvoll Bt
16 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
szintjét megfelelő valószínűségi-gazdaságossági számítások alapján kell majd meghatározza, amelynek megfelelően kialakíthatók a megelőző intézkedések valamint a katasztrófa esetére készített intézkedési tervek.
2.3
Teljesítmény
Az EKNy rendszer az egész országra kiterjedően, központilag válaszol meg minden, a közhiteles egészségügyi adatokra vonatkozó kérést, akár szolgálati, akár állampolgári eredetű legyen is az. Ebből jelentős mennyiségű adatforgalom származik, melynek megfelelően gyors lekezeléséről gondoskodni kell, figyelembe véve a használat prognosztizálható növekedését is. A tervezésnél figyelembe veendő számszerű elvárásokat az adatmodell ismertetésénél tárgyaljuk.. Ebben a pontban az igény természeténél fogva nagyrészt informatikai jellegű követelmények fogalmazódnak meg az EKNy rendszerrel szemben, melyeket részletesen a 6. fejezetben tárgyalunk. 1. Statikus informatikai jellemzők • • •
Háttértároló kapacitás Megfelelően méretezett adatcsatornák Könnyű, akár üzem közben is elvégezhető kapacitásbővítés
2. Dinamikus informatikai jellemzők • • •
A feldolgozás és adatkezelés sebessége Lekérdezési válaszidő Keresések végrehajtásánál elfogadható válaszidő biztosítása
3. Az EKNy rendszer reagálása túlterhelési helyzetekre • • •
Stubenvoll Bt
A túlterhelési helyzet jelzése, legyen lehetőség célzott hozzáférési korlátozással a legfontosabb szolgáltatások fenntartására Túlterhelés esetén nem léphet fel sem hibás működés, sem adathiba A túlterhelés elmúltával a normális működés álljon helyre, a túlterhelésnek ne legyen maradó hatása
17 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
3 Adatbank szolgáltatások Annak érdekében, hogy az EKNy rendszer az előző fejezetben rögzített jellemzők biztosításával el tudja látni a 4. és 5. fejezetben ismertetendő funkcionális feladatokat, különféle szolgáltatásokat és segéd-funkciókat kell megvalósítson. Jelen fejezet ezeket tekinti át. Az elsődleges adatbanki szolgáltatások – mint a • • • •
különféle mélységű és kombinációjú keresések, csoportos lekérdezések, szűrések és leválogatások, valamint a különböző közhiteles nyilvántartásokban való együttes keresés lehetőségének megvalósítása,
az 5.1 pontban tárgyalt Üzleti logiká-ban jelennek meg, melyeknek az EKNy rendszerben való konkrét megvalósítását a párhuzamosan futó „A létező közhiteles nyilvántartások felmérése” (25. számú projekt) eredményei felhasználásával elkészülő, a konkrét nyilvántartások adatkezelésével foglalkozó fejezetben ismertetjük.
3.1
Naplózás
3.1.1 Célja A megváltoztatott adatok visszakereshetősége, és az esetleges illetéktelen behatolók és behatolási szándékukról tanúbizonyságot tevők megfigyelése. Ennek érdekében a naplózás az alábbi eseményeket rögzíti: • • •
Adatmódosulások Gyanús felhasználók tevékenységei Bizalmas területek hozzáférései
A naplózás megtervezése szempontjából az EKNy rendszernek két jellemzőjét kell kiemelnünk: 1. A rendszerben tárolt adatok speciálisan két kategóriát alkotnak: viszonylag kis hányadukat a rendszer maga tartja karban (ezek pontos körét „A létező közhiteles nyilvántartások felmérése” projekt fogja definiálni, de várhatóan ide tartozik majd például az orvos- vagy a gyógyszerésztörzs), vagyis a primer adatváltozásukat ebben a rendszerben kell lekezelni, melyet a 4.1 pontban tárgyaluk. Az EKNy adatainak nagyobb hányadát ugyanakkor a rendszer vagy csak másolatban tárolja, vagy csak a hozzájuk való hozzáférést biztosítja (lásd a 4.2 - 4.6 pontokat). Ebből az adatmódosulások naplózása szempontjából az következik, hogy igen jól
Stubenvoll Bt
18 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
körülhatárolt azon adatok köre, melyek egyáltalán megváltozhatnak, kivéve az igen jól definiálható tüközési, adatmásolási eseményeket. 2. Hasonlóan az adatokhoz, az adathozzáférésre jogosultak köre is markánsan két csoportot alkot. Egyrészt megjelennek a tömeges, de csak a „nem érzékeny” illetve „saját” adatok lekérdezésére jogosult állampolgári igények, másrészt viszont az „érzékeny” adatokra irányuló lekérdezések mindig igen szigorúan definiált, előre rögzített irányokból jelentkeznek, magas jpogosultsági szintű felhasználók részéről. Ezek fényében minden egyes adatkörre illetve hozzáférési csoportra célszerű a naplózási paraméterek egyedi megfontolása, amelyet az EKNy rendszer üzemeltetői felelőse kell rögzítsen.
3.1.2 Adatmódosulások Az adatok változását az EKNy rendszerben feltétlenül szemmel kell tartani. Ez olyan tevékenység, amit mindig végezni kell és soha ki nem kapcsolható. Ezáltal biztosítható, hogy ha esetleg hibásan érkező adatok elrontják az adatbázis tartalmát, akkor azok könnyen visszakereshetőek lesznek, és az esetlegesen okozott hiba javíthatóvá válik. Ha szándékos rongálás történik, akkor beazonosítható a tevékenységet elvégző. Az adatmódosulások naplózása adatbázis triggerek és History táblák segítségével javasolt. Tekintettel arra, hogy az EKNy rendszerben a tömeges hozzáférés kizárólag olvasásra engedélyezett és csak a saját kezelésben levő illetve a tükrözött adattár (lásd a 4.1. és 4.2 pontot) tartalmát frissítjük, különösen fontos az adatmódosítási tevékenységek nyomon követése.
3.1.3 Gyanús felhasználók tevékenységei Előfordulhat, hogy egyes felhasználók hozzájutottak olyan adatokhoz, melyekkel visszaélhetnek, és ezt a visszaélést meg is kísérlik. Kell lennie a rendszerben lehetőségnek arra, hogy az egyes gyanús személyeket megfigyelés alá helyezzék. Esetleg teljes csoportokat, ha kérdéses, hogy az adott csoportból ki követte el a visszaélést. Mivel az EKNy rendszert nagyon sok felhasználó használhatja, az ilyen naplózások igen költséges tevékenységek lehetnek (nagy tároló és akár nagy munkaidő kapacitást is igényelhetnek). Tehát a szelektív naplózási tevékenységnek feltétlenül konfigurálhatónak kell lennie a Webes interfészen keresztül, és a használatát csak magas jogosultsági szinttel rendelkező felhasználók kezdeményezhetik. A szelektív naplózás megvalósítása magasabb szintű feladat, a szoftver struktúrájában az üzleti logikának kell ezt a feladatot elvégezni. Gondoskodni kell az adatbázis oldalon az
Stubenvoll Bt
19 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
adatok eltárolásához szükséges, megfelelő táblaszerkezetekről, ahonnan a Webes interfészen keresztül a naplózási adatokat is le kell tudni kérdezni.
3.1.4 Bizalmas területek hozzáférései A közhiteles nyilvántartások egy része – az ESKI döntése, vagy a vonatkozó törvények előírásai alapján, melyekre vonatkozóan a párhuzamosan futó „A közhiteles nyilvántartások jogi környezetének feltérképezése” (26. számú projekt) fog útmutatást adni – igényelhet kiemelt védettséget, az ilyen területek hozzáféréseit vagy az erre irányuló hozzáférési kísérleteket minden esetben naplózni kell, függetlenül a felhasználótól. Ez a naplózási feladat igen hasonló az előző pontban említetthez és ugyanazt a műszaki felkészültséget igényli, tehát ennek a tevékenységnek feltétlenül konfigurálhatónak kell lennie a Webes interfészen keresztül, és csak magas jogosultsági szinttel rendelkező felhasználok használhatják.
3.1.5 A naplók kiértékelése Minden adattömeg annyit ér, amennyit értelmezni lehet belőle – ezen elv alapján célszerű a naplózás eredményeinek gépi úton való, statisztikai módszerekkel történő rendszeres kiértékelését megfelelő programokkal elvégezni, illetve a rendszer üzemeltetése során erről ügyrendi intézkedésekkel gondoskodni. Ezt a tevkenységet az ESKI rendeli el, felelőse és fő végrehajtója az üzemeltetéssel megbízott csoport. A kiértékelésnek alapvetően két célja van: 1. Biztonsági események felismerése, vagyis az EKNy adatokhoz való jogosulatlan hozzáférés ill. annak kísérlete, sikertelen hozzáférési kísérletek gyanus halmozódása, stb. Az EKNy projekt megvalósítása során célszerű lesz az ilyen jellegű események felismerésére célzott lépéseket tenni, melyhez ajánlott az informatikai biztonságban jártas szakértő tanácsát figyelembe venni. 2. Látogatottsági statisztikák készítése, amely elsősorban az ESKI, továbbá az adatgazdák számára nyújt hasznos információt az adattartalmak iránti érdeklődés, és ezen keresztül az EKNy rendszer informatikailag szűk keresztmetszete iránt.
Stubenvoll Bt
20 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
3.2
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Archiválás
3.2.1 Az adattár mentése A saját kezelésben tárolt adattárak (lásd a 4.1. pontot) archiválását bizonyos időközönként, a visszaállíthatóság érdekében el kell végezni. Ezt a tevékenységet fontos szabályozni, mikor, mit és hogyan kell archiválni. Tanácsos megkülönböztetni a kis és nagy mentéseket. A nagy mentés a teljes adatterületet eltárolja, ilyen mentéseket ritkábban kell elvégezni, hiszen nagy számú redundáns adat kerülne tárolásra. A kis mentéseknél, az adatmódosulási naplók alapján kisebb adatmentési csomagokat össze lehet állítani. Adatbázisok archiválására az elmúlt évtizedekben, nagy tapasztalat alapján bevált eljárásrendek alakultak ki, melyeket érdemes implementálni. Az implementálás az üzemeltetéssel megbízott csoport feladata. Foglalkozni kell az archivált adatok tárolásának biztonsági kérdéseivel is. A lementett adatokat jól elzárt, behatolástól és külső behatásoktól védett helyen kell tárolni, azokhoz csak a megfelelő jogokkal rendelkező személy férhet hozzá, de ő is csak indokolt esetben. Az ezzel kapcsolatos eljárás rendjét az ESKI rendeli el, felelőse és fő kidolgozója az üzemeltetéssel megbízott csoport.
3.2.2 Az adattár visszaállítása Minden intézkedés ellenére, melyeket az adatok biztonsága érdekében megvalósítunk, bekövetkezhetnek adathibák. Ezeknek a hibáknak, esetleg szándékos rongálásoknak a következményeit az adatok visszaállításával lehet megoldani. A visszaállításnak több lépése, kategóriája van. Az, hogy melyik visszaállítási lépést kell választani, attól függ, hogy milyen formájú, mértékű az adatok rongálódása. Az erről szóló döntést az adott helyzetben kell meghozza az üzemeltetéssel megbízott csoport ügyeletese, nagyobb káresemény gyanuja esetén annak vezetője. Ez a kérdés a katasztrófa-kezelésben is szabályozott kell legyen (lásd 3.5 pont). 1. Tükör szerver alapján A tükör szerver alapján, ahol minden adat másolásra került, az adatok egyértelműen visszaállíthatók. A megoldás nem elégséges olyankor, amikor az adatok integritása megsérült, de ez csak a tükrözést követő stádiumban derül ki. Ilyenkor a visszaállításhoz más módszert kell választani.
Stubenvoll Bt
21 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
2. Napló fájlok alapján Ha az adatok sérülésének helye egyértelműen behatárolható, akkor az adatmódosulásról vezetett naplófájl alapján beazonosítható a kiváltó ok és a sérülés formája is. Ezenkívül az is azonosítható, hogy a betöltött adatokat meddig kell visszagörgetni. Ekkor a napló fájlokon elvégzett negatív feldolgozás eredményeként (azaz az adatok visszagörgetésével, ami a beszúrásból törlést, törlésből beszúrást és módosulás esetén a korábbi állapotra való adat visszaállást eredményez), egy korábbi állapot nyerhető vissza. Ezen a korábbi állapoton a szinkronsor ismételt lefuttatásával újra előállítható az aktuális adatbázis tartalom. Abban az esetben, ha a szinkronsor tartalmazza a hibát, aminek következtében az adat integritása megsérült, a szinkronsor újra futtatása a hibás állapot ismételt előállítását eredményezi. Ilyenkor a szinkronizálásra kerülő, kívülről kapott adat extraktumokat kell újra betölteni. Ha az extraktum hordozza magában a hiba okát, akkor a kapcsolódó szervezetnek kell küldeni egy adatismétlési kérelmet, és az érintett extraktum kivételével minden egyéb adatot be kell tölteni, majd a megismételt, most már hibátlan extraktum is rátölthető. 3. Mentések alapján Ha olyan hiba következett be, ami miatt a napló fájlok alapján történő visszaléptetés már költségesebb lenne, mint az archív fájlokból történő visszaállítás, akkor teljes visszaállítást kell végezni. Ekkor az archív állományok hozzáféréséhez jogosult személy betölti a legutolsó nagy mentést, majd a nagy mentés készítése óta előállított kis mentéseket is. Ezek után, a kis mentés óta készült szinkron sorokat újrafuttatja. Abban az esetben, ha a szinkronsor tartalmazza a hibát, akkor az előző pontban leírtak alapján kell itt is eljárni és lépésenként visszamenni az utolsó, még hibátlan állapotig.
3.3
Hozzáférési jogosultságok
Minden informatikai rendszerben alapvetően jelenlévő funkció a hozzáférési jogosultságok kezelése, vagyis a rendszerhez, az abban tárolt adatokhoz való hozzáférés személyre szóló korlátozása. Mivel nem célunk közismert megoldások részleteibe itt belemenni, ezért csak összefoglaljuk a jogosultság-kezelésnek az EKNy rendszer biztonságos üzemeltetésével kapcsolatosan felmerülő legfontosabb jellemzőit. Ennek tárgyalásakor szükséges különbséget tenni az informatikai rendszer szintjén és az alkalmazás szintjén végzett jogosultság-ellenőrzés között, melyeket külön pontban tárgyalunk.
Stubenvoll Bt
22 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
3.3.1 Jogosultságok az informatikai rendszer szintjén Az informatikai rendszer szintjén a jogosultságokat az elemi jogosultságoknak az egyes felhasználókhoz való hozzárendelésével kezeljük. Mivel a rendszer igen nagyszámú elemi jogosultsággal dolgozik, ezek csoportjaiból képzett „szerepköröket” rendelünk az egyes használói csoportokhoz, mely csoportokhoz azután az egyes felhasználók tartoznak:
(Forrás: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html) Az EKNy rendszerben a jogosultságok szempontjából négy nagy szerepkört definiálhatunk (melyeken belül a gyakorlat és a célszerűség követelményei szerint további alcsoportok képezhetők): 1. Rendszerfelügyelet Ez a kis létszámú (3-5 fő), szakmai csoport kezeli a többi csoport jogosultságait és felelős azért, hogy mindenki a számára szükséges és még éppen elégséges jogosultsággal rendelkezzék. Kiváltságai közé tartozik többek között a szelektív naplózás futtatása, a felhasználók biztonsági ellenőrzése és annak biztosítása is, hogy az egyébként kiterjedt lehetőségekkel rendelkező karbantartók megbízhatósága megfelelő legyen. A rendszerfelügyeletet ellátó csoport az EKNy rendszer felelős üzemeltetője, ennek megfelelően célszerű, ha a csoportot és annak feladatait az ESKI az ESZCSM jóváhagyásával jelöli ki. 2. Karbantartás A rendszer hardver és szoftver elemeit ellenőrző, karbantartó szakemberek, akik gyakorlatilag korlátlan lehetőségekkel bírnak, és akik felelőssége a rendszer rendelkezésre állásának biztosítása. A szoftver új verzióinak betöltésére, a rendszer teljesítményének illetve túlterhelésének mérésére ugyancsak ez a csoport jogosult.
Stubenvoll Bt
23 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
3. Alkalmazás-üzemeltető Az EKNy rendszer napi üzemeltetési feladatairól gondoskodnak, végrehajtják és ellenőrzik a frissítéseket, bármilyen, a rendszer szolgáltatásaival kapcsolatos probléma esetén első szintű hibaelemzést végeznek és szükség esetén segítséget nyújtanak a felhasználóknak. 4. Kérelmező A webes felületen keresztül adatlekérdezési igénnyel jelentkező, a közhiteles nyilvántartások tartalma iránt érdeklődő személyek, akiknek csak adat-olvasási jogosultságuk van. A nyilvántartásokhoz való hozzáférés tekintetében jogaikat az adott nyilvántartáshoz kapcsolódó törvényi szabályozás tovább korlátozza, ennek ellenőrzése az alkalmazás szintjén történik meg.
3.3.2 Alkalmazás-szintű jogosultságok A közhiteles nyilvántartásokhoz való hozzáférést minden egyes nyilvántartás esetében törvény korlátozza. Ez a szabályozás többnyire szigorúan előírja a kérelmező azonosítását, mert bizonyos adatok csak bizonyos kérelmezők számára adhatók ki, mások számára az adatok vagy nem férhetők hozzá, vagy csak igen korlátozott adattartalom engedélyezett. A vonatkozó törvények feldolgozását „A közhiteles nyilvántartások jogi környezetének feltérképezése” (26. számú projekt) végzi, eredményei felhasználásra kerülnek az EKNy rendszer számára javasolt hozzáférési rendszer kidolgozásánál, amelyet a konkrét adatnyilvántartásokat tárgyaló későbbi fejezetek ismertetnek. A korlátozás a gyakorlatban abban a formában jelenik meg, hogy az egyszerű állampolgár megtekintheti a rá vonatkozó adatok nagy részét csaknem minden nyilvántartásban, egyes, arra kijelölt intézmények feljogosított képviselői viszont egy-egy szigorúan körülhatárolt adattárból széles körű információkat lekérdezhetnek. Ennek a hozzáférési korlátozásnak a kezelése azt igényli, hogy •
az állampolgár, mint kérelmező bejelentkezésekor megadjon olyan adatokat, melyek ellenőrzése csak az adattár tartalmával való célzott összevetéssel végezhető el, vagyis a jogosultság ellenőrzése nem a webes felületen, hanem az adatbázis kezelésének szintjén történik meg, másrészt
•
egy intézményi kérelmező jelentkezésekor nem elegendő a kérelmező személyét azonosítani, hanem ellenőrizni kell azt is, hogy mely intézmény informatikai rendszeréből, esetleg mely programból csatlakozik, ami hálózat-szintű azonosítást és az engedélyezett partner-intézmények informatikai rendszerparamétereinek nyilvántartását is szükségessé teszi.
Stubenvoll Bt
24 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
3.3.3 Az adatlekérdezés jogosultságának vizsgálata Egy adatlekérdezési jelentkezés jogosságának elbírálása tehát voltaképpen mind a két jogosultsági szint bevonásával történik: először az informatikai rendszer szintjén azonosításra kerül, hogy az adott kérelmező jogosult-e a rendszerrel kapcsolatba lépni, majd a megszólított alkalmazás szintjén a törvényben szabályozott jogosultság ellenőrzése történik meg. A jogosultság ellenőrzését azonban lehetőleg úgy kell megvalósítani, hogy ez a kettősség a kérelmező számára többnyire ne legyen érzékelhető. A 3.4. fejezetben ismertetett különféle adatkezelések közül egyesek mindkettőt, mások csak az egyik szintet igénylik, az adott nyilvántartás igényeihez igazítva. A jogosultsági rendszer iránti konkrét igények megfogalmazása az egyes nyilvántartások ismertetése kapcsán történik meg.
3.3.4 Keresési jogosultság Külön felhívjuk a figyelmet a keresési jogosultsáág szabályozásának kérdésére, amely a ugyancsak az alkalmazás szintjén értelmezett. Míg az adatelemek szintjén csak az írási és olvasási jogosultság két nagy csoportját kell megkülönböztetnünk (ahol a törlés és bővítés ugyancsak az írás egy-egy speciális esete), addig az alkalmazás szintjén az olvasásnak több, lényegesen eltérő szolgáltatást nyújtó változata van, melyeket az egyes adatbázisok kezelésének megtervezésénél figyelembe kell venni. Egy adatelem célzott olvasása esetén tudnunk kell az adatelem egyedi azonositóját (pl. a pecsétszám alapján megkapjuk az orvos nevét), azonban ha ilyen információnk nincs, keresési eljáráshoz kell folyamodni. A keresés a klasszikus adatfeldolgozásban annak engedélyezését igényli, hogy egy-egy jellemző minden lehetséges értékére, vagy egy behatárolt értéktartományára valamennyi adatelemet kiolvassuk. Nyilvánvaló, hogy az alkalmazás szintjén megfogalmazva ez szükségessé teszi valamennyi adatelem olvasását, vagyis lényegesen „erősebb” jogosultságot igényel. A most leírt keresés az EKNy rendszerben lényeges szerepet játszik, és a létező nyilvántartások ismertetésekor, illetve az EKNy megvalósításakor implementálni kell. A teljesség érdekében megemlítjük a szabad formátumú, az internetes keresőgépek fejlődésével elterjedt keresés lehetőségét. Ilyenkor egy vagy több kulcsszó – vagyis megadott adattartalom – előfordulását keresi meg a kereső program az adatbázisban, melyet nem kötött adatstruktúrában, hanem szabad szövegformátumban kezel. Mivel a közhiteles nyilvántartások kötött adatformátumúak, és hozzáférésüket a jog pontosan szabályozza, ezért ez a lehetőség várhatóan csak a „preklasszikus” közhiteles nyilvántartások esetén (pl. a kódrendszereknél) lesz alkalmazható.
Stubenvoll Bt
25 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
3.4
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Az adatforgalom titkosítása
Az EKNy rendszerbe, vagy abból kifelé irányuló forgalomra meg kell valósítani az adatok titkosítottan történő továbbítását. Mivel a nyilvános hálózatokon az adatcsatornák lehallgatás ellen nem megfelelően védettek, ezért az illetéktelen személyektől fontos megvédeni a cserélt információkat. Az EKNy rendszer három relációban is folytat külső adatforgalmat, ahol érzékeny adatok mozgatása történik: 1. A tükrözött adatbázis frissítésekor a primer rendszerből küldött adatok mozgatásánál, 2. Az API interfészen keresztüli hozzáférés esetén a kérelmező adatait a jogosultság ellenőrzése céljából le kell küldeni a primer adatbázisnak, amely válaszként felküldi a kért adatokat. 3. A kérelmező és az EKNy rendszer közötti adatforgalom a legsérülékenyebb, hiszen minden esetben a nyitott Interneten keresztül történik. Ezekre az adatmozgásokra feltétlenül adattitkosítást kell alkalmazni. Az utóbbi években széles körben elterjedt, 128-bites Secure Socket Layer (SSL) módszer igen hatékony, széles körben bevált, ezért célszerű az EKNy rendszerben is ezt alkalmazni.
3.5
Katasztrófa-kezelés
Míg e fejezet eddigi pontjaiban azokkal a feladatokkal foglalkoztunk, amelyek a rendszer hibátlan működésének fenntartását vannak hivatva elősegíteni, addig a katasztrófa-kezelés – a nemzetközi irodalomban szokásos szóhasználattal Disaster Recovery, tehát inkább „a katasztrófából való kilábalás” – azokkal a tevékenységekkel foglalkozik, melyeket azért kell elvégezni egy esetleges katasztrófa bekövetkezte előtt, hogy ha a katasztrófa mégis bekövetkeznék, annak káros kihatásai minél kisebbek legyenek és minél gyorsabban helyre lehessen állítani a rendszer normális működését. A témának bőséges irodalma van és elsősorban különböző a szinteken megvalósítandó létesítési, ügyrendi és üzemeltetési, és ezek között informatikai feladatokkal is foglalkozik. Az alábbiakban röviden felsoroljuk a disaster recovery körébe tartozó legfontosabb tevékenységeket. Az EKNy rendszer kialakításakor illetve üzemvitelének megszervezésekor ezek köréből kell azokat és olyan szinten bevezetni, melyek a konkrét rendszer feladata, az adatok értéke és pótolhatatlansága illetve az üzemkiesés által okozott kár mérlegelése alapján a legmegfelelőbbek és gazdaságilag indokolhatóak. Erre célszerű egy célzott elemzés kidolgozása.
Stubenvoll Bt
26 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Az első lépés az un. „legnagyobb tervezett katasztrófa” definiálása (pl. megsemmisül az épület a benne működő rendszerrel és az üzemeltető személyzettel, dokumentációval együtt). Ezután meg kell határozni, mekkora adatvesztés és üzemkiesés tolerálható, ha ez az esemény bekövetkeznék. A további tervezés ezeket kell figyelembe vegye, mert az alább felsorolt tevékenységek mindegyike költséges és a költségek a kár csökkentésére irányuló erőfeszítésekkel igen meredeken emelkednek. 1. A kitűzött célnak megfelelő informatikai megoldás kiválasztása és megvalósítása, üzemeltetése. Az informatikai megoldás létesítési-építészeti támogatása (pl. tükrözött adatbázisok alkalmazása és azok elhelyezése a primer rendszertől fizikailag minél jobban elválasztva, külön épületben, stb.). 2. Minél pontosabb és gyakoribb háttér-mentés készítése a rendszer teljes szoftverrendszeréről és a rendszerben tárolt adatokról. A primer rendszerrel lehetőleg azonos funkcionalitású, rövid idő alatt üzembe helyezhető tartalék készenlétben tartása. 3. Az adatmentések, valamint a legfrissebb rendszer- és üzemviteli dokumentáció elhelyezése igen jól védett, biztonságos helyen, a mentések tervszerű karbantartása. 4. Katasztrófa-terv készítése, amely igen részletesen tartalmazza a katasztrófa bekövetkezése esetén foganatosítandó intézkedéseket, beleértve az intézkedési jogköröket és azok továbbadási hierarchiáját. A terv oktatása, rendszeres gyakorlatok végrehajtása és azok eredményének értékelése, tanulságainak levonása. 5. A katasztrófa-terv napi szinten való frissítése, adatainak naprakészen tartása, publikálása (pl. kulcsjegyzékek, telefonlisták frissítése a munkatársak be- és kilépésekor).
Stubenvoll Bt
27 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
4 Adatgyűjtési szolgáltatások Az adatgyűjtési szolgáltatások célja, hogy a kérelmező által igényelt adatokat – a megfelelő jogosultsági vizsgálat elvégzése után – a közhiteles nyilvántartások megfelelő adattárából hozzáférhetővé tegye a kérelmező számára. A közhiteles adatok jelenleg különféle adattárakban állnak rendelkezésre. Ezek eltérő informatikai kialakításúak, különböző szervezetek kezelésében állnak de esetenként jogi szabályozásuk és ebből következően a hozzáférésükre vonatkozó ügyrend is eltérő. Annak érdekében, hogy ezt a heterogén adatkörnyezetet megfelelően kezelhessük, a közhiteles nyilvántartások adattárait az adatgyűjtés szempontjai szerint csoportosítjuk. Ebben a fejezetben az egyes csoportok jellemzőivel, a hozzáférés módjával és az ebből következő egyedi adatkezelési-funkcionális igényekkel foglalkozunk. Az egyes, konkrét adattárak illetve nyilvántartások hozzárendelése e csoportokhoz az adatnyilvántartásokat leiró későbbi fejezetekben kerülnek ismertetésre. Az adathozzáférések alábbi ismertetésével az is célunk, hogy az információval segítséget nyújtsunk a létező közhiteles nyilvántartások csoportba sorolásánál meghozandó döntésekhez.
4.1
Saját kezelésben levő adatbázis
Az adattár ebben az esetben az ESKI kezelésében, a EKNy rendszerrel közös informatikai környezetben helyezkedik el. Az adatbázis tartalmának lekérdezésére szolgáló funkciókon kívül az adatbázist, mint primer adatforrást is kezelni kell, amely a szokványos adatbázisfunkciók implementálását is szükségessé teszi.
4.1.1 Adatfrissítés Az adatok jogszabály által meghatározott ügyrend szerint kerülnek frissítésre, ide értve az adatok törlését is. A vonatkozó jogszabályokat a párhuzamosan futó „A közhiteles nyilvántartások jogi környezetének feltérképezése” projekt tárja fel. A frissítést természetesen csak a megfelelő jogosultsággal rendelkező személy végezheti. A frissítési tevékenység automatikusan naplózásra kerül, ezen kívül minden adatbázis-kezelő tárolja a frissítési információt is, ami hiba esetén lehetővé teszi a korábbi állapot konzisztens visszaállítását. Itt jegyezzük meg, hogy a nagyobb adatbiztonság és rendelkezésre állás érdekében kialakított tükrözött adatbázis-kezelés esetén a tükrözött adatállományba a rendszer automatikusan továbbítja a frissített információt, ezért az minden pillanatban pontos másolata a primer adattárnak.
Stubenvoll Bt
28 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Általános esetben az adatfrissítés különféle módokon történhet, ezek közül egy adott nyilvántartás esetén egy vagy több is alkalmazásra kerülhet. A konkrétan javasolt frissitési mód(ok) akkor választható(k) ki, ha az ESKI kezelésében karbantartott közhiteles nyilvántartásokról döntés született. A kérdésre az egységes adatmodellt és annak megvalósítását tárgyaló későbbi dokumentumben még visszatérünk. 1. Kézi, egyedi frissítés A megfelelő jogosultságokkal rendelkező kezelő közvetlen adatmódosítást végez. Ritkán használatos és általában csak előre megfelelően bejelentett munkahelyről illetve kezelő programból hajtható végre. 2. Kötegelt adatok betöltése fájlból Fontos lépés a kötegelten érkező adatok esetében eldönteni, hogy a futó, más struktúrájú rendszerekből milyen extraktumot kell készíteni, mely betölthető lesz a jelenlegi rendszerbe. Az adatok átalakítása az EKNy formátumára három helyen történhet meg: • • •
Az adatot szolgáltatónál. Már az extraktumot eleve úgy állítja elő, hogy azt az EKNy adatbázis oldalán már csak betölteni kelljen. A betöltő modulnak attól még léteznie kell, de lényegesen egyszerűbb lesz a feladata. Az EKNy adatbázisba töltés előtt. Ilyenkor az extraktumot előállító rendszerek lesznek sokkal egyszerűbbek, és az adatbázis aktualizáló lát el bonyolultabb feladatot. Az adatbázisba töltés után. Ebben az esetben az EKNy adatbázis oldalán ismerni kell az összes olyan formátumot, melyből az adatok érkezhetnek, és az adatok megfelelő helyre pakolása a betöltés után következik be.
3. Programozási interfészen keresztül (API) Ez a mód lehetővé teszi az adatbázis tartalmának távolról, más szervezet saját rendszeréből való, automatikus frissítését. A hozzáféréshez az adatbázis gazdája – jelen esetben az ESKI – biztosít megfelelő program-modult (függvényt), mely az adatokat küldeni kívánó programba kerül beépítésre. Természetesen itt különös gonddal kell a hozzáférési jogosultságokat beállítani és gondoskodni kell arról, hogy az adatküldő program csak megfelelően biztonságos rendszeren futhasson. 4. Webes interfészen keresztül A webes interfészen keresztül is lehetőséget lehet biztosítani az adatok felvitelére. Ezt abban az esetben lehet igénybe venni, ha a felhasználónak megfelelő jogosultsága van az adatok módosítására és gondoskodunk az adatforgalom megfelelő szintű védelméről (titkosítás).
Stubenvoll Bt
29 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Ilyenkor a felhasználónak be kell jelentkeznie a megfelelő felhasználó név alatt, majd miután a felhasználó elfogadásra kerül a rendszer által, már lehetősége lesz, hogy a leválogatott adatokon módosításokat végezzen. Ezt a részt, mivel ez az a felület ami leginkább ki lesz téve a támadásoknak, igen gondosan kell megvalósítani, felkészülve minden adat automatikus naplózására az adatbázis szintjén.
4.1.2 Osztott hozzáférés több adatgazda esetén Az adatbázis megfelelő kialakításával megoldható, hogy egyes entitás-csoportok különböző adatgazdák fennhatósága alatt legyenek. Ilyenkor az adatbázist fizikailag az egyik résztvevő szervezet üzemelteti, de az adatok egy része más szervezet(ek) felelőssége alá kerül, azokra az üzemeltető szervezetnek nincs módosítási joga. Az adatbázisprogramozás szintjén, tábla- és sor-szintű lock-olással biztosítandó, hogy inkonzisztencia többoldalú hozzáférés esetén se léphessen fel.
4.1.3 Adatlekérdezés Az adatok megfelelő hozzáférési jogosultság esetén lekérdezhetők. Adott esetben, jogszabályi előírás alapján a lekérdezéshez bizonyos adatkombinációk megadása is szükséges lehet, ezek meglétét természetesen megfelelően elkészített jogosultság-ellenőrző kód kell vizsgálja. A különböző jogosultságok az alkalmazás-szerverben vannak beállítva. Az alkalmazásszerver elvégzi a kérelmező jogosultságának vizsgálatát (a hitelesítést), és már a saját bejelentkezésével szólítja meg az adatbázis-szervert. Erre a célra az adatbázis-szervernek csak néhány engedélyezett felhasználóneve van, ahol el van különítve a csak olvasási hozzáférés a karbantartási hozzáférésektől, ezáltal garantáltan le lehet tiltani bizonyos hozzáférési műveleteket és területeket, ami növeli az adatbiztonságot.
4.2
Helyi másolat – tükör – biztosítása
Ebben a struktúrában a közhiteles nyilvántartás primer adatbázisa továbbra is a jelenlegi adatgazda kezelésében van, ott történik az adatok karbantartása, az érvényes jogszabályok által meghatározott keretek között. Az EKNy rendszer azonban ennek az adatbázisnak egy helyi másolatát kezeli, melyet megfelelő adatkapcsolaton keresztül szükség szerint frissít. Az EKNy rendszerhez érkező lekérdezések a megfelelő jogosultság-ellenőrzést követően ebből a másolatból („tükörből”) kerülnek kielégítésre. Itt jegyezzük meg, hogy adott esetben célszerű lehet egy forrás-adattárnak csak bizonyos részéről készíteni a „tükör”-másolatot. Ez elsősorban akkor válhat szükségessé, ha az adatgazda a közhiteles adatok mellett logikailag célszerűen kapcsolható egyéb adatokat is ebben az adatállományban kezel, s ezek nem tartanak számot a közhitelességre, sőt, az
Stubenvoll Bt
30 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
adatkezelést ellátó intézmény „saját” adatainak tekinthetők. Ez a megoldás célszerűen és biztonságosan elválasztja az intézmény saját adatait, melyhez nem kíván hozzáférést biztosítani, a közhiteles és így az EKNy rendszeren keresztül hozzáférhető adatoktól.
4.2.1 Adatfrissítés A frissítési tevékenység itt a primer adatbázisban végrehajtott változások átvezetésére szorítkozik. Az adott nyilvántartás konkrét körülményei alapján célszerű megvizsgálni, milyen mértékű és mélységű naplózási funkciókat és visszaállítási lehetőségeket kell biztosítani, tekintettel arra, hogy adatsérülés esetén mindig vissza lehet nyúlni a primer adatbázishoz. Természetesen arra is figyelemmel kell lenni, hogy egy, a teljes adatkörre kiterjedő újratöltés nagy adatbázis esetén jelentős időt vesz igénybe, mely alatt az adatkérések nem teljesíthetők. Ezért célszerű itt is az – egyéb megfontolások miatt amúgy is kialakított – helyi tükrözés funkcióinak igénybevétele, az előző esetben már tárgyalt módon. Az adatfrissítés automatizáltan történik, konkrét megvalósítását az adott nyilvántartásra jellemző változási gyakoriság függvényében kell megtervezni. Indítása történhet rendszeres időközönként vagy a primer adatbázis-kezelő által küldött trigger-jel hatására, ha egy vagy bizonyos mennyiségű adatváltozás bekövetkezett. Az adatküldés lehetőségei azonosak az előző esetben ismertetettekhez: 1. Kötegelt adatok betöltése fájlból Az adatok átalakítása az EKNy formátumára három helyen történhet meg, melyek között az adott struktúrák ismeretében előre kell dönteni: • • •
Az adatot szolgáltatónál. A küldő rendszer az extraktumot eleve úgy állítja elő, hogy azt az EKNy adatbázis oldalán már csak betölteni kelljen. Az EKNy adatbázisba töltés előtt. Ilyenkor az extraktumot előállító rendszerek lesznek sokkal egyszerűbbek, és az adatbázis aktualizáló lát el bonyolultabb feladatot. Az adatbázisba töltés után. Ebben az esetben az EKNy adatbázis oldalán ismerni kell az összes olyan formátumot, melyből az adatok érkezhetnek, és az adatok megfelelő helyre pakolása a betöltés után következik be.
2. Programozási interfészen keresztül (API) Ehhez a hozzáféréshez az EKNy rendszer biztosít megfelelő program-modult (függvényt), mely a primer adatkezelő rendszerébe beépítve közvetlenül bejuttatja az adatfrissítést a másolt állományba. Ezen a módon igen szoros szinkronizáció építhető fel, mert a primer adat frissülésekor azonnal frissítésre kerül az EKNy rendszer másolt adatállománya is.
Stubenvoll Bt
31 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
4.2.2 Adatlekérdezés Az adatok lekérdezése semmi különbséget nem mutat a 4.1.3 pontban leírtaktól. Természetesen a jogosultság kezelését ugyancsak át kell venni a primer adatkezelést ellátó rendszerből – amennyiben az táblázatvezérelt módon történik, akkor a jogosultság-adatok ugyancsak tükrözhetőek és a hitelesítést ellátó kódrészt az EKNy rendszeren „meg kell ismételni”, vagy a hozzáférést korlátozó jogszabály alapján fel kell építeni a megfelelő hozzáférési jogosultság-ellenőrzést. Amennyiben a jogszabályi előírás a lekérdezéshez bizonyos adatkombinációk megadását is előírja, mindenképpen aktív jogosultságellenőrzést kell implementálni.
4.3
Hozzáférés programozási interfészen keresztül
Különösen érzékeny adatokat tartalmazó közhiteles nyilvántartás esetén a jogszabály a hozzáférést jelentős mértékben korlátozhatja, előírva még a jogosan birtokolt adatok másolásának tilalmát is. Másrészt éppen az ilyen esetben a közhiteles nyilvántartást kezelő intézménynek az adathozzáférések fölötti őrködés törvényi felelőssége, ezért az eddig tárgyalt két hozzáférési modell csak nagy nehézségek mellett lenne implementálható. Az EKNy rendszer az egységes adatkérési felületen megjelenő igényt ebben az esetben úgy tudja kielégíteni, hogy – adott esetben egyszerűsített – jogosultsági ellenőrzés után a kérelmet annak paramétereivel együtt továbbítja a primer adatgazda rendszeréhez. A részletes, tartalomellenőrzéssel is járó jogosultság-vizsgálatot már ez a rendszer végzi el és pozitív esetben megjeleníti a kért adatot. Ezt az EKNy rendszer átveszi és szükség esetén kiegészítő adatokkal ellátva a megfelelő formátumban a webes közzétételi felületen átadja a kérelmezőnek. Ez az adatforgalom a már korábbiakban tárgyalt programozási interfész (API) technológiával valósítható meg a legcélszerűbben. További előnye a hozzáférési függvények alkalmazásának, hogy azokat az adatgazda készíti el, elfedve ezáltal az adattárában alkalmazott belső struktúrákat. Az EKNy rendszer csupán e kész függvényeket kell a program logikába beépítse, amellyel a lekérdezéseket megvalósítja. Amennyiben az adatstruktúrák a jogszabály változása következtében megváltoznak, elegendő e függvényeket a logikában lecserélni.
4.4
Web-link biztosítása
Amennyiben a kérelmező olyan közhiteles adathoz kíván hozzáférni, amely a tárgyalt három lehetőség egyikével sem érhető el, az EKNy rendszer nem fogja tudni a kért adatot biztosítani. Egy további, lazább lehetőséget nyújthatunk azonban ilyen esetben weblink(ek) biztosításával, mely vagy közvetlenül a kívánt adattárra illetve adatra mutat, vagy – az Interneten megszokott – keresési algoritmusok segítségével szélesebb kört is bevonhat a keresésbe.
Stubenvoll Bt
32 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Ez a lehetőség, és különösen a kereső-motorral és hasonló, korszerű webes eszközökkel megtámogatott hozzáférés várhatóan a kevéssé kényes adatokhoz való hozzáférésre lesz alkalmazható, és az állampolgári informálódás korszerű segédeszközeként fogja a többi, szigorúan kezelt lehetőséget kiegészíteni. Nyilvánvaló, hogy ebben az esetben az EKNy rendszer legfeljebb csak egy egyszerű jogosultság-ellenőrzést végezhet, a mélyebb biztonsági ellenőrzés, amennyiben arra szükség van, a link által megcímzett portál feladata lesz. Az ilyen kérelmezésekre válaszként adott linkeket – a nem-determinisztikus keresések eseteit nem számítva – a link által megcímzett intézmények kell biztosítsák. A link-listák karbantartása igen egyszerűen bővíthető táblázatkezeléssel valósítható meg. Hasonlóan oldható meg a webes felületen megjeleníthető, a keresés vagy lekérdezés pontosítására vagy a paraméterek megadására felszólító, célzott információt szolgáltató HTML-oldalak előkészítése is melyet a linket tulajdonló partner-intézménnyel együttműködésben kell kialakítani.
4.5
Off-line információ biztosítása
Léteznek olyan közhiteles nyilvántartások, melyek kialakítása jelenleg műszakilag nem teszi lehetővé az on-line kapcsolódást. Amennyiben egy lekérdezés ilyen adatforrásra irányul, az EKNy rendszer csak szöveges információt tud adni arról, hogy a keresett adat mely intézménynél található. Az információs felület standard kialakítású, a benne megjelenítendő tartalmakat, melyeket a vonatkozó intézmények kell biztosítsanak, táblázatokban kezeljük.
4.6
Statikus adatok
A teljesség kedvéért itt említjük meg a közhiteles nyilvántartások körébe sorolt, statikus adatokra vonatkozó lekérdezések kezelését is. Ebbe a csoportba olyan adatok, tipikusan referencia-listák kerülnek, melyek igen ritkán, évente egy-két alkalommal változnak, tartalmuk miatt nem, vagy alig igényelnek jogosultságokat, de fontos, hogy pontosan, hivatkozhatóan hozzáférhetőek legyenek. Az ilyen adatállományokat nem érdemes adatbázisban tárolni, számukra a webes megjelenítés során nem kell dinamikus lapokat összeállítani. Kezelésüket a Webes közzétételi környezet című fejezetben, a Statikus oldalak tárolása című pontban ismertetjük. .
Stubenvoll Bt
33 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
4.7
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Az adatgyűjtési módok összehasonlítása
A különböző hozzáférési mechanizmusokat az alábbi táblázatban foglaljuk össze
Közhiteles adatok közvetlen hozzáférhetősége Hozzáférési jogosultságok kezelése az EKNy rendszerben Adatok módosítása a Web interfészen keresztül Események naplózása Integritás vizsgálat
Primer adattár saját kezelésben
Tükrözött adatbázis
Hozzáférés API interfésszel
Web-link biztosítása
Off-line információ
Statikus lista
IGEN
IGEN
IGEN
IGEN
nem
IGEN
IGEN
IGEN
nem
nem
nem
IGEN
Részben
nem
nem
nem
nem
nem
IGEN
IGEN
IGEN
nem
nem
nem
IGEN
IGEN
nem
nem
nem
nem
Fontos megjegyezni, hogy az ismertetett hozzáférési módok az EKNy rendszerben alkalmazható lehetőségeket ölelik fel. Ismertetésükkel célunk a jelen tanulmányban – későbbi fejezetekben – az egyes közhiteles nyilvántartásokhoz javasolt hozzáférési módokon túlmenően, a jövőbeni fejlesztés számára is útmutatást adni.
Stubenvoll Bt
34 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
5 Webes közzétételi környezet Az EKNy rendszer felhasználói a közhiteles adatokhoz a webes felületen keresztül férhetnek hozzá, mely az ágazati portálhoz, az ESZCSM valamint az ESKI honlapjához szervesen kapcsolódik. Ez egy megszokott Internetes felület, amely azonban igen szigorúan védett tartalmakhoz csatlakozik. Ahhoz, hogy az adatokat az Interneten közzé lehessen tenni, olyan program logika szükséges, mely a jogosultságok kezelését, az adatok leválogatását, megjelenítését, és a szükséges biztonsági óvintézkedéseket is megvalósítja. Ezek a funkciók a rendszer architektúrájában két szintre bomlanak szét, az üzleti logikára és a megjelenítésre.
5.1
Üzleti logika
Az üzleti logika (amely a teljes EKNy rendszer középső szintjét jelenti), a rendszer program logikáját tartalmazza. Ez azt jelenti, hogy alapvetően minden, programozást igénylő tevékenység az üzleti logika részét képezi.
5.1.1 Technológiai megfontolások Mivel az üzleti logika az architektúra szintjén jól elkülöníthető az alsó, adattárolási és a felső, megjelenítési szinttől, ezért a rendszer fejlesztésében célszerű e szemlélet kiforrt technológiái közül az egyiket felhasználni, mely javaslatunk szerint a J2EE technológia. Mindjárt itt említjük meg, hogy bár a J2EE, mint a Java nyelv professzionális szintje, eredetileg a Sun Microsystems terméke, azonban mára már inkább tekinthető az informatikai világ széleskörűen elfogadott szabványának, melyre számos gyártó kínál megfelelő implementációt, melyek önmagukban igen kiterjedt programozási és futtatási környezetek. A J2EE technológia úgynevezett Enterprise Java Bean-eket („babokat”) tárol a J2EE konténeren belül. Ezek a babok végzik el a program fő logikáját. Minden, ezen túlmutató tevékenységet a konténer átvállal, így például a jogosultságok, a memória, a párhuzamosítás kezelését. Az EKNy rendszer szempontjából kétféle bab lényeges, a Session Bean és az Entity Bean. A Session Bean-ek program logikát tartalmaznak, más Session Bean-eket Entity Bean-eket hívhatnak meg, míg az Entity Bean-ek általában az adatbázis adattartalmának reprezentációi. Sok esetben egy Entity Bean konkrétan egy táblát szimbolizál. Ebből a babból történő adatkinyerés egyenértékű más módszerekkel való adatbázis leválogatással. Az Entity Bean-ek adattartalmának meghatározásához a J2EE technológia tartalmaz még egy EJB Query Language adatlekérdező nyelvet, ami nagyon hasonlít az SQL lekérdező Stubenvoll Bt
35 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
nyelvre. Ezzel célirányos adatlekérdezéseket lehet definiálni, mely több adattáblán keresztül is képes az szükséges adatokat összeválogatni, és egy csokorban rendelkezésre bocsátani. Ezáltal ennek sem szükséges a program logikában elhelyezkednie.
5.1.2 Adatkeresési funkciók Az EKNy rendszer legfőbb feladata, hogy a kérelmezők számára a közhiteles nyilvántartások adattáraiból a legkülönfélébb szempontok szerinti kereséseket tegyen lehetővé. Egy keresés lehet • •
determinisztikus adatbázis-lekérdezés, vagy web-tartalom keresése.
Mivel az EKNy rendszerben az adatok a 4. fejezetben tárgyaltak szerint részben közvetlenül rendelkezésre állnak, részben azonban link információ útján érhetőek el, ezért nem kizárt, hogy szükség lesz e két keresési eljárás kombinálására is. Ennek lehetőségét egy megfelelően dinamikus, táblavezérelt szoftver környezet fogja biztosítani. 1. Determinisztikus keresés Az egészségügyi és szociális szektorban tárolt közhiteles adatok alapvetően jól definiált struktúrával rendelkeznek és ennek megfelelően keresésük is a hagyományos, determinisztikus adatbázis-keresési eljárásokra épül. Ebben a logikában minden adatbáziskeresés végső soron szabányos SQL-lekérdezések véges sorozatára vezethető vissza. Az SQL felület természetesen nem jelenik meg a felhasználói felületen, funkciói a programozás szintjén a már említett J2EE technológiában létező Query Language segítségével fogalmazhatók meg. Ez a megoldás hasonlóan működik mind egyszerű, mind bonyolult, több keresési feltétellel specifikált lekérdezésekre, mivel a keresési feltételek paraméterek formájában jelennek meg az üzleti logika alsó szintjén. Ezzel az eljárással ad választ a rendszer egy saját kezelésben karbantartott adatra (például annak lekérdezésére, hogy hol van a VI. kerületben kardiológiai szakrendelés, ami egy több-paraméteres keresés az egészségügyi szolgáltatók adatbázisában) ugyanúgy, mint amikor a keresést az eredeti adatbázis felé kell továbbítania. Példa ez utóbbira mondjuk egy konkrét biztosítási jogviszony lekérdezése a TAJ adatbázisból, melyhez a feltételezett biztosított személyi adatait az EKNy rendszer tárolt eljárások meghívásával elküldi a TAJ adatbázisnak, ahol az az ottani keresési mechanizmust aktiválja. Akkor is működik ez a mechanizmus, amennyiben a keresés több közhiteles adattárban tárolt adatok kombinációjára vonatkozik. A keresésben specifikált entitásokat az EKNy rendszer dinamikus táblákban tárolja, hozzárendelve őket – az egységes adatmodellen keresztül – az eredeti közhiteles adattárak valamelyikéhez. Amikor olyan keresést aktiválunk, melynek paraméterei végső soron több adattárat szólítanak meg, akkor az üzleti
Stubenvoll Bt
36 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
logika a keresést több, párhuzamosan végrehajtott műveletre bontja fel, majd azok eredményét összekombinálva jeleníti meg a webes közzétételi felületen. 2. Webes tartalom-keresés Lehetőségünk van az EKNy adatbázisban tartalom-alapú keresésre is, amikor a kereséshez nem tudjuk egy adott entitás konkrét értékét megadni. Ilyenkor a keresés, az internetes kereső-motorok logikája szerint, web-oldalakon történik. Az EKNy adatbázis esetén ezek részben statikus oldalak (lásd 5.2.2,), melyekre ez a funkció minden további nélkül alkalmazható, részben azonban dinamikusan épülnek fel. Ebben ismét csak az üzleti logika nyújt segítséget, amely keresést indít a közhiteles adatbázisban, egyes tartalom alapján értelmesen kereshető mezőkre vonatkozóan. Hangsúlyoznunk kell azonban, hogy bár a tartalom-alapú keresésre a szükséges funkciók rendelkezésre állnak, az EKNy rendszerben, jellegénél fogva, elsősorban a determinisztikus keresés dominál. A tartalom-alapú keresésre a 5.2.3 pontban más aspektusból még visszatérünk.
5.1.3 Jogosultságok kezelése Az üzleti logikának a 3. fejezetben leírtaknak megfelelően támogatnia kell a jogosultságok kezelését. Meg kell tudnia különböztetni a jogosultságokat, a csokorba szedett jogosultságokat, azaz a szerepköröket, a felhasználókat és a felhasználói csoportokat. Lehetőséget kell tudni biztosítania arra, hogy egy megfelelő (adminisztrátori) jogosultsággal rendelkező személy képes legyen a jogosultságokat kiosztani vagy visszavonni a Web interfészen keresztül is. A J2EE technológián belül a jogosultságok, szerepkörök, felhasználók és felhasználói csoportok kezeléséhez nem szükséges plusz program logikát ültetni a rendszerbe, mert a J2EE kerete erre jól használható megoldást nyújt.
5.1.4 Adathozzáférés, lekérdezés Bár az üzleti logika közvetlenül kapcsolódik az adatbázis szerverekhez, számára mégis mindegy, hogy milyen szerverekkel kell kommunikálnia, mert a J2EE technológia jól elrejti számára az adatforrás típusát. Az Entity Bean-ek használatával már tisztán csak a kinyert adatokkal kell foglalkozni. Az Entity Bean-ek fölött elhelyezkedő Session Bean-ekben megbújó program logika képes rendelkezni arról, hogy az adatokat milyen jogosultságoknál, milyen feltételek mellett lehet az adatbázisból lekérdezni.
Stubenvoll Bt
37 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
5.1.5 Naplózás A naplózási tevékenységeket a Session Bean-ekben kell megvalósítani, ahol rendelkezésre áll, hogy a felhasználó milyen tevékenységeket kívánt elvégeztetni a rendszerrel. Ha szükséges, az általa kiadott összes utasítást fel lehet jegyeztetni, mely napló adatokat Entity Bean-eken keresztül az adatbázisban rögzíteni lehet. A naplózások ki-be kapcsolásához olyan program logika szükséges, mely a beállított adatokat szintén adatbázisban tárolja, így a szükséges információkat onnan bármikor be lehet tölteni, módosítani, vagyis az érintett felhasználóra azonnal érvényesíteni lehet. Ezt oly módon kell elvégeznie, hogy ha az érintett felhasználó épp használja a rendszert, amikor a megfigyelését beállítják, a rá vonatkozó naplózási tevékenységeknek azonnal működésbe kell lépniük.
5.1.6 Konzisztencia-vizsgálat Az adatok helyességének biztosítása érdekében a rendszernek folyamatosan önellenőrzést kell végeznie, a saját adatainak helyességéről. Ezeket az ellenőrzéseket a lekérdezett adatokra a lekérdezés pillanatában el kell végeznie. Ha az adatok integritásában hiba állt elő, erről mind a felhasználót, mind pedig a rendszer karbantartóját azonnal értesítenie kell. Hasonlóan az adatok rendszeres mentésének, a teljes ellenőrzésnek is meg kell történnie bizonyos időközönként, mely a teljes adattartalom helyességének vizsgálatát elvégzi. Mivel ez egy fokozottan erőforrás-igényes tevékenység, ezért általában csak csúcsidőn kívüli tevékenység lehet, kivételt képez a frissítés, adatfeltöltés alkalmával ellenőrzésként, vagy jogosulatlan betörés gyanuja esetén végrehajtott konzisztencia-vizsgálat.
5.1.7 Rendszerhiba jelzés és riasztás A rendszerben bekövetkező hibákról a karbantartót azonnal értesíteni kell. Az értesítésnek nem csak a szoftver vagy adat problémákról, hanem a hardver hibákról is jelzéseket kell tudnia küldeni. Azaz ha valamelyik szerveren hardver hiba lépett fel, vagy esetleg a szerver teljesen kiesett a hálózatból, arról a jelző rendszernek informálnia kell a karbantartót. A hibajelzést generáló programrésznek speciális üzeneteket is kell tudnia kezelni, mint pl.: E-mail, SMS, telefonon keresztül történő hangüzenet továbbítás, melyet a nap 24 órájában el kell tudnia juttatni a címzettnek.
Stubenvoll Bt
38 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
5.2
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Megjelenítés
A kért információ konkrét megjelenítése Web oldalakon keresztül történik meg. Ahhoz, hogy ezek az oldalakat a felhasználó számára hozzáférhetővé váljanak az Interneten keresztül, az oldalakat egy Web szerveren kell tárolni. Mivel a három rétegű architektúra középső szintjén J2EE technológia használata ajánlott, ezért olyan Web szerver használata szükséges, amelyik támogatja a Servlet-ek és Java Server Page-ek használatát, azaz J2EE kompatibilis. A Servlet-ek és a Java Server Page-ek (JSP-k), olyan Web oldalak elkészítésére alkalmasak, melyek egy statikus kereten belül dinamikus tartalommal rendelkeznek. Vagyis ezek az oldalak csak a megjelenítéshez szükséges keretet tartalmazzák, és a feltöltésükhöz szükséges adattartalmat az üzleti logikából nyerik ki.
5.2.1 Dinamikus oldalak A dinamikus oldalak megjelenítéséhez szükség van a Servlet-ek és Java Server Page-ek használatára. Ezek az oldalak olyan adattartalommal rendelkeznek, melyek lekérdezéstől függően más és más tartalommal lehetnek feltöltve. Az oldalak dinamikus tartalmát az adatbázisban tárolt adatok képezik, melyeket az üzleti logikán keresztül kapnak meg a Web oldalak. A dinamikus oldalak tartalmaznak statikus részeket is, de ezek csupán az adatok megjelenítési formáját, az oldalakat jellemző designt jelentik. A dinamikus tartalom feltöltéséhez hivatkozásokat tartalmaznak a rendszer középső rétege felé.
5.2.2 Statikus oldalak Léteznek olyan Web oldalak, melyek alapvetően statikus adatokat tartalmaznak. Ezek igen ritkán változnak, és nagy szövegrészeket, leírásokat jelentenek. Az ilyen információt indokolatlan lenne adatbázisban tárolni, mivel ezáltal csak a rendszer alsóbb szintjeinek indokolatlan terhelése növekedne. A statikus oldalakat magán a Web szerveren kell elhelyezni, ahonnan tartalma közvetlenül elérhetővé válik a falhasználók számára. A statikus oldalak frissítését az érintett oldalak lecserélésével lehet megoldani.
Stubenvoll Bt
39 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
5.2.3 Tartalom alapú keresés Mint minden jól felépített honlapnak, az EKNy rendszernek is szükséges tartalmaznia egy tartalom alapján történő keresést megvalósító motort. Ennek a motornak képesnek kell lennie arra, hogy a Web szerveren tárolt statikus oldalakból, az adatbázisban tárolt adatokból, és a kapcsolódó honlapok tartalmából találati listákat tudjon összeállítani. Ezt oly módon kell elvégeznie, hogy az csak az aktuális felhasználóra érvényes jogosultsági szintnek megfelelő találatokat produkálja. E cél érdekében, az adatbázisban tárolt adatok közötti kereséshez az üzleti logikát kell felhasználnia.
5.2.4 Adminisztratív tevékenységek felületei Az EKNy rendszer adminisztratív tevékenységei több témakört ölelnek fel: •
Bejelentkezések, ahol felhasználónév - jelszó párossal a felhasználó a rendszerben történő hitelesítését végzi el. Maga a hitelesítés konkrétan az üzleti logikában valósul meg, de az oldal megjelenítését a Web szerver végzi el.
•
Jogosultság beállítások, amit az erre megfelelően feljogosított személy a Web oldalon keresztül képes módosítani.
•
Naplózási beállítások, melyeket a megfelelő jogosultságokkal rendelkező személy képes ezeken az oldalakon keresztül elvégezni, ellenőrizni és törölni.
•
Rendszer konfigurációs beállítások, amiket a rendszer adminisztrátora, akár távoli hozzáféréssel is, módosítani tud. Ez abban nyújt nagy segítséget, ha a rendszerben valamilyen probléma adódik, mivel a karbantartó személy akár azonnal, távolról is be tud avatkozni, és a kisebb problémákat el tudja hárítani.
Az adminisztratív tevékenységeket szigorúan naplózni kell, amit az üzleti logika szintjén elhelyezkedő naplózási modul valósít meg.
Stubenvoll Bt
40 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
6 Architektúra Az eddigi fejezetekben nagyszámú funkcionális és teljesítmény-igényt vázoltunk fel, melyeknek az EKNy rendszer meg kell feleljen. Az elmondottak alapján – egyelőre még csak elvi szinten – már megfogalmazhatóak a rendszer architektúrájával szemben támasztott kvalitatív követelmények, melyek alapján meghozhatók az alapvető tervezési döntések és felvázolható a rendszer architektúrája.
6.1
Az EKNy rendszer
Ebben a pontban a rendszer egészéről vázolunk fel követelményeket, melyeket a későbbi hardver és szoftver pontok alatt az tovább kifejtünk.
6.1.1 Rendelkezésre állás A közhiteles nyilvántartások adataihoz való hozzáférés magas rendelkezésre állást követel meg a rendszertől. A 2. fejezetben részletezett követelmények teljesítése érdekében a rendszer hardver elemeit duplikáltan kell implementálni és minden adat és programkód másolatának meg kell jelenni a tükrözött szervereken. Ezzel biztosítható, hogy ha valamelyik eszközzel probléma adódik, a másolata azonnal át tudja venni a feladat elvégzésének szerepét. Ehhez az architektúrához olyan szoftver rendszert kell alkalmazni, mely a tükrözési funkcionalitást automatikusan el tudja látni, azaz nem szükséges kézi beavatkozás a tartalék hardverre történő átálláshoz, ezáltal az átállásból származó időkiesés minimálisra (szinte nullára) csökken. Ezt a megvalósítást nagyon jól támogatja a J2EE technológia. A redundáns hardver és szoftver architektúra döntő fontosságú a rendszerkiesések minimalizálásához, azonban hiba esetén a karbantartást ellátó személynek a bekövetkező problémát a lehető legrövidebb időn belül el is kell hárítania, hiszen ilyenkor az üzem tartalék nélkül megy tovább.
6.1.2 Sebesség A rendszernek jellemzője, hogy nagy számú egyidejű lekérdezést kell tudnia rövid időn belül kiszolgáljon, melyek adott esetben bonyolult adatbázis lekérdezéseken is alapulhatnak. Éppen ezért az adatok feldolgozása, és az adatokból felépülő Web oldal összeállítása a lehető legkevesebb időt kell, hogy igénybe vegye.
Stubenvoll Bt
41 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Az ábrázolt igények a hardverrel szembeni követelmények meghatározására az jelentik, hogy annak a nagyszámú, egyidejű lekérdezés kiszolgálásához nagy memória kapacitással, gyors processzorral, és nagy sávszélességű hálózati kapcsolattal kell rendelkeznie. A szoftver igényekre vonatkoztatva pedig azt, hogy az alkalmazott szoftvereknek hatékonyan kell támogatniuk a nagyszámú konkurens felhasználó tevékenységeit.
6.1.3 Karbantarthatóság A rendszer felépítésének mind hardver, mind szoftver oldalról olyannak kell lennie, hogy a karbantartás könnyen megoldható legyen. Ez szükségessé válhat tervszerű hardverbővítés, szoftver továbbfejlesztés, vagy akár a rendszer által generált hibajelzés alapján történő azonnali javítás esetén is. Az ábrázolt igények a hardver számára az jelentik, hogy a szükséges hardvernek lehetőséget kell nyújtania futás közbeni periféria cserékre. A szoftvertől azt igénylik, hogy a szoftver moduloknak jól konfigurálhatóaknak és paraméterezhetőknek kell lenniük.
6.2
Hardver
Ezen a helyen csak megemlítjük a tükrözött rendszer-részek fizikai elhelyezésének és őrzésének kérdését, amely mint létesítési-szervezési kérdés merül fel és további megbízhatóság-növekedést eredményezhet. Erre a szempontra a 3.5 Katasztrófa-kezelés című pontban térünk ki részletesebben
6.2.1 Raid vagy SCSI winchestertárolás Az optimális karbantarthatósághoz és bővíthetőséghez olyan, nagy hatékonyságú háttértár alkalmazására van szükség, ahol a rendszer leállítása nélkül is cserélni lehet a háttértárakat. Ez jelentősen megkönnyíti a munkavégzést adatmentés és adat-visszaállítás esetében, vagy egy nagyobb háttértárolóra történő áttérés esetén.
6.2.2 Memória kapacitás Mivel igen nagy mennyiségű adathozzáférésre kell számítani, ezért az adatok szükséges időn belüli garantált kiszolgálásához nagy memória kapacitásra van szükség. Mind az adatbázis szerver oldalán, ahol a gyors lekérdezések a lehető legtöbb adat memóriában tartásával garantálhatók, mind pedig az alkalmazás szerver oldalán, ahol annál gyorsabb lesz az egyes kérések kiszolgálása, minél több modult tud a rendszer memóriában tartani,. A kapacitásra vonatkozóan a rendszer kivitelezésekor kell majd javaslatot tenni, a számszerűsített igények figyelembevételével. Stubenvoll Bt
42 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
6.2.3 Processzorsebesség Az adatok lehető leggyorsabb kiszolgálásához javasolt a processzor kiválasztásában elsősorban a feladat végrehajtási időt, mint döntő paramétert figyelembe venni; a lebegőpontos számítások elhanyagolhatók a jelen feladat kategóriájának tükrében. Nem elvárás a 64 bites processzorok használata, de nem is kizáró tényező.
6.2.4 Hálózati kapcsolat sebessége Fontos paraméter a hálózati kapcsolat sebessége, mivel az adatok folyamatos szinkronizálása komoly erőforrásokat köthet le, továbbá a lekérdezések eredményei is jelentős adatmennyiséget mozgatnak meg a hálózaton keresztül. E szempont figyelembevételével a Gigabit Ethernet használatát javasoljuk, mely 1 Gbit/sec sebességgel képes az adatok továbbítására.
6.2.5 Topológiai elhatárolódás Célszerű, hogy rendszer szerverei más-más hálózati csatornán tartsák egymással a kapcsolatot, ezzel a magasabb szintek folyamatosan vágnák el a lehetőséget a legalacsonyabb szinten elhelyezkedő adatok illetéktelen hozzáférésétől.
6.2.6 Internet biztonság Az Internetre történő felcsatlakozás mindig komoly rizikóval jár. Tanácsos a Web szerverek mögé egy tűzfalat is beüzemelni, mely meggátolja a nem a Web szerverről érkező kérések kielégítését, illetve a betörési kísérleteket. Továbbá az adatok védelme érdekében a titkosított csatornák (Secure Socket Layer) használatával biztosítani kell, hogy a Web szerver és a felhasználó közötti kommunikációhoz illetéktelen személy ne férhessen hozzá.
6.3
Szoftver
Ebben a pontban azon szoftverek körét határozzuk meg, melyek elengedhetetlenek az EKNy rendszer működéséhez.
Stubenvoll Bt
43 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
6.3.1 Operációs rendszer A rendszer rendelkezésre állására, megbízhatóságára és sebességére vonatkozó igények miatt tanácsos egy Unix alapú operációs rendszer használata, ahol arra lehet számítani, hogy mind az operációs rendszer hibájából, mind a rendszer sebezhetősége miatt bekövetkezhető szándékos rongálásokból származó kiesett órák száma minimális lesz. Javasolt a Linux operációs rendszer használata a fenti okok, és a szabad szoftver licenc szabályai miatti ingyenessége miatt.
6.3.2 Adatbázis A Rendszer fejezetben már említés történt a globális tükrözött architektúra szükségességéről, ezt az adatbázis kapcsán most ismét megerősítjük A két számítógép adattartalmának azonossága az adatbázis kezelő rendszer szintjén lebonyolított sűrű szinkronizációval garantálható, így az egyik adatszolgáltató szerver kiesése esetén sem adatvesztés, sem pedig szolgáltatás-kiesés nem következik be. Az adatok szinkronizálása az adatszolgáltatástól független, külön csatornán keresztül kell történjék, azaz külön hálózati adapter szükséges a két kommunikációs csatorna kezeléséhez. Az adatbázis-kezelő rendszernek nagy sebességgel kell az adatokat rendelkezésre bocsátania. Nagy rendelkezésre állást és nagy fokú biztonságot kell nyújtania, továbbá olyannak kell lennie, mely megvalósítja a fent említett adattükrözést egy távoli géppel történő folyamatos szinkronizációval. Elvárás még vele szemben, hogy megfelelően megbízható jogosultság és adattitkosítási mechanizmussal rendelkezzen az adatok védelme céljából.
6.3.3 Alkalmazás szerver Maga a program logika (üzleti logika), a három rétegű architektúrának megfelelően egy középső rétegen kell elhelyezkedjen, mely a J2EE technológia támogatásával rendelkezik. Ezeket a rendszereket hívják alkalmazás szervereknek. Az alkalmazás szerverek kellő hátteret biztosítanak a cél elérése érdekében, hogy a kifinomult jogosultság-kezelési igények tisztán konfigurációval, minden többletprogramozás szükségessége nélkül megvalósíthatóak legyenek. Jó megoldásokat nyújtanak továbbá az adatok titkosított csatornákon keresztül történő továbbítására is. A J2EE technológiából kifolyólag az alkalmazás szerverek számára tisztán konfiguráció útján publikálhatóak azok az adatforrások, ahonnan az adatokat ki kell nyerniük, azaz az üzleti logika számára mellékes, hogy hol, milyen beállításokkal milyen adatbázis
Stubenvoll Bt
44 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
rendszerben vannak az adatok tárolva. Tükrözött adatbázis rendszer esetén automatikusan képes az elsődleges rendszerről átállni a tartalék, tükrözött adatokat tartalmazó rendszerre. A tükrözött rendszerarchitektúrát az üzleti logika megbízhatósága is alátámasztja, mert bár az üzleti logika nem dinamikusan módosuló tartalmú rendszer és ezért nem igényel az adatbázishoz hasonló folyamatos szinkronizációt, de a programkód módosításait mindkét alkalmazás szerverre el kell juttatni, hogy amennyiben a tartalék rendszer átveszi a vezérlést, zökkenőmentesen, azonos programverzióval futhasson tovább az alkalmazás. A hibák detektálását az alkalmazás szerveren belüli logika valósítja meg, ezért szükség van egy olyan értesítő rendszerre, ami olyankor is el tudja juttatni a karbantartó számára a hibajelzést, ha az éppen nem tartózkodik a munkahelyén. Tehát a hibajelzést generáló programrésznek speciális üzeneteket is kell tudnia kezelni, mint pl.: E-mail, SMS, telefonon keresztül történő hangüzenet továbbítás. Erre egyes alkalmazás szerverek képesek. Nem műszaki, hanem szervezési kérdés, hogy karbantartásért felelő csoport ügyeleti rendszerben dolgozzék, amely lehetővé teszi egy éjszakai bekövetkező rendszerhiba azonnali elhárítását is. Ez nem igényel folyamatos jelenlétet, de elérhetőséget és azonnali helyszínre utazást igen.
6.3.4 Web szerver A Web szerver felel az adatok megjelenítéséért, azaz azon oldalak szolgáltatásáért, melyek az adatokat lekérdező személyek böngészőjében megjeleníthetőek. A Web szervernek dinamikus oldalak megjelenítésére képesnek kell lennie, vagyis J2EE kompatibilisnek kell lennie ahhoz, hogy Servlet-eket és Java Server Page-eket képes legyen megjeleníteni, amihez az alkalmazás szerver szolgáltatja a szükséges adatokat. Itt kerülnek tárolásra azon statikus oldalak is, melyeket nem szükséges adatbázisban tárolni, vagyis csak nagy mennyiségű, ritkán változó szöveges információkat tartalmaznak.
6.4
A javasolt architektúra áttekintése
Az adatszolgáltatást három rétegű alkalmazás kell megvalósítsa, ahol elkülönül az adatok tárolása (adatbázis szerver), az adatok szolgáltatása (üzleti logika) és az adatok megjelenítése (kliens). Mivel az adatok megjelenítése Web-es interfészen keresztül kell, hogy megtörténjen, ezért a fent említett három réteg a következő formában jelenik meg: Adatbázis szerver, Alkalmazás szerver, Web szerver. Ahhoz, hogy a fent említett elhatárolódó szinteket megfelelően és a leghatékonyabban meg lehessen valósítani, célszerű a J2EE technológia használata. Egyúttal ez a technológia megfelelő támogatást nyújt tükrözött adatbázis szerverek, jogosultságok, és dinamikus Web lapok kezelésére is.
Stubenvoll Bt
45 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
6.5
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Hardver architektúra
A következő pontokban az ábra sorrendjében összefoglaljuk a bemutatott elemek legfontosabb funkcióit. Stubenvoll Bt
46 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
6.5.1 Adatbázis szerver és tükrözött adatbázis szerver Az adatbázis szerver gondoskodik az EKNy rendszer által kezelt és a primer adattárakból tükrözött másolatban helyben frissített adatok tárolásáról. A tükrözött adatbázis szerver pontosan ugyan azokat az adatokat tárolja, mint az elsődleges adatbázis szerver, annak érdekében, hogy ha bármi probléma történik és az elsődleges adatbázis szerver kiesik, azonnal át tudja venni a szerepét, a nélkül, hogy a felhasználót bármi kellemetlenség érné az adatok lekérdezése során. Az adatok szinten tartására egy külön hálózati csatorna szolgál, hogy minden egyéb hálózati kommunikációtól függetlenül történhessen meg az adatok szinkronizálása. Ezáltal nem gátolja az adatok lekérdezését azzal, hogy az adatszolgáltató hálózati csatornát terheli, és garantált a szinkronizálandó adatok lehető leggyorsabb célba juttatása.
6.5.2 Kapcsolódó adatbázis szerverek Léteznek olyan adatbázis szerverek, melyeknek az adattartalma jogi, vagy egyéb okokból nem tárolható az EKNy rendszerén belül. Ezekhez az adatokhoz az alkalmazás szerver közvetlenül csatlakozik. A csatlakozáshoz a kapcsolódó rendszerben egy interfész van biztosítva, ami tárolt eljárások meghívását valósítja meg. Az adat lekérdezés jogosultságának vizsgálata a kapcsolódó rendszeren történik meg, a lekérdezéshez megadott paraméterek alapján.
6.5.3 Alkalmazás szerver és tükrözött alkalmazás szerver Az alkalmazás szerver tárolja a teljes program logikát, azaz az üzleti logikát. Az alkalmazás szerver nem csak különálló hardvert, hanem az adott hardveren futtatott alkalmazás típusát is jelenti. A tükrözött alkalmazás szerver pontosan ugyanazokat az adatokat tárolja, mint az elsődleges alkalmazás szerver, annak érdekében, hogy ha bármi probléma történik és az elsődleges alkalmazás szerver kiesik, azonnal át tudja venni a szerepét az üzemi funkciók megzavarása nélkül. Mivel az adatok ritkán változnak, ezért nem szükséges folyamatos szinkronizációval frissen tartani az adatokat. E miatt nem is igényel külön szinkronizációs csatornát.
Stubenvoll Bt
47 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
6.5.4 Tűzfal és tükrözött tűzfal Fontos az adatok védelme az illetéktelenektől, szándékos rongálóktól, ezért az alkalmazás szerver és a Web szerver közé egy tűzfal telepítése ajánlott, mely meggátol minden olyan adatlekérési kísérletet, mely nem a Web szervertől érkezik, vagy minden olyan kísérletet, ami nem a megfelelő formában próbál az adatokhoz hozzáférni. A tartalék tűzfalra azért van szükség, mert ha az elsődleges tűzfal működésében zavar áll be, a tartalék rendszer át tudja venni a szerepét, és az adatok szolgáltatásában semmi fennakadás nem mutatkozik.
6.5.5 Web szerver és tükrözött Web szerver A Web szerver látja el a megjelenítés feladatát, vagyis a Web szerveren találhatók azok a Web oldalak melyek a felhasználó böngészőjében a lekért információt megjelenítik. A tartalék Web szerver pontosan ugyanazokat a Web oldalakat tárolja, mint az elsődleges Web szerver, ezáltal hiba esetén lehetőség nyílik a kérelmeknek a tartalék szerverre való átirányítására. Ehhez azonban a címzés átirányítására is szükség van, melynek megoldására többféle lehetőség van, melyek közül majd a konkrét rendszerterv kialakításánál, az igények pontos ismeretében lehet dönteni. Mivel az adatok ritkán változnak, ezért itt sem szükséges folyamatos szinkronizációval frissen tartani az adatokat és külön szinkronizációs csatornára sincs szükség.
6.5.6 Internet és a felhasználók Az ábra utolsó sora jelzi, hogy az EKNy rendszerhez az Interneten keresztül nagyszámú kérelmező csatlakozhat, akik bárhol tartózkodhatnak.
Stubenvoll Bt
48 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
6.6
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Szoftver architektúra
Tárolásra kerül a más szolgáltatóktól lekért adatok és a saját adatok
Szinkronizáció
Tükrözött és saját adatok Adattárolás, adatszolgáltatás szintje Relációs adatbázis szerver használatával
Adatbázis szerver
Kapcsolódó adatbázis szerver
Adat szolgáltatás A nagy számú konkurens lekérdezés, és a kért adatok mennyisége miatt nagy sebességű hálózat
A J2EE technológia magában támogatja a jogosultságok kezelését, az programozni nem kell, csak konfigurálni
Üzleti logika (konkrét program logika) szintje J2EE technológiát támogató alkalmazás szerverek használatával
Alkalmazás szerver Adat szolgáltatás
Ha a tűzfal különálló eszköz, akkor a nagyobb biztonság elérése érdekében célirányos eszköz beszerzése javasolt
Adatvédelem szintje Túzfal használatával
Tűzfal Adat szolgáltatás
A tűzfal és a Web szerver lehet közös hardveren, ha a hardver megfelelő kapacitással rendelkezik
Az Internethez való csatlakozást a nagy számú konkurens használó miatt a gerinchálózatra történő illeszkedéssel javasolt megoldani
Adatmegjelenítés szintje J2EE kompatibilis Web szerver használatával
Web szerver Internet
Ügyfél megjelenítés szintje Internet kapcsolattal rendlekező helyekről Web böngésző használatával
`
Stubenvoll Bt
49 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Az egész EKNy rendszerre érvényes ajánlás, hogy minden hardveren (leszámítva a speciális célgépként működő tűzfalat) Unix alapú operációs rendszer fusson, a nagy rendelkezésre állása és megbízhatósága miatt. A következőkben az egyes szoftver egységek legfontosabb jellemzőit soroljuk fel.
6.6.1 Adatbázis szerver Az adatbázis szerver a más szervezetektől tükrözött, vagy saját adatokat tartalmazza. Ez maga az adatszolgáltatás szintje. Az adatokat relációs adatbázisban kell tárolni, mely megfelelő jogosultsági és adattitkosítási mechanizmussal rendelkezik ahhoz, hogy az adatok kellő biztonságban tudhatók legyenek.
6.6.2 Tükrözött és saját adatok Ezen a szinten jelenik meg minden, az EKNy rendszerben tárolt adat, legyen az saját kezelésben, vagy más adattárból tükrözéssel átmásolt és itt frissített adat.
6.6.3 Kapcsolódó adatbázis szerver Ez a szerver tárolt eljárások meghívásával gondoskodik azon adatok lekérdezéséről, melyek nem tárolhatók az EKNy rendszerben. Ezek meghívásával lehet adatokat lekérdezni, oly módon, hogy a tárolt eljárásnak paraméterben megadott jogosultsági információk alapján az érintett szervezet adatbázis szervere hitelesíti a felhasználót.
6.6.4 Alkalmazás szerver Az alkalmazás szerver nem csak a hardvert magát jelenti, hanem az alkalmazott szoftvert is. Az alkalmazás szerverek három rétegű alkalmazások számára egy futtató keretet biztosítanak, melyek átveszik a programozók kezéből a memóriával, párhuzamosítással, hálózatkezeléssel, titkosítással, jogosultság kezeléssel kapcsolatos feladatokat, és a rendszerek fejlesztői csak a program logikával kell törődjenek. Olyan alkalmazás szerver használata szükséges, mely teljes mértékben megvalósítja a J2EE technológiát, és amely többek között rendelkezésre tud bocsátani olyan többletszolgáltatásokat is, mint az SMS-ben, Email-ben történő üzenetküldést.
Stubenvoll Bt
50 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
6.6.5 Tűzfal A tűzfal topológiailag lehet külön hardver, de össze is épülhet a Web szerverrel. Ha a tűzfal különálló hardver, akkor lehet egy konkrét tűzfal-szolgáltatásokat ellátó céleszköz, de lehet egy hardver is, melyen egy szoftver egység biztosítja a tűzfal funkcionalitásokat. Ha a végső megoldás külön hardvert valósít meg, akkor a nagyobb biztonság elérése érdekében javasolt megfelelő célhardver használata. Ha a tűzfal összeépül a Web szervert tartalmazó hardverrel, akkor egy szoftver fogja biztosítani tűzfal funkcionalitásokat.
6.6.6 Web szerver A Web szerver tartalmazza a Web oldalakat, melyek lehetnek statikusak és dinamikusak is. A statikus Web oldalak azok az adatok, melyek igen ritkán változnak, és alapvetően szöveges leírások. A dinamikus oldalak azok, melyeknek tartalma függ a felhasználó jogosultsági körétől, a lekérdezett adatoktól, vagyis rajtuk keresztül az adatbázis tartalma jelenik meg. Ezeknél az oldalaknál az oldalak kerete, alapvető design-ja van a Web szerveren tárolva, minden lényegi tartalom az adatbázisból érkezik. Ahhoz, hogy ezek az oldalak az alkalmazás szerveren keresztül kinyerhetőek legyenek, szükséges, hogy a Web szerver J2EE kompatibilis legyen, vagyis képes legyen Servlet-ek és Java Server Page-ek futtatására.
6.6.7 Internet Az EKNy rendszerét Interneten keresztül használók számára csak egy Web böngésző szükséges, mely manapság már minden számítógépen megtalálható. A Web böngészőn keresztül a felhasználó minden számára fontos információt lekérdezhet, amihez megfelelő jogosultsága van. Az adatok védelme érdekében a kapcsolatok titkosítottan épülnek fel (Secure Socket Layer alkalmazásával), így illetéktelen személyek nem tudnak belehallgatni mások adatforgalmába. A rendszer karbantartóinak lehetőségük lesz a rendszert az Interneten keresztül felügyelni, probléma esetén egyszerűbb tevékenységekkel beavatkozni. Komolyabb problémák esetén természetesen a hiba elhárítását a helyszínen kell elvégezni.
Stubenvoll Bt
51 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
II. rész Az adatmodell
A tanulmány második része az egészségügyi és szociális szféra közhiteles nyilvántartásai adatmodellezését mutatja be. Először a jobb érthetőség érdekében röviden összefoglaljuk az adatmodellezés technológiai alapjait és az alkalmazott módszer hátterét, majd sorra vesszük a dr. Sinkó Eszter már idézett tanulmánya alapján jelenleg közhitelesnek tekintett nyilvántartásokat, leírjuk adatmodelljüket illetve rámutatunk azokra az esetleges hiányosságokra, melyek a teljes körű leírást akadályozták. Javaslatot teszünk egy, a nyilvántartásokban jelenleg meglevő redundancia csökkentésére, a nyilvántartások harmonizálására, és mint lehetőséget, elkészítjük a személyi nyilvántartások harmonizált adatmodelljét. Végül a jelenlegi adatstruktúrákat alapul véve bemutatjuk az EKNy rendszer megvalósításánál kialakítandó adatmodellt.
Stubenvoll Bt
52 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
7.1.1 Adatmodell Az adatmodell egy adathalmaz struktúrájának és entitásainak leírása, a közöttük levő kapcsolatok típusának és viselkedésének bemutatása. Egy információhalmaz azonosított egyedeit entitásoknak, az entitások alkotó elemeit paramétereknek és az entitások közötti összefüggéseket kapcsolatoknak nevezzük.
7.1.2 Az UML Az UML a Unified Modeling Language rövidítése, mely egy szabványos jelölésrendszer objektum-orientált programok tervezéshez. Az UML 1.0-ás verzióját 1997-ben fogadta el a nemzetközi szabványügyi hivatal, azóta több bővítése és pontosítása látott napvilágot, melyekkel használhatósága jelentősen nőtt és mára igen elterjedten használatossá vált. Az UML nem ad módszertant a programok és rendszerek tervezéséhez, csupán a jelölés alapjait fekteti le. Ezeken az alapokon számos módszertan alkalmazható. Az UML lehetővé teszi, hogy különböző módszertanok alkalmazása ellenére (hiszen minden szervezet egy kicsit más és más módszereket követ) egy elkészített rendszerterv mégis egységes ábrázolási technikával készüljön el, azt könnyen tudja olvasni minden olyan személy, aki a fejlesztésekbe becsatlakozik, és ne okozzon problémát a szervezetek közötti információ cserében sem. Az UML több jelölési módot is tartalmaz, melyek a tervezés eltérő szintjén segítik a rendszerfejlesztőt. Ezeket két csoportosítási kategóriába sorolja: • •
Statikus diagrammok Dinamikus diagrammok
Számunkra a Statikus diagrammok közül kizárólag az osztály diagrammokra van szükség, ezért az UML-nek csak ezt a területét ismertetjük. Ha a kedves olvasó mégis tovább érdeklődik e jelölésrendszer után, akkor a szabvány leírását a www.uml.org oldalról díjmentesen letöltheti.
Stubenvoll Bt
53 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
7.1.3 Adatmodellezés UML-ben Az UML az osztály diagramm segítségével kiválóan alkalmas adatmodellek ábrázolására. Az entitások az osztályok maguk, az entitás paraméterei az osztály változói, és a kapcsolatokat a számosságukkal együtt szintén jelölni lehet.
«table» ORSZAG ID : INTEGER NEV : VARCHAR(64)
«table» MEGYE
1 0..*
ID : INTEGER NEV : VARCHAR(255) ORSZAG_ID : INTEGER
A fenti ábrán két entitás látható, ORSZAG és MEGYE névvel ellátva. Az entitásokat a <
> constraint teszi egyértelművé. Ha logikailag nézzük meg a két entitást, akkor könnyen belátható, hogy a nyilvántartásban egy országhoz nulla vagy több megye tartozhat, de olyan nincs, hogy egy megye ne tartozzon semelyik országhoz, vagy hogy ugyanaz a megye több országhoz is tartozzon. Ezt a közöttük átívelő, függőséget kifejező vonal és a két szélén elhelyezkedő jelölés írja le. Az entitások attribútumainak jelölésében a következő jeleket lehet felismerni. Az első két betű az adat kezelésére vonatkozó főbb információt jelöl meg: •
NN: azt jelenti, hogy a megjelölt mező nem lehet zérus (Not Null), vagyis kötelező kitölteni adattal.
•
PK: Primary Key, azaz ez a mező egyértelműen azonosítja a táblában tárolt adatok minden egyes sorát. Az elsődleges kulcsok értéke nem lehet nulla, azokat mindig meg kell adni.
•
FK: Foreign Key, azaz ez a mező egy kapcsolódó táblának az elsődleges azonosítója (Primary Key). Az idegen kulcsok csak akkor lehetnek nulla értékűek, ha kapcsolata a másik táblával engedélyezi, hogy a túloldalon ne tartozzon hozzá kapcsolódó adat. Ha ezt a fenti ábrán nézzük, akkor a MEGYE entitásban megjelölt idegen kulcs nem lehet null, mivel az ORSZAG entitásnak kötelezően egynek kell lennie. Azaz nincs olyan megye, mely ország nélkül is létezhet.
A kettőspont előtt az attribútum neve, míg utána a típusa található.
Stubenvoll Bt
54 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
7.1.4 Az SQL Az SQL egy szabványos programozási nyelv, mely relációs adatbázisokból történő adatlekérdezéseket, adatdefiníciókat valósít meg. Az SQL-en belül két kategóriára bomlanak az utasítások: • •
Adatdefiníciók Adatmanipulációs utasítások
Az SQL-t a ANSI szabványosította, aktuális változata az SQL-92. Adatdefiníciós utasítások Az adatdefiníciós utasítások lehetővé teszik, hogy az adatbázisban létrehozzunk, módosítsunk vagy töröljünk entitásokat, azaz adatbázis táblákat, nézeteket. Továbbá, hogy ezekhez jogosultságokat és szerepköröket rendeljünk, vagy visszavonjunk. Adatmanipulációs utasítások Az adatmanipulációs utasítások segítségével a létrehozott adatbázis táblákból, nézetekből adatokat kérdezhetünk le, azokat módosíthatjuk, illetve törölhetjük őket.
7.2
Elvárások
7.2.1 Elvárások az adatmodellel szemben Az adatmodellel szemben támasztott elvárások az entitások, és azok kapcsolatának szintjére korlátozódik, és nem elvárás az entitások mezőinek konkrét meghatározása.
7.2.2 Elvárások az UML adatmodellezéssel szemben Az UML adatmodellezéssel szemben az az elvárás, hogy kellően rugalmas, és univerzális megoldást nyújtson, értelmezése egyértelmű legyen. Ezt az UML oly módon képes teljesíteni, hogy a jelölésrendszer szabványként elfogadott, vagyis minden szoftverfejlesztő cégnek tisztában kell lennie a jelölési elemekkel. Mivel az UML 1997 óta szabvány, ezért ma már számos szoftver termék képes a jelölésrendszer támogatására. Az XMI segítségével egy általános fájl struktúrát is kidolgoztak hozzá, mellyel az UML diagrammok teljesen platform- és szoftver-függetlenné váltak.
Stubenvoll Bt
55 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
7.3
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Ajánlások
7.3.1 Ajánlások modellezési eszközökre Modellezési eszközök keresése közben több szempontot tanácsos szem előtt tartani, melyek a következők: •
Kezelje az UML diagrammokat, mivel az adatstruktúra UML osztálydiagramokban kerül megvalósításra
•
Legyen XMI támogatása abból a célból, hogy az UML diagrammokat képes legyen betölteni, melyek az erre a célra készült általános fájlábrázolási rendszerben készültek
•
Komoly előnyt nyújthat, ha az UML diagrammokból közvetlenül képes adatbázis struktúrát generálni vagy oly módon, hogy SQL utasításokat képes összeállítani, vagy pedig úgy, hogy közvetlenül az adatbázisban képes létrehozni a kívánt táblákat
•
Értelem szerint fontos szempont az eszköz árfekvése is. Jelenleg több cég termékének is kapható ingyenes változata, melyek tökéletesen használhatók modellezési célokra. Általában az ingyenes változatok az olyan többlet szolgáltatásokat nem szokták tartalmazni, mint az adatbázisban történő tábla létrehozás vagy SQL utasítások összeállítása a diagrammok alapján.
Stubenvoll Bt
56 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
8 A létező egészségügyi és szociális közhiteles nyilvántartások adatmodellje A meglevő közhiteles nyilvántartások feltérképezését az eEgészség program párhuzamosan futó, 25. számú projektje, „A létező közhiteles nyilvántartások felmérése” végezte el, dr. Sinkó Eszter vezetésével; az alábbi fejezet az ő idézett munkája eredményeire épül.
8.1
A létező közhiteles nyilvántartások áttekintése
Idézett tanulmányában dr. Sinkó Eszter az egészségügyi és szociális szféra területén az alábbi, létező nyilvántartásokat jelölte meg, mint amelyek ma közhitelesnek tekinthetők, és figyelembe veendők az EKNy rendszer kialakításakor: • • • • • • • • • •
Orvostörzs (tartalmazza a fogorvosokat is) Klinikai szakpszichológusok nyilvántartása Egészségügyi szakdolgozók nyilvántartása Gyógyszerészek nyilvántartása Gyógyszerek nyilvántartása Szolgáltatók nyilvántartása Országos Transzplantációs Nyilvántartás TAJ nyilvántartás Kódtáblázatok nyilvántartása (BNO, FNO, OENO, HBCS) Finanszírozási algoritmusok nyilvántartása
Ebben a fejezetben az egyes közhiteles nyilvántartások adatmodelljét mutatjuk be, majd ismertetjük az EKNy rendszer ennek alapján felépített közös adatmodelljét. Itt szükséges megjegyezni, hogy mind dr. Sinkó Eszter idézett tanulmánya, mind dr. Szócska Gábornak a közhiteles nyilvántartások jogi környezetét bemutató, ugyancsak az eEgészség program keretében kidolgozott felmérése, mind saját előkészítő munkánk alapján egybehangzóan leszűrhető, hogy a jelenleg létező nyilvántartások ill. az az azokat szabályozó jogi háttér még nem eléggé egységes ahhoz, hogy az EKNy rendszerre egységes adtamodell legyen készíthető. Ebben a fejezetben azonban ajánlásokat teszünk arra, hogy milyen harmonizálási lehetőségeket látunk a jelenlegi adatmodellek összevezetésére a későbbiekben. A fejezet további részében a létező közhiteles nyilvántartások adatmodelljét készítjük el, támaszkodva a fenti munka eredményeire. A dr. Sinkó Eszter tanulmányának középpontjában álló szervezeti-működési bemutatásból kiindulva felépítjük a nyilvántartások logikai adatmodelljét, megadva az entitásokat és az adatmezőket is. Az érthetőség kedvéért
Stubenvoll Bt
57 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
kénytelenek voltunk egyes elemeket átvenni az idézett tanulmányból, de igyekeztünk, amennyire lehet, elkerülni az ismétléseket. Az egyes nyilvántartások adatmodelljét az alábbi tagolásban ismertetjük: 1. Áttekintés • • • • •
A nyilvántartás célja, logikai környezete (a jobb érthetőség érdekében) A szervezet megfogalmazása Az általa nyilvántartott adatok meghatározása, célja Adatforgalom megfogalmazása Adatokra vonatkozó specialitások (pl.: kód képzés leírása)
2. Entitás leírások • • •
Diagramm Entitás leírások Attribútum leírások
3. Adatbázis információk • •
Mennyiségi, méreti, sebességi adatok Tárolási környezet
Mely adatokat lehet összevonni Mit nyerünk vele Mely adathalmazokkal lehet az összevonást elvégezni Közös formára hozási javaslat
Meg kell jegyeznünk, hogy ez a felsorolás nem minden nyilvántartás esetén volt kitölthető megfelelő tartalommal, mivel nem sikerült minden közhiteles adattárról valamennyi, ehhez szükséges információt megszerezni. Ahol az adatmodell elkészítéséhez a szükséges adatok nem álltak rendelkezésünkre, ott a lehetőséghez képest igyekeztünk más forrásból meríteni, a cél minél jobb elérése érdekében. Több helyütt is a nyilvántartásba való felvétel alapját képező űrlap adatait kellett lapul vennünk, melyből magunk alakítottunk ki adatmodellt. Ezeken a helyeken azonban egyértelműen jelezzük (a szokásos sárga helyett rózsaszín háttérrel, ami fekete-fehér nyomtatásban sötétebbnek hat), ha az adatmodell feltételezéseken alapul. Amennyiben az EKNy rendszer megvalósításra kerül, az adatmodelleket a tervezés első fázisa során egyeztetni kell a megfelelő adatgazdákkal.
Stubenvoll Bt
58 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
8.2
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Orvosok, fogorvosok alapnyilvántartása
8.2.1 Áttekintés „Az egészségügyi tevékenység gyakorlása, a betegek érdekeit, valamint az ellátás biztonságát védendő, engedélyhez kötött. Ahhoz, hogy valaki orvosként, fogorvosként tevékenykedhessen, orvosi, fogorvosi végzettséggel kell rendelkeznie. Az itthon kiadott illetve külföldön megszerzett és honosított diplomák nyilvántartási kötelezettségéről az 1997-es Egészségügyi Törvény rendelkezik, e szerint a megszerzett szakképesítésről ún. alapnyilvántartást kell vezetni.” „A nyilvántartás elsősorban papíralapú. Az utóbbi időben (2001-től) elektronikus nyilvántartás is történik, a régi adatlapokat eközben folyamatosan rögzítik, visszamenőleg 1960-ig”. „Az alapnyilvántartás esetében - az ESzCsM megbízása alapján - a nyilvántartás működtetője az Engedélyezési és Közigazgatási Hivatal (EKH). Bár a Magyar Orvosi Kamara (MOK) a működési nyilvántartás karbantartója, az alapnyilvántartás az ESzCsMtől történő folyamatos adatfrissítés útján is az ő gondozásában van. Az adatfrissítés távoli modemes adatkapcsolattal történik. A működő nyilvántartást a MOK-nál (Magyar Orvosi Kamara) rögzítik, viszont a működő (vagy működési) nyilvántartás feltétele az alapnyilvántartás megléte, erről az EKH igazolást ad ki.”
8.2.2 Entitások Az alapnyilvántartásban egyetlen entitás szerepel, mely az orvos törzslapja. Az adatnyilvántartás kulcsa a sorszám, melynek képzése A/nnnnn formában történik meg, ahol nnnnn: 1-99999.
Stubenvoll Bt
59 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
«table» Orvostörzs Sorszám : VARCHAR(1) Név : VARCHAR(1) Leánykori név : VARCHAR(1) Születési hely : VARCHAR(1) Születési idő : TIMESTAMP Anyja neve : VARCHAR(1) Állampolgársága : VARCHAR(1) Lakcím : VARCHAR(1) Szakképesítés megnevezése : VARCHAR(1) Oklevél, bizonyítvány száma : INTEGER Oklevél kiállítás helye : VARCHAR(1) Oklevél kiállítás időpontja : TIMESTAMP Oklevél kiállító intézmény : VARCHAR(1) Honosított oklevél által tanúsított szakképesítés : VARCHAR(1) Honosítás száma : INTEGER Honosítás helye : VARCHAR(1) Honosítás időpontja : TIMESTAMP Honosító intézmény : VARCHAR(1) Vizsga letételét tanúsító okirat száma : INTEGER Okirat kiállítás helye : VARCHAR(1) Okirat kiállítás időpontja : TIMESTAMP Okirat kiállító intézmény : VARCHAR(1)
Az adatmodell az adatfelvételi lap adatai alapján készült, mivel az elektronikus megvalósítás során kialakított struktúrát nem sikerült megkapnunk. A VARCHAR(1) adattípus megjelöléssel arra utalunk, hogy szöveges adatmezőkről van szó, ezek hosszát azonban nem ismerjük.
8.2.3 Adatbázis információk Időben e tanulmány elkészítésével párhuzamosan történik az átállás az EKH eddig részben papír alapú nyilvántartásáról elektronikus nyilvántartásra, de mivel az új rendszer még nem működik végleges formájában, így nincsenek pontos információink az adatbázis fizikai paramétereiről és adatszerkezetéről. Az átmeneti állapotban a változásokat a MOK működési nyilvántartásába is felveszik. Várhatóan 2004 őszén áll üzembe az új alapnyilvántartás. Az orvosi, fogorvosi alapnyilvántartás jelenleg mintegy 63.000 személy adatait tartalmazza, közülük 53.000 fő adatai elektronikusan is hozzáférhetőek. Az éves bővülés mértéke kb. 1100 fő.
Stubenvoll Bt
60 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
A tárolási környezetről, az adatbázis megvalósításának hardver-szoftver környezetéről nem kaptunk információt.
8.2.4 Hozzáférési szabályozások Az adatbázis személyes adatokat tartalmaz, ezért rá alkalmazni kell a megfelelő általános adatvédelmi szabályokat. Saját adatok lekérdezése: Nincs elegendő információ. Adatlekérdezés az ESZCSM körében: az adatok lekérdezésére, az adatszolgáltatásra belső szabályozás van érvényben, melyről nincs elegendő információ.
8.2.5 Egységesítési ajánlások A nyilvántartásról túlságosan kevés adat áll rendelkezésünkre ahhoz, hogy megfelelő javaslatot tehessünk a többi adattárral való harmonizálásra. Általánosságban mégis lehet annyit mondani, hogy a nyilvántartás név és cím struktúrája egységesíthető a többi személyi nyilvántartás megfelelő adatmezei adatstruktúrájával. A konkrét megvalósítások ismeretében lehet azonban csak felmérni, mekkora egyedi munkát igényel az adatok konverziója, adott esetben mezőkre bontása.
8.3
Orvosok, fogorvosok működési nyilvántartása
8.3.1 Áttekintés Az Egészségügyi Törvény rendelkezik az orvosok, fogorvosok működési nyilvántartási kötelezettségéről is; nyilvántartásba vétel hiányában ilyen irányú tevékenységet nem lehet folytatni. A kétféle nyilvántartás felállítására 2000. év tavaszán került sor, miniszteri rendelet előírása alapján. A nyilvántartások vallott célja továbbá – egészségpolitikai vonatkozásban –, hogy tudni lehessen, hány orvos, fogorvos, milyen intézményekben, munkahelyeken dolgozik ma az egészségügyben. A működési nyilvántartást a nyilvántartás működtetője: a Magyar Orvosi Kamara (MOK) látja el. A működési nyilvántartásba vétel az orvos, fogorvos kérelmére történik, nem kötelező jellegű a regisztráció. Stubenvoll Bt
61 / 141
Budapest, 2004 szeptember 30
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
eEgészség Program – 27. projekt
8.3.2 Entitás leírások A működési nyilvántartásban kilenc entitás szerepel: • • • • • • • • •
Tag nyilvántartás Diploma Etikai eljárás Kamarai funkció Továbbképzés Nyelvismeret Szakképesítés Tudományos fokozat Munkahely
Ezen entitások kapcsolata a következő ábrán látható:
Diploma Munkahely
Tudományos_fokozat
Etikai_eljárás
Tag
Kamarai_funkció
Szakképesítés Nyelvismeret
Továbbképzés
Tagnyilvántartás A Tagnyilvántartás a működési nyilvántartás alapadatait tartalmazza. A kamarai tagról tárolt alapérvényű információk ebben az entitásban vannak tárolva.
Stubenvoll Bt
62 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Itt is megjegyezzük, hogy a VARCHAR(1) adattípus megjelöléssel arra utalunk, hogy szöveges adatmezőkről van szó, ezek hosszát azonban nem ismerjük. Diploma A Diploma entitás az Magyar Orvosi Kamarai tagok által megszerzett diplomákat tárolja, melyek közül több is lehet egy taghoz rendelve.
8.3.3 Adatbázis információk Pillanatnyilag ~63000 nyilvántartási (pecsét)szám foglalt, ennyien szerepelnek az alapnyilvántartásban. Közülük eddig összesen ~43000 orvos, fogorvos regisztráltatta magát a működési nyilvántartásban. Évente 600-700 a friss diplomások, illetve a honosítások száma. Szakvizsga alapján ~1000/év a változás, egyéb adatváltozás (lakcím, munkahely): 3-4000/év. Az adatbázis fizikai megvalósítására, tárolási környezetére vonatkozóan nincs elegendő információnk.
8.3.4 Hozzáférési szabályozások A nyilvántartás jelenlegi formájában nem kérdezhető le az Interneten keresztül. A megyei és helyi kamarák az adatbázishoz behívásos terminálkapcsolatot létesíthetnek, valamint szerződött kapcsolatok is vannak az adatszolgáltatásra (pl. bankok, internet magazin stb.), a
Stubenvoll Bt
68 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
MOK vezetőség egyetértésével. Lekérdezés lehetősége a nagyközönség számára csak az ügyfélszolgálaton keresztül, off-line biztosított. A hozzáférési jogosultság kérdése a jelenlegi nyilvántartásban nem általánosan megoldott. Az adatokhoz csak megfelelő, esetileg beállított jogosultságokkal lehet intézményeknek hozzáférni. Megfontolandó, hogy dr. Sinkó Eszter felmérése szerint a nyilvántartás tartalmi integritása sem megoldott. A fentiek miatt az EKNy rendszer megvalósítása első lépéseként pontosan specifikálni kell a nevesítetlen és nevesített hozzáférések eseteit, és a lekérdezhető, illetve kereshető adatok körét.
8.3.5 Egységesítési ajánlások A személyekre vonatkozó alapadatok kiemelhetők a nyilvántartás belsejéből, mivel a többi személyi nyilvántartásban is azok állnak a középpontban. A személyek tipikus alapadatai: • • • • • • • • • •
Név Születési név Születési idő Születési hely Anyja neve Címei (levelezési, otthoni) Telefonszámai Email címe Neme Állampolgársága
A címekre vonatkozó részek feltétlenül külön választhatók a személyes adatoktól, már csak azért is, egy személynek több címe is van, és a munkahelyi címe számos dolgozónak azonos. A címeket több szinten kell megvalósítani, annak függvényében, hogy a redundáns adatkezelést a lehető leghatékonyabban lehessen megszüntetni. Ezek a kategóriák a következők: • • • •
Ország Megye Város Cím (utca, házszám stb.)
A telefonszámokat szintén érdemes külön választani mind a személyektől, mind az intézményektől. Ennek több oka is van.
Stubenvoll Bt
69 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
• •
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Egy intézmény és egy személy munkahelyi telefonszáma lehet azonos Mind az intézményeknek, mind a személyeknek több telefonszáma is lehet. Egy intézménynek osztályonként is több, míg egy személynek tipikusan három (munkahelyi, otthoni, mobil), de előfordulhat, hogy ennél többet is nyilván kell tartani.
Éppen ezért kár lenne a megadható telefonszámok mennyiségét limitálni. Többféle nyilvántartásban is szerepelhet ugyanaz a munkahely megjelölésként. Ezeket felesleges volna többször is tárolni, megkockáztatva azt, hogy egy esetleges munkahelyeket listázó lekérdezés három-négy variánsban is megjelenítse ugyanazt az intézményt. Minden nyilvántartásba vett személynek van valamilyen szintű szakképesítése, diplomája, stb. Ezeket az oklevelekre vonatkozó információkat szintén összevontan lehet kezelni. Tipikus adatok: • • • •
Oklevél száma Kiállítási idő Kiállító intézmény Szakképesítés megnevezése
Több nyilvántartásban is szükséges az idegen nyelveket beszélő alkalmazottak nyelvvizsga szintjeit, oklevelét nyilvántartani. Ezek szintén összevonható, közös helyen tárolható adatok.
8.4
Gyógyszerészek alapnyilvántartása
8.4.1 Áttekintés Az egészségügyi tevékenység gyakorlása, mint az már ismert, a betegek érdekeit valamint az ellátás biztonságát védendő, engedélyhez kötött. Ahhoz, hogy valaki gyógyszerészként tevékenykedhessen, gyógyszerész végzettséggel kell rendelkeznie. Az itthon kiadott illetve külföldön megszerzett és honosított diplomák nyilvántartási kötelezettségéről az 1997-es Egészségügyi Törvény rendelkezik, e szerint a megszerzett szakképesítésről ún. alapnyilvántartást kell vezetni. Az alapnyilvántartás esetében - az ESzCsM megbízása alapján - a nyilvántartás működtetője az Engedélyezési és Közigazgatási Hivatal (EKH). Az alapnyilvántartás esetében a tanulmányok sikeres lezárásakor az oktatási intézmény jelenti be az adatokat.
Stubenvoll Bt
70 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
8.4.2 Entitások Az alapnyilvántartásban egyetlen entitás szerepel, mely a gyógyszerész törzslapja. Az adatnyilvántartás kulcsa a sorszám, melynek képzése A/nnnnn formában történik meg, ahol nnnnn: 1-99999.
«table» Gyógyszerésztörzs Sorszám : VARCHAR(1) Név : VARCHAR(1) Leánykori név : VARCHAR(1) Születési hely : VARCHAR(1) Születési idő : TIMESTAMP Anyja neve : VARCHAR(1) Állampolgársága : VARCHAR(1) Lakcím : VARCHAR(1) Szakképesítés megnevezése : VARCHAR(1) Oklevél, bizonyítvány száma : INTEGER Oklevél kiállítás helye : VARCHAR(1) Oklevél kiállítás időpontja : TIMESTAMP Oklevél kiállító intézmény : VARCHAR(1) Honosított oklevél által tanúsított szakképesítés : VARCHAR(1) Honosítás száma : INTEGER Honosítás helye : VARCHAR(1) Honosítás időpontja : TIMESTAMP Honosító intézmény : VARCHAR(1) Vizsga letételét tanúsító okirat száma : INTEGER Okirat kiállítás helye : VARCHAR(1) Okirat kiállítás időpontja : TIMESTAMP Okirat kiállító intézmény : VARCHAR(1)
8.4.3 Adatbázis információk Jelenleg nincs adatbázis információ, mivel adatbázis sincs. Az EKH által bemutatott tervek szerint ACCESS alapú adatbázis kezelő program készül ugyanazoknak a szakembereknek a segítségével, akik a MOK Regisztert is üzemeltetik.
8.4.4 Hozzáférési szabályozások Amíg nem áll fel az új, elektronikus nyilvántartás, nem ismertek ezek a paraméterek.
Stubenvoll Bt
71 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
8.4.5 Egységesítési ajánlások A gyógyszerésztörzs adatai az adatspecifikáció szerint teljesen azonosak az orvosokról tárolt törzsadatok nyilvántartási struktúrájával.
8.5
Gyógyszerészek működési nyilvántartása
8.5.1 Áttekintés Ugyancsak az Egészségügyi Törvény rendelkezik a gyógyszerészek működési nyilvántartási kötelezettségéről is; nyilvántartásba vétel hiányában ilyen irányú tevékenységet nem lehet folytatni. A kétféle nyilvántartás felállítására 2000 tavaszán került sor, miniszteri rendelet előírása alapján. A nyilvántartások vallott célja továbbá - egészségpolitikai vonatkozásban -, hogy tudni lehessen, hány gyógyszerész, milyen intézményekben, milyen munkahelyeken dolgozik ma az egészségügyben. A működési nyilvántartás esetében a nyilvántartás működtetője: a Magyar Gyógyszerész Kamara (MGYK). A működési nyilvántartásba vétel a gyógyszerész kérelmére történik.
8.5.2 Entitások Sajnos az entitásokról egy egyszerű tábla kapcsolati rajz kivételével semmit nem kaptunk, így nem tudjuk, hogy mely adatok kerülnek tárolásra ebben a nyilvántartásban. Valószínűsithető azonban, hogy az adatok köre nem tér el jelentősen a többi személyi nyilvántartástól.
«table» Személy 0..1 «table» Gyógyszertár
Stubenvoll Bt
*
* 1
«table» Képesítés
72 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
8.5.3 Adatbázis információk Az adatbázis mérete jelenleg ~50MB (+300MB fotó). 7300 gyógyszerész szerepel a működési nyilvántartásban. Napi változási forgalom: 2MB/nap Az adatbiztonságot napi mentés (tükrözés) biztosítja. Lekérdezések mennyisége: 10-100MB/nap
8.5.4 Hozzáférési szabályozások A hozzáférési jogosultságokról hivatalos információt nem kaptunk. Rendelkezésre állás: éjjel-nappal, minden nap (7/24)
8.5.5 Egységesítési ajánlások Mivel semmilyen értékelhető információ nem érkezett az entitások struktúrájáról, kivéve egy egyszerű tábla kapcsolati diagrammot, ezért az egységesítési ajánlásokat nem tudtuk megbízható alapokra helyezni. Ennek ellenére, az egyszerű ábra alapján feltételezhető, hogy a személyekre, a szakképesítésre és a munkahelyre vonatkozó adatok szétválaszthatóak. A feltételezés szintjén megemlíthetjük, hogy valószínűleg a személyhez és a munkahelyhez kötődő cím meghatározások szintén közös entitás halmazban ábrázolhatók. A szakképesítéshez valószínűleg oklevél, az oklevélhez pedig intézmény társul, melyek ugyancsak beleillenek a felvázolt összevont adatbázis struktúrába.
8.6
Klinikai szakpszichológusok alapnyilvántartása
8.6.1 Áttekintés Az egészségügyi tevékenység különböző szintű gyakorlása, a betegek érdekeit valamint az ellátás biztonságát védendő, engedélyhez kötött. Ahhoz, hogy valaki klinikai szakpszichológusként tevékenykedhessen, ilyen irányú végzettséggel kell rendelkeznie. Az
Stubenvoll Bt
73 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
itthon kiadott illetve külföldön megszerzett és honosított diplomák nyilvántartási kötelezettségéről az 1997-es Egészségügyi Törvény rendelkezik, e szerint a megszerzett szakképesítésről ún. alapnyilvántartást kell vezetni. Az alapnyilvántartás esetében - az ESzCsM megbízása alapján - a nyilvántartás működtetője az Engedélyezési és Közigazgatási Hivatal (EKH).
8.6.2 Entitás leírások Az alapnyilvántartás szempontjából egyetlen entitásról lehet beszélni, mely a klinikai szakpszichológus törzslapja alapján a következő információkat tartalmazza:
«table» Klinikai_szakpszichologustorzs Sorszám : VARCHAR(1) Név : VARCHAR(1) Leánykori név : VARCHAR(1) Születési hely : VARCHAR(1) Születési idő : TIMESTAMP Anyja neve : VARCHAR(1) Állampolgársága : VARCHAR(1) Lakcím : VARCHAR(1) Szakképesítés megnevezése : VARCHAR(1) Oklevél, bizonyítvány száma : INTEGER Oklevél kiállítás helye : VARCHAR(1) Oklevél kiállítás időpontja : TIMESTAMP Oklevél kiállító intézmény : VARCHAR(1) Honosított oklevél által tanúsított szakképesítés : VARCHAR(1) Honosítás száma : INTEGER Honosítás helye : VARCHAR(1) Honosítás időpontja : TIMESTAMP Honosító intézmény : VARCHAR(1) Vizsga letételét tanúsító okirat száma : INTEGER Okirat kiállítás helye : VARCHAR(1) Okirat kiállítás időpontja : TIMESTAMP Okirat kiállító intézmény : VARCHAR(1)
8.6.3 Adatbázis információk Az adatbázis mérete: jelenleg ~8-10MB. 630 klinikai szakpszichológus szerepel az alapnyilvántartásban. Napi változási forgalom: 0, 001MB/nap Az adatok Access adatbázisban vannak tárolva.
Stubenvoll Bt
74 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
8.6.4 Hozzáférési szabályozások Rendelkezésre állás: munkaidőben, heti öt napon. A hozzáférés korlátozásáról illetve jogosultságokról nem kaptunk információt.
8.6.5 Egységesítési ajánlások A nyilvántartásról túlságosan kevés adat áll rendelkezésünkre ahhoz, hogy megfelelő javaslatot tehessünk a többi adattárral való harmonizálásra. Annyi mindenesetre már most felismerhető, hogy a klinikai szakpszichológusok nyilvántartására várhatóan alkalmazni lehet azokat az ajánlásokat, melyeket a Magyar Orvosi kamara által tárolt orvosok működési engedélyére tettünk, vagyis a személy, cím, oklevél jellegű adatokat valószínűleg közösen kezelhető formára lehet hozni és ezen adatok közös tárolása megvalósítható.
8.7.1 Áttekintés Az Egészségügyi Törvény rendelkezik a klinikai szakpszichológus működési nyilvántartási kötelezettségéről is; nyilvántartásba vétel hiányában ilyen irányú tevékenységet nem lehet folytatni. A kétféle nyilvántartás felállítására 2000 tavaszán került sor, a már ismert miniszteri rendelet előírása alapján. A működési nyilvántartás esetében a nyilvántartás működtetője: az Egészségügyi Szakképző és Továbbképző Intézet (ETI).
8.7.2 Entitás leírások A szakpszichológusok működési nyilvántartása egy entitásból áll, mely tartalmazza az összes
klinikai szakpszichológus működési nyilvántartásának elektronikus feldolgozásához szükséges adatot.
Stubenvoll Bt
75 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
«table» Klinikai_szakpszichologus_mukodesi Sorszám : VARCHAR(1) Név : VARCHAR(1) Születési hely : VARCHAR(1) Születési idő : TIMESTAMP Anyja neve : VARCHAR(1) Állampolgársága : VARCHAR(1) Leánykori név : VARCHAR(1) Szakképesítés megnevezése : VARCHAR(1) Oklevél, bizonyítvány száma : INTEGER Képzést szervező intézmény neve : VARCHAR(1) Képzés időpontja : TIMESTAMP Képesítést szervező intézmény megnevezése : VARCHAR(1) Alapnyilvántartás száma : VARCHAR(1) Vizsga letételét tanúsító okirat száma : INTEGER Tudományos fokozat : VARCHAR(1) Nyilvántartási száma : VARCHAR(1) Kiállítás helye : VARCHAR(1) Kiállítás ideje : TIMESTAMP Kiállító intézmény megnev. : VARCHAR(1) Nyelvismeret foka : VARCHAR(1) Nyelv megnevezése : VARCHAR(1) Nyelvvizsga kiállítás helye : VARCHAR(1) Nyelvvizsga bizonyítvány száma : VARCHAR(1) Nyelvvizsga kiállítás időpontja : VARCHAR(1) Nyelvizsga kiállító intézmény megnevezése : VARCHAR(1) Előző nyilvántartási száma : VARCHAR(1) Korlátozott alkalmasság : BIT(1) Az eü. tev. egy évet meghaladó szünetelt. ideje : VARCHAR(1) Honosított oklevél által tanúsított szakképesítés : VARCHAR(1) Honosítás száma : INTEGER Honosítás helye : VARCHAR(1) Honosítás időpontja : TIMESTAMP Honosító intézmény : VARCHAR(1) Munkahely neve : VARCHAR(1) Lakcím : VARCHAR(1) Munkahely címe : VARCHAR(1) Beosztása : VARCHAR(1) Szakképesítés szerinti munkakörökben eltöltött évek száma szerinti gyakorlati pontszám : INTEGER Elméleti továbbképzés pontszáma : INTEGER
8.7.3 Adatbázis információk Az adatbázist az ETI 2003-ban vette át az ESzCsM Humánpolitikai Főosztályától. Az adatbázis mérete: jelenleg ~10-12MB. Mintegy 630 klinikai szakpszichológus szerepel a működési nyilvántartásban. Napi változási forgalom: 0, 001MB/nap
Stubenvoll Bt
76 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Az adatok Access adatbázisban vannak tárolva.
8.7.4 Hozzáférési szabályozások Nem ismeretesek.
8.7.5 Egységesítési ajánlások A nyilvántartásról túlságosan kevés adat áll rendelkezésünkre ahhoz, hogy megfelelő javaslatot tehessünk a többi adattárral való harmonizálásra. Annyi mindenesetre már most felismerhető, hogy a klinikai szakpszichológusok nyilvántartására várhatóan alkalmazni lehet azokat az ajánlásokat, melyeket a Magyar Orvosi kamara által tárolt orvosok működési engedélyére tettünk, vagyis a személy, cím, oklevél jellegű adatokat valószínűleg közösen kezelhető formára lehet hozni és ezen adatok közös tárolása megvalósítható.
8.8
Egészségügyi szakdolgozók alapnyilvántartása
8.8.1 Áttekintés Az egészségügyi tevékenység különböző szintű gyakorlása, a betegek érdekeit valamint az ellátás biztonságát védendő, engedélyhez kötött. Ahhoz, hogy valaki egészségügyi szakdolgozóként tevékenykedhessen, ilyen irányú szakképesítéssel kell rendelkeznie. Az eddig tárgyalt humánerőforrást érintő adatbázisokhoz hasonlóan - az 1997 évi CLIV. törvény 'az egészségügyről' 111. § és 112. § rendelkezése alapján - a nyilvántartások kettéosztódnak: alap-, és működési nyilvántartásra. Az alapnyilvántartás karbantartója az Egészségügyi Szakképző és Továbbképző Intézet (ETI). Az alapnyilvántartásba vétel, mint mindig, a szakképesítést kiadó intézmény bejelentése alapján történik, kötelező jelleggel. Elsősorban papíralapú nyilvántartás (kartonok), informatikai rendszer másodlagosan rögzíti az adatokat. Az alapnyilvántartást egy szekvenciaazonosító rögzíti, az az alapnyilvántartási szám, de azonosításra a Magyar Egészségügyi Szakdolgozói Kamara által adandó számot lehet majd használni, ezzel lehet a nyilvántartásokat később összekapcsolni.
8.8.2 Entitás leírások A szakdolgozók alapnyilvántartási adatlapja Stubenvoll Bt
77 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
«table» Egeszsegugyi_szakdolgozotorzs Törzslap száma : INTEGER Név : VARCHAR(1) Születési név : VARCHAR(1) Leánykori név : VARCHAR(1) Születési hely : VARCHAR(1) Születési idő : TIMESTAMP Anyja neve : VARCHAR(1) Állampolgársága : VARCHAR(1) Legmagasabb iskolai végzettség : VARCHAR(1) Szakképesítés megnevezése, azonosító száma : VARCHAR(1) Szakképesítést szervező intézmény neve, címe : VARCHAR(1) Vizsgát szervező intézmény neve, címe : VARCHAR(1) Bizonyítvány, oklevél száma : VARCHAR(1) A képesítést szervező intézmény neve, címe : VARCHAR(1) A vizsgát szervező intézmény neve, címe : VARCHAR(1) Az alapnyilvántartás száma : VARCHAR(1)
8.8.3 Adatbázis információk Mivel az adatok tárolása – jelenleg – együtt történik a működési nyilvántartással, az adatok az együttes adatbázisra vonatkoznak. Az adattartalom 1 000 000 rekord az adatbázisban, ~190 MB. ~450000 különböző egyed van az alapnyilvántartásban, ezek közül ~160000 került kapcsolatba az ETI-vel 1998 óta (minden bizonnyal ez a ténylegesen létező személyek száma) Adatváltozás az alapnyilvántartásban: 8000-10000 új egyed/év. Lekérdezések száma: kb. 200-800/nap. Az adatok tárolása SQL AB.Server rendszerben történik.
8.8.4 Hozzáférési szabályozások Nem ismertek.
Stubenvoll Bt
78 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
8.8.5 Egységesítési ajánlások A nyilvántartásról túlságosan kevés adat áll rendelkezésünkre ahhoz, hogy megfelelő javaslatot tehessünk a többi adattárral való harmonizálásra. Annyi mindenesetre már most felismerhető, hogy az egészségügyi szakdolgozók nyilvántartásárából várhatóan ugyancsak a személy, cím, oklevél jellegű adatokat lehet közösen kezelhető formára hozni, hasonlóan a Magyar Orvosi kamara által tárolt orvosok működési engedélyére tett ajánláshoz.
8.9
Egészségügyi szakdolgozók működési nyilvántartása
8.9.1 Áttekintés Az egészségügyi tevékenység különböző szintű gyakorlása, a betegek érdekeit valamint az ellátás biztonságát védendő, engedélyhez kötött. Ahhoz, hogy valaki egészségügyi szakdolgozóként tevékenykedhessen, ilyen irányú szakképesítéssel kell rendelkeznie. Az eddig tárgyalt humánerőforrást érintő adatbázisokhoz hasonlóan - az 1997 évi CLIV. törvény 'az egészségügyről' 111. § és 112. § rendelkezése alapján - a nyilvántartások kettéosztódnak: alap-, és működési nyilvántartásra. A nyilvántartást egyelőre az ETI vezeti, de 2004. október 31. után valószínűleg át kell adnia a Magyar Egészségügyi Szakdolgozói Kamara (MESZK) számára. Az alapnyilvántartásban is említett MESZK (kamarai szám) azonosításon túl speciális működési nyilvántartási kód képződik, a szakképzési szintek alapján: .<szakmai kód>.<sorszám>/<év> formában. Pl. D.6.5358/2002 (D: diplomás, 6: védőnő, 5358. sorszám, 2002: év)
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
«table» Egeszsegugyi_szakdolgozok_mukodesi Törzslap száma : INTEGER Név : VARCHAR(1) Születési név : VARCHAR(1) Születési hely : VARCHAR(1) Születési idő : TIMESTAMP Anyja neve : VARCHAR(1) Állampolgársága : VARCHAR(1) Lakcíme : VARCHAR(1) Szakképesítés megnevezése : VARCHAR(1) Szakképesítést szervező intézmény neve, címe : VARCHAR(1) Vizsgát szervező intézmény neve, címe : VARCHAR(1) Bizonyítvány, oklevél száma : VARCHAR(1) Nyelvvizsga típusa : VARCHAR(1) Korlátozott alkalmasság jelzése : VARCHAR(1) Szüneteltetett tevékenység jelzése : VARCHAR(1) Munkahely neve : VARCHAR(1) Munkahely kódszáma : VARCHAR(1) Munkahely címe : VARCHAR(1) Munkakör és kódszáma : VARCHAR(1) Gyakorlati pontszám : INTEGER Elméleti továbbképzés pontszámai : INTEGER
8.9.3 Adatbázis információk Az adatok tárolása – jelenleg – együtt történik a működési nyilvántartással, az adatok az együttes adatbázisra vonatkoznak. 1 000 000 rekord az adatbázisban, ~190 MB adattartalom A kiadott működési nyilvántartási kártyák sorszáma jelenleg 135 ezernél tart. Becsült változásforgalom: kb. 20 MB/nap Lekérdezések száma: kb. 200-800/nap. Az adatok tárolása SQL AB.Server rendszerben történik.
8.9.4 Hozzáférési szabályozások Nem ismertek.
8.9.5 Egységesítési ajánlások
Stubenvoll Bt
80 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
A nyilvántartásról túlságosan kevés adat áll rendelkezésünkre ahhoz, hogy megfelelő javaslatot tehessünk a többi adattárral való harmonizálásra. Annyi mindenesetre már most felismerhető, hogy az egészségügyi szakdolgozók nyilvántartásárából várhatóan ugyancsak a személy, cím, oklevél jellegű adatokat lehet közösen kezelhető formára hozni, hasonlóan a Magyar Orvosi kamara által tárolt orvosok működési engedélyére tett ajánlásához.
8.10 Gyógyszerek nyilvántartása 8.10.1
Áttekintés
A gyógyszerek nyilvántartására 2004-ben elkészült a K-NET nevű programcsomag, amely a gyógyszerek törzskönyvezési folyamatát, mint eljárást van hivatva lebonyolítani, és tárolja mindazokat a közbenső – és esetenként szigorúan bizalmas – adatokat is, melyek e folyamat során az egyes résztvevő intézményeknél képződnek. A törzskönyvezési folyamat eredményeként minden engedélyezett gyógyszerről összeáll egy publikus adathalmaz, amelynek tartalma hivatalosan kihirdetésre is kerül. Ezt az adathalmazt bárki lekérdezheti az EKNy rendszer kérelmezési felületén, más adat viszont még megfelelő jogosultságok megléte esetén sem kérdezhető le az EKNy-en keresztül, csak közvetlenül a K-NET felületén. A K-NETről elegendő azt az adatstruktúrát ismerni, amely a K-NET rendszerben eredményesen végigvitt folyamatok végeredményeként egy engedélyezett gyógyszer jogszabály szerint publikus adatait tartalmazza. Ezt az adatstruktúrát képezzük le az EKNy rendszerben, majd az adatokat tükrözéssel töltjük fel a K-NET-ből. A frissítést az EKNy rendszer a K-NET felől érkező trigger üzenet hatására végzi el, valahányszor a K-NET publikus adatbázisa megváltozott.
8.10.2
Stubenvoll Bt
Entitás leírások
81 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
A K-NET, mint az Áttekintésben már említettük, egy önmagában sokrétű, nagymennyiségű adatot tartalmazó rendszer, melynek csak igen kis része publikus és közhiteles. Az adatbázis egészéről nem áll információ rendelkezésre, a publikus rész tükrözéssel másolásra kerül az EKNy rendszerben, de ennek a résznek sem kaptuk meg a méretét.
8.10.4
Hozzáférési szabályozások
A gyógyszertörzs fent ismertetett adatai publikusak, korlátozás nélkül hozzáférhetők. További adat a gyógyszernyilvántartásból nem publikus, és csak megfelelő jogosultsággal, és csak közvetlenül férhető hozzá a K-NET rendszer felületén.
8.10.5
Egységesítési ajánlások
A gyógyszer adatbázisra nincs értelme egységesítési ajánlást tenni, mivel az adatstruktúra egyedi és nem tartalmaz más adatbázissal közös elemeket.
Stubenvoll Bt
82 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
8.11 Szolgáltatók nyilvántartása 8.11.1
Áttekintés
A nyilvántartás kialakításának alapvető célja - az egyelőre még hatályban lévő jogszabály alapján - az egészségügyi szolgáltatók nyilvántartásba vétele, azonosítása, a működés főbb kapacitásjellemzőinek és a szolgáltatók részére kiadott működési engedélyek lajstromba vétele. Az egészségügyi szolgáltatókat függetlenül attól, hogy magán vagy közintézményről van szó, tartalmaznia kell az adatbázisnak. A működési engedélyek részletezik az engedélyezett szakmákat is, ez utóbbi ad választ a 'milyen tevékenységet' kérdésre. A szolgáltatók nyilvántartását az Állami Népegészségügyi és Tisztiorvosi Szolgálatnak a szolgáltató működési helye szerint területileg illetékes megyei (fővárosi) intézete, az országos nyilvántartást, mint országos adatkezelő az Országos Tisztifőorvosi Hivatal vezeti - mondja ki az egyelőre még hatályos 32-es NM rendelet. Az adatok elsődleges nyilvántartója az ANTSZ illetékes városi/megyei intézete. Az (ágazati) azonosító felépítése Intézmények esetén: 1.
2.
Megye, kerület kód
3.
4.
Intézet sorszáma
5. Ellátás kódja
6.
7.
8.
9.
Eü. szakmai kódjegyzék sz. jelölés Szakfeladat Az egység kódja
Kódmagyarázat: Ellátás kódja: 1 2 3 4 5 6-9 A C G K R P M S
Aktív fekvőbeteg ellátás Járóbeteg-szakellátás, a központi diagnosztika, terápia Nappali kórház Szanatórium Egyéb egészségügyi szolgálat Foglalt Ápolási otthon és osztály Krónikus fekvőbeteg-ellátás Gondozóintézeti ellátás Kúraszerű ellátás Rehabilitáció (fekvő) Rehabilitáció (járó) Mátrix egység Mozgó szakorvosi szolgálat
Önálló járóbeteg-szakellátó rendelések esetén:
Stubenvoll Bt
83 / 141
Budapest, 2004 szeptember 30
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
eEgészség Program – 27. projekt
1.
2.
3.
Megye, kerület kód
4.
5. Ellátás kódja (6,7,8)
00
6.
7.
8.
9.
Eü. szakmai kódjegyzék sz. jelölés Szakfeladat Az egység kódja
Háziorvosok (egyéb ellátók) esetén: 1.
2.
Megye, kerület kód
3.
4.
5.
009
6.
7.
8.
9.
Alapszolgáltató azonosító szakterületi kód
Kódmagyarázat: Szakterületi kód tartományok 0001-4499 Felnőtt vagy vegyes háziorvosi szolgálat 4500-4999 Felnőtt, gyermek vagy vegyes háziorvosi ügyelet 5000-5999 Gyermek háziorvosi szolgálat 6000-6999 Fogászati alapellátás 7000-7399 Iskola, óvodai és egyéb oktatási intézet orvosa 7400-7999 Védőnői szolgálat 8000-8499 Foglalkozás-egészségügyi szolgálatok 8500-8999 Egyéb közösségi intézetek alapellátását végző orvosok 9000-9499 Otthoni gondozás, ápolás 9500-9999 Egyéb alapellátási feladatokra fenntartva
8.11.2
Entitás leírások
Intézet Intézeteket megfogalmazó, meghatározó entitás.
Stubenvoll Bt
84 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Az adatbázis mérete jelenleg ~74MB. Az adatokat nem relációs adatbázis rendszerben (DBMS) tárolják, hanem egyszerű DBF fájlokban, speciális kliensalkalmazás által való hozzáférést biztosítva. Az adatkapcsolat megvalósítása az adatállományok másolásával történik. Rendelet szabályozza az adatfrissítés módját, eszerint a változásokat 15 napon belül be kell jelenteni (rögzíteni). Lekérési gyakoriság: havonta adatszolgáltatás az OEP felé. Egyébként ritka a hozzáférés az adatokhoz. (2003-as adat szerint 67 db/év az OTH-ban).
Stubenvoll Bt
88 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
8.11.4
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Hozzáférési szabályozások
A 32/1997. (X.28.) NM rendeletben meghatározott nyilvántartás adatai a 7.§. (1) szerint nyilvánosak. A jogszabály megfogalmazásában: "közérdekűek". Rendelkezésre állás ideje: munkanap 8 órától 16.30-ig. Hozzáférés módja: lokális gépeken adott felhasználók jelszóval. Az egyes intézeteknél történő lekérdezésekről nincs tudomása az OTH informatikai főosztályának.
8.11.5
Egységesítési ajánlások
Az adatstrukturából az • •
Intézet, valamint a Nemintézet
entitás, melyek struktúrája egyforma, kiemelhető, és maga is tartalmaz • •
cim és telefonszám
adatokat. Ezek mentén elképzelhető a többi közhiteles adatstruktúrával való harmonizálás.
8.12 Országos Transzplantációs Nyilvántartás 8.12.1
Áttekintés
Az ÁNTSZ másik, közhitelesnek tartott nyilvántartása az Országos Transzplantációs Nyilvántartás (OTNY). Szabályozott keretek között működik ötödik esztendeje. Létrehozatalát az 1997-es Egészségügyi Törvény megszületése segítette elő. Magyarországon minden állampolgár elhalálozása illetve agyhalál állapotba kerülése esetén belső szervei, szövetei felhasználhatóak, átültethetőek más, nem feltétlenül magyar állampolgárba. Ez alól kivételt csak azok az esetek jelenthetnek, amikor az állampolgárok még életükben tiltakozó nyilatkozatot készítenek e kivétel ellen. A tiltakozó nyilatkozatokat a betegek maguknál tarthatják, de szigorúan szabályozott körülmények közepette (személyesen, ajánlott postai küldeményként, háziorvos segítségével) eljuttathatják az egészségügyi hatóságokhoz, az Országos Közegészségügyi Központba, így azok biztosan nem kallódnak el a kritikus pillanatokban. Ezeket a nyilatkozatokat tartják nyilván az Országos Transzplantációs Nyilvántartásban. A nyilvántartásból való kikerülés módja is ugyanolyan precízen szabályozott, mint a bekerülés módja.
Stubenvoll Bt
89 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Több ország ettől eltérő szabályozási gyakorlatot folytat, amikor a transzplantáció céljára kivehető szervek, szövetek eltávolításáról esik szó. Ezen országokban csak akkor adnak lehetőséget állampolgárok szerveinek felhasználására, ha pozitív, beleegyező nyilatkozat születik e tekintetben. Nálunk az a félelem él, hogy az állampolgári tudatosság jelenlegi szintje nem tenne elérhetővé elegendő szervet, ezért az egészségügyi kormányzat úgy foglalt állást, csupán a tiltakozó nyilatkozatnak ad helyt. Egészen 2004 elejéig az ÁNTSZ OTH volt az OTNY működtetője, de február 21.-től kezdődően - a 24 órás működtetés biztosítása érdekében - átkerült a Fodor József Országos Közegészségügyi Központhoz (OKK). Az átadásról a 74/2003 (XII.23.) ESzCsM rendelet adott felhatalmazást az OTH számára.
8.12.2
Entitás leírások
Az OKK nem kívánta megosztani velünk az általunk kért információkat, az adatbázis nem nyilvános mivoltára utalva. További információkhoz jutás érdekében minisztériumi közvetlen utasításra lenne szükség, az intézmény vezetése ugyanis nem híve semmilyen nyilvánosságnak, még olyan vonatkozásban sem, mely adatokat, milyen formátumban rögzítik.
8.12.3
Adatbázis információk
Rendelkezésünkre álló statisztikák szerint 2004. január 10-ig 672 tiltakozást adtak le, abból jelenleg 381 az érvényes tiltakozások regisztrált száma, 2 hiánypótlásos, 284 esetben vonták vissza a tiltakozást, míg 5 a száma a hiánypótlásos visszavonásoknak.
8.12.4
Hozzáférési szabályozások
Az OTNY adatai nem nyilvánosak. Ebben az évben 112 egészségügyi intézmény regisztráltatta magát az adatbázis jogosult használatára, ezekben az intézményekben összesen 919 azon kijelölt egészségügyi dolgozók száma, akik felhatalmazottak az adatbázisból való lekérdezésre. Ezek száma 1999 óta meghaladta az 1100-at. Az OTNY adatszolgáltatása az intézmények felé 24 órás.
8.12.5
Egységesítési ajánlások
Mivel az adatbázis tartalma nem ismert, az egységesítésre sem tudunk ajánlást tenni.
Stubenvoll Bt
90 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
8.13 TAJ nyilvántartás 8.13.1
Áttekintés
„A TAJ kártya segítségével vehetők igénybe egészségügyi szolgáltatások Magyarországon, térítés mentesen - legalábbis azon szolgáltatások esetében, ahol az 1997-es Egészségbiztosítási Törvény erre módot ad. A TAJ kártya tartalmazza a TAJ számot, amelyről az OEP-nek nyilvántartást kell vezetnie. E nyilvántartás közhitelesnek mondott/vélt, amely hitelessé formálásába sok energiát ölt a Pénztár. Sziszifuszi munkával kísérlik meg - egyre gyarapodó sikerrel - az 1992-ben kiadott, háziorvos választására is alkalmassá tett, 'Személyazonosító Jellel' ellátott, társadalombiztosítási kártyák, illetve az azokat később felcserélő TAJ kártyák közül azok szűrését, amelyek egy-egy állampolgár számára halmozottan kerültek kiadásra, vagy éppen mára érvénytelenné váltak. Az érvényesnek tekintett TAJ kártyák száma mára 10 133 ezerre lecsökkent. Ez a korábbi 14 000 ezres TB kártya nagysághoz viszonyítva jelentős mértékű javulást mutat. A nyilvántartás problémájának még mindig meglévő súlyát azonban jelzi az az OEP becslés, miszerint 300-800 ezer között valószínűsíthető azon magyar állampolgárok száma, akiknél nem tisztázott, milyen jogosultsággal rendelkeznek a TAJ kártya használata során. A TAJ szám az egészségügyi (és egyéb, társadalombiztosítási) szolgáltatást igénybe vevő személyek azonosítását szolgálja. A TAJ szám tehát egy személyi azonosító, amelyet a magyar állampolgár születésekor kap, és amely - normál esetben - végigkíséri egész élete során. A TAJ számot az Országos Egészségbiztosítási Pénztár képezi. A TAJ nyilvántartás ezen azonosítók közhiteles formában történő tárolását biztosítása - célja szerint. Külföldi állampolgár is kaphat TAJ számot, ha biztosítási jogviszonyt létesít, vagy megállapodást köt egészségügyi szolgáltatásokra való jogosultság megszerzésére, illetve akkor is, ha a biztosított vagy az egészségügyi szolgáltatásra jogosult személy közeli hozzátartozójának minősül. Már ebben a szakaszban érdemes felhívni a figyelmet arra, hogy szemben mindenfajta hiedelemmel - amelytől korábban nem volt mentes jelen tanulmány írója sem -, a TAJ kártyák ma az egészségügyi szolgáltatások iránt az állampolgárok háromnegyede esetében igazolnak csupán hitelt érdemlően igénybevételi jogosultságot. A z Országos Egészségbiztosítási Pénztár a TAJ számok nyilvántartásának gazdája. A TAJ nyilvántartás - tekintettel a benne foglalt személyes adatok jellegére - nem nyilvános.”
8.13.2
Entitás leírások
A TAJ esetében nincsenek entitások meghatározva, mivel az adatok nem kerülnek át az EKNy rendszerébe. Ezeket az adatokat csak távoli, pillanatnyi lekérdezéssel lehet megkapni, mely függvényhívással kerül megvalósításra. Stubenvoll Bt
91 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
A függvény meghívása a TAJ számra vonatkozó információk paraméterben történő átadásával történik, aminek eredményeként visszaigazolás érkezik, hogy a TAJ érvényes azonosító-e vagy sem.
8.13.3
Hozzáférési szabályozások
A TAJ rendszer szolgáltatásai az OEP más alkalmazásaiból interfészeken keresztül érhetőek el. Az interfészek Oracle tárolt eljárások, amelyek: • • • •
valamilyen adatlekéréseket teljesítenek a TAJ rendszer adatbázisából; az OEP különböző alkalmazásaiból meghívhatók; a konkrét kérdéseket bemenő paraméterekben adott értékek formájában várják; a válaszokat pedig a kimenő paraméterek értékeként adják vissza.
Az interfészekhez való hozzáférés kezelése Oracle DBMS szinten történik a TAJ_ITF_ROLE szerepkör révén. Ez a szerepkör fel van ruházva az összes jogosultsággal, amely az interfész objektumok eléréséhez szükséges. A hívó alkalmazások a számukra rendelkezésre bocsátott Oracle felhasználói azonosítóval érik el az interfészeket.
8.14 Szakmai kódnyilvántartások (BNO, FNO, OENO, HBCS) 8.14.1
Áttekintés
„A szakmai kódok kialakításának alapvető célja, hogy segítsék az egészségügyi szolgáltató intézmények tevékenységének dokumentálhatóságát, ellenőrizhetőségét és elősegítsék az intézmények finanszírozását. A szakmai kódokat tartalmazó adatbázisok kialakításának célja, hogy stabil, nyomon követhető, ellenőrizhető módon történjen a betegségek, tevékenységek, beavatkozások azonosítása, csoportosítása. A kódrendszerek karbantartója jelenleg az OEP Finanszírozási Informatikai Főosztálya (régebben GYÓGYINFOK). E téren rövidesen változás áll elő, mivel a szakmai kódok közül a BNO, OENO, FNO felülvizsgálata, frissítése, és közzététele hamarosan az Egészségügyi Stratégiai Kutatóintézethez kerül. A BNO (Betegségek Nemzetközi Osztályozása) az ENSZ Egészségügyi Világszervezete (WHO) által közzétett „Betegségek és az egészséggel kapcsolatos problémák nemzetközi statisztikai osztályozása”. 1996. január 1. napjától minden olyan dokumentáción, illetve adatszolgáltatási kötelezettség teljesítésénél, amikor külön jogszabály alapján a betegségeket kódjelekkel fel kell tüntetni, a Tizedik Revízió” (BNO-10) alkalmazandó. A Stubenvoll Bt
92 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
betegségek osztályozása segítő rendszerként működik a HBCS számára is, lehetővé téve ezáltal a teljesítményelvű finanszírozást az aktív fekvőbetegellátásban. Az OENO (Orvosi Eljárások Nemzetközi Osztályozása) a vizsgálatok, beavatkozások, eljárások osztályzását jelenti. E beavatkozásokat, eljárásokat kóddal jelölik meg a tevékenységek besorolása érdekében. OENO kódok használata technikai segítséget jelent a mind a járó-, mind pedig a fekvőbetegellátás finanszírozásában. Ahogyan a HBCS, úgy az OENO is kiegészítve finanszírozási paraméterekkel (pontokkal), besorolási algoritmusként is értelmezhető, ezért ott is megjelenítésre kerül. Az FNO (Funkciók Nemzetközi Osztályozása) standard nyelvezet a betegek funkcionális állapotának leírására. Közvetlen kapcsolatban áll a BNO-val. Az FNO kódok F típussal a BNO kódok rovatban jelenthetők. E jelentés a krónikus minősítésű és pszichiátriai osztályok számára kötelező, de finanszírozásuk módja egyelőre változatlan. A kódok gyűjtésének célja a krónikus betegségek ápolási igényeinek felmérése. Segítségével egy megbetegedett szervrendszer kóros funkcionális állapotát lehet standardizált körülmények között leírni, jelezve a rehabilitáció vagy krónikus kezelés irányát és indokoltságát. A tanulmány első felében már jeleztük, nem egyértelmű, hova sorolható a HBCS (Homogén Betegségcsoportok). Tekinthetnénk szakmai kódnak és finanszírozási algoritmusnak egyaránt, hiszen csak a HBCS segítségével kerülhet sor az aktív fekvőbetegellátás finanszírozására. Bizonytalanságunkat fokozta, hogy a 6/1998-as NM rendelet csupán a BNO-val és az OENO-val kapcsolatosan fogalmaz meg karbantartási feladatokat, a szakmai kódrendszerek témájában. Ugyanakkor Kincses Gyula egyik előadásában, amelyet már idéztünk korábban, ugyancsak a kódrendszerek között tárgyalta a HBCS-t. Végül azt a megoldást választottuk, hogy a homogén betegségcsoporti törzsállományt, amelyik súlyszámok nélkül tartalmazza a lehetséges csoportokat, kódelnevezéseket, kódjegyzéket, a szakmai kódok közé soroltuk, tehát egyfajta klasszifikációnak tekintettük. Ellenben azt a változatot, amelyik súlyszámot is tartalmaz, illetve besorolja meghatározott szempontok alapján a szolgáltatói teljesítményeket, az algoritmusok közé tettük.”
8.14.2
Entitás leírások
BNO
Stubenvoll Bt
93 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Betegségek Nemzetközi Osztályozása (BNO) esetén: • •
a jelenlegi rekordszám: 11473 rekord kisebb alábontásokat kivéve csak verzióval változik jelenlegi a X.
Funkciók Nemzetközi Osztályozása (FNO) esetén: • •
a jelenlegi rekordszám: 288 rekord még nincs tapasztalat a változás mértékéről.
Stubenvoll Bt
94 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Orvosi Eljárások Nemzetközi Osztályozása (OENO) esetén: • •
a jelenlegi rekordszám: 4392 rekord, ritkán változik.
Homogén betegségcsoportok (HBCS) esetén: • •
a jelenlegi rekordszám: 786 rekord évente változik kismértékben.
8.14.4
Hozzáférési szabályozások
Mindegyik adatbázis nyilvános, az FNO kivételével a GYÓGYINFOK honlapjáról letölthető (www.gyogyinfok.hu/kod.htm). Az FNO az OEP honlapon keresztül érhető el és tölthető le (www.oep.hu), de önálló kiadványok illetve rendeletek mellékleteként is megjelentetésre kerülnek.
8.14.5
Egységesítési ajánlások
Az adatstruktúra meglehetősen egyszerű és világos. Ezen egyszerűsítési, összevonhatósági lehetőséget felfedezni különösebben nem érdemes.
„A finanszírozási algoritmusok definiálása igen kényes kérdés, nem egyértelmű, mit tekintünk e kategóriába sorolhatónak. Mi e tanulmány keretei között besorolási szabályokat értünk alatta, s elsősorban a HBCS, OENO, a fogászati ellátás illetve a kísérleti szakaszban lévő KBCS (krónikus betegségcsoportok) vonatkozásában értelmezzük. Ez azt jelenti, hogy besorolási szabályként értelmezzük a szabálykönyveket valamint a besorolási kézikönyveket. A felsorolt témák közül most a HBCS illetve az OENO kerül megtárgyalásra. Fontos hangsúlyozni, hogy nem tartjuk ide értendőnek az összes finanszírozási szabályt, elszámolási rendet, amely a 43/1999-es Kormányrendelet mellékletét képezi, azaz, amely kitér a többi között a CT/MR, vagy a művese finanszírozási szabályaira is. A finanszírozási besorolási szabályok közhiteles nyilvántartásának célja, hogy a kifizetések, a teljesítmény elszámolások az egészségügyi szolgáltató intézmények számára
Stubenvoll Bt
95 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
átlátható, ellenőrizhető módon történjenek. Ma ezek nem nyomon követhetőek a szolgáltatóknak, s ez rendkívül komoly feszültséget okoz az OEP és az intézmények között meglévő, egyébként szerződésgarantált kapcsolatban. A nyilvántartás működtetője jelenleg az OEP Finanszírozási Informatikai Főosztálya (régebben GYÓGYINFOK).”
8.15.2
Entitás leírások
A soron következő leírások a finanszírozási algoritmusok egy szűk spektrumára vonatkoznak, de mindaddig, amíg nem születik egyezség arról, mi minden tartozzon ide, csak e leszűkített keretek között, a besorolási szabályok szintjén tárgyaljuk e kérdéskört. OENO finanszírozás «table» OENO finan oeno_kod : CHAR(5) nev : VARCHAR(80) lehet_jaro : CHAR(1) lehet_fekvo : CHAR(1) lehet_ferfi : DECIMAL(1, 0) lehet_no : DECIMAL(1, 0) kortol : DECIMAL(3, 0) korig : DECIMAL(3, 0) pont : DECIMAL(6, 0)
Orvosi Eljárások Nemzetközi Osztályozása (OENO) esetén:
Stubenvoll Bt
96 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
•
a jelenlegi rekordszám: 4392 rekord,
•
ritkán változik.
Homogén betegségcsoportok (HBCS) esetén: •
a jelenlegi rekordszám: 786 rekord
•
évente változik kismértékben.
8.15.4
Hozzáférési szabályozások
Hozzáférési jogosultságokról hivatalos információt nem kaptunk. Az adatbázisok szabálykönyv illetve besorolási kézikönyv formájában léteznek, ugyanakkor elektronikus formában a GYÓGYINFOK honlapjáról olyan, ún. kisgépes, PC-s változatuk tölthető le, amely csak 90-95%-os pontossággal eredményezi az OEP/GYÓGYINFOK besorolást, legalábbis a HBCS esetében.
8.15.5
Egységesítési ajánlások
Mind az OENO mind a HBCS finanszírozási alapot érdemes összevonni az előző fejezetben bemutatott OENO és HBCS kódokkal.
8.16 További, ajánlott nyilvántartások Dr. Sinkó Eszter idézett tanulmány 3. fejezetében további nyilvántartások közhitelessé tételét javasolja, ezek: Engedélyezett orvostechnikai eszközök Társadalombiztosítás által finanszírozott gyógyászati segédeszközök Engedélyezett egészségügyi/orvosi beavatkozások, eljárások Ahhoz, hogy az uj nyilvántartások könnyen beilleszthetők legyenek az EKNy rendszerbe, célszerű néhány szempontot figyelembe venni. •
Javasoljuk, hogy az adatbázis-struktura legyen normalizált a harmadik szinten.
•
A kialakítás során vegyék figyelembe a 10. fejezetben ismertetett javaslatot a harmonizálásra, és lehetőség szerint az ott ismertetett táblák kerüljenek felhasználásra az adatstruktúra definiálásakor.
Stubenvoll Bt
97 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
•
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Az adatbázis legyen SQL alapú (nem Access), ahol a tárolt adatok méretétől és biztonsági kezelésétől függően széles skálán lehet az adatbázis rendszerét kiválasztani (az ingyenes MySQL-től a professzionális de drága Oracle-ig)
Stubenvoll Bt
98 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
9 Az EKNy rendszer közös adatmodellje Az EKNy rendszer a 8.1 pontban felsorolt nyilvántartásokat kell magába foglalja. A 12.1 pontban az adattárolás módjának taglalásakor rögzítjük, hogy ezek közül a személyi nyilvántartásokat, a gyógyszernyilvántartás publikus részét, a szolgáltatók nyilvántartását valamint a kódrendszereket az EKNy rendszerben magában is tároljuk, rendszeres frissítéssel létrehozva az eredeti nyilvántartások azonos adattartalmú tükrét, míg a transzplantációs nyilvántartáshoz és a TAJ-hoz tárolt függvények segítségével férhetünk hozzá, vagyis ez utóbbi lekérdezésekhez adattárolásra nincs szükség. A felsorolt adattükrök tárolása érdekében létre kell hozni az EKNy rendszer saját adatbázisát. Ez az adatbázis pontosan meg kell feleljen a forrás-adatbázisok adatmodelljének. Az egyes forrás nyilvántartások adatmodelljeit a 8.2 - 8.15 pontokban részletesen ismertettük. Ezek ismeretében az EKNy adatmodellje az alábbi fejezetekben ismertetett sémával írható le.
9.1
Közös adatmodell csoportjai
A közös adatmodell a meglévő nyilvántartási rendszer csoportjaiból épül fel. Az EKNy rendszer megvalósításának első szintjén még nem igény az adatok harmonizált kezelése, ezért az egymással átfedésben lévő adatok, adott esetben duplikáltan tárolhatnak információkat.
Stubenvoll Bt
99 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Mivel az orvosok alapnyilvántartásáról nem kaptunk konkrét adatstruktúra leírást, így csak azt tudjuk kikötni, hogy az orvosok alapnyilvántartásba vételekor kitöltendő űrlap tartalmának minden részlete az EKNy rendszerébe vélhetőleg átkerülhet.
Stubenvoll Bt
100 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
A rendszer megvalósításának során ezeket az adatstruktúrákat be kell szerezni, és ezek alapján a rendszer adatbázis terveit módosítani kell. «table» Orvostörzs Sorszám : VARCHAR(1) Név : VARCHAR(1) Leánykori név : VARCHAR(1) Születési hely : VARCHAR(1) Születési idő : DATE Anyja neve : VARCHAR(1) Állampolgársága : VARCHAR(1) Lakcím : VARCHAR(1) Szakképesítés megnevezése : VARCHAR(1) Oklevél, bizonyítvány száma : INTEGER Oklevél kiállítás helye : VARCHAR(1) Oklevél kiállítás időpontja : DATE Oklevél kiállító intézmény : VARCHAR(1) Honosított oklevél által tanúsított szakképesítés : VARCHAR(1) Honosítás száma : INTEGER Honosítás helye : VARCHAR(1) Honosítás időpontja : DATE Honosító intézmény : VARCHAR(1) Vizsga letételét tanúsító okirat száma : INTEGER Okirat kiállítás helye : VARCHAR(1) Okirat kiállítás időpontja : DATE Okirat kiállító intézmény : VARCHAR(1)
9.3
Orvos működési nyilvántartás
A megkapott orvosok működési nyilvántartása strukturális egésszé állt össze, melynek tükrözése megoldható. Sajnos a szöveges mezők hosszáról információt nem kaptunk, ezért mindenhol az 1 hosszúság szerepel.
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Gyógyszerész alapnyilvántartás
Mivel a gyógyszerészek alapnyilvántartásáról nem kaptunk konkrét adatstruktúra leírást, így csak azt tudjuk kikötni, hogy a gyógyszerészek alapnyilvántartásba vételekor kitöltendő űrlap tartalmának minden részlete az EKNy rendszerébe vélhetőleg átkerülhet. A rendszer megvalósításának során ezeket az adatstruktúrákat be kell szerezni, és ezek alapján a rendszer adatbázis terveit módosítani kell. «table» Gyógyszerésztörzs Sorszám : VARCHAR(1) Név : VARCHAR(1) Leánykori név : VARCHAR(1) Születési hely : VARCHAR(1) Születési idő : TIMESTAMP Anyja neve : VARCHAR(1) Állampolgársága : VARCHAR(1) Lakcím : VARCHAR(1) Szakképesítés megnevezése : VARCHAR(1) Oklevél, bizonyítvány száma : INTEGER Oklevél kiállítás helye : VARCHAR(1) Oklevél kiállítás időpontja : TIMESTAMP Oklevél kiállító intézmény : VARCHAR(1) Honosított oklevél által tanúsított szakképesítés : VARCHAR(1) Honosítás száma : INTEGER Honosítás helye : VARCHAR(1) Honosítás időpontja : TIMESTAMP Honosító intézmény : VARCHAR(1) Vizsga letételét tanúsító okirat száma : INTEGER Okirat kiállítás helye : VARCHAR(1) Okirat kiállítás időpontja : TIMESTAMP Okirat kiállító intézmény : VARCHAR(1)
9.5
Gyógyszerészek működési nyilvántartása
A gyógyszerészek működési nyilvántartásának adatbázis struktúrájáról szinte semmilyen információnk nincsen. Feltehetően személyi, munkahelyi, végzettségi adatok megtalálhatóak benne, de ezen adatok konkrét felépítése nem ismert, ezért még közelítőleges ajánlást sem tudunk adni az EKNy rendszerbe kerülésükről. A rendszer megvalósításának során ezeket az adatstruktúrákat be kell szerezni, és ezek alapján a rendszer adatbázis terveit módosítani kell.
Stubenvoll Bt
103 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
9.6
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Klinikai szakpszichológusok alapnyilvántartása
Mivel a klinikai szakpszichológusok alapnyilvántartásáról nem kaptunk konkrét adatstruktúra leírást, így csak azt tudjuk kijelenteni, hogy a klinikai szakpszichológusok alapnyilvántartásba vételekor kitöltendő űrlap tartalmának minden részlete az EKNy rendszerében vélhetőleg átkerülhet. A rendszer megvalósításának során ezeket az adatstruktúrákat be kell szerezni, és ezek alapján a rendszer adatbázis terveit módosítani kell. «table» Klinikai_szakpszichologustorzs Sorszám : VARCHAR(1) Név : VARCHAR(1) Leánykori név : VARCHAR(1) Születési hely : VARCHAR(1) Születési idő : TIMESTAMP Anyja neve : VARCHAR(1) Állampolgársága : VARCHAR(1) Lakcím : VARCHAR(1) Szakképesítés megnevezése : VARCHAR(1) Oklevél, bizonyítvány száma : INTEGER Oklevél kiállítás helye : VARCHAR(1) Oklevél kiállítás időpontja : TIMESTAMP Oklevél kiállító intézmény : VARCHAR(1) Honosított oklevél által tanúsított szakképesítés : VARCHAR(1) Honosítás száma : INTEGER Honosítás helye : VARCHAR(1) Honosítás időpontja : TIMESTAMP Honosító intézmény : VARCHAR(1) Vizsga letételét tanúsító okirat száma : INTEGER Okirat kiállítás helye : VARCHAR(1) Okirat kiállítás időpontja : TIMESTAMP Okirat kiállító intézmény : VARCHAR(1)
Mivel a klinikai szakpszichológusok működési nyilvántartásából nem kaptunk konkrét adatstruktúra leírást, így csak azt tudjuk kijelenteni, hogy a klinikai szakpszichológusok működési nyilvántartásba vételekor kitöltendő űrlap tartalmának minden részlete az EKNy rendszerébe vélhetőleg átkerülhet. A rendszer megvalósításának során ezeket az adatstruktúrákat be kell szerezni, és ezek alapján a rendszer adatbázis terveit módosítani kell.
Stubenvoll Bt
104 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
«table» Klinikai_szakpszichologus_mukodesi Sorszám : VARCHAR(1) Név : VARCHAR(1) Születési hely : VARCHAR(1) Születési idő : TIMESTAMP Anyja neve : VARCHAR(1) Állampolgársága : VARCHAR(1) Leánykori név : VARCHAR(1) Szakképesítés megnevezése : VARCHAR(1) Oklevél, bizonyítvány száma : INTEGER Képzést szervező intézmény neve : VARCHAR(1) Képzés időpontja : TIMESTAMP Képesítést szervező intézmény megnevezése : VARCHAR(1) Alapnyilvántartás száma : VARCHAR(1) Vizsga letételét tanúsító okirat száma : INTEGER Tudományos fokozat : VARCHAR(1) Nyilvántartási száma : VARCHAR(1) Kiállítás helye : VARCHAR(1) Kiállítás ideje : TIMESTAMP Kiállító intézmény megnev. : VARCHAR(1) Nyelvismeret foka : VARCHAR(1) Nyelv megnevezése : VARCHAR(1) Nyelvvizsga kiállítás helye : VARCHAR(1) Nyelvvizsga bizonyítvány száma : VARCHAR(1) Nyelvvizsga kiállítás időpontja : VARCHAR(1) Nyelvizsga kiállító intézmény megnevezése : VARCHAR(1) Előző nyilvántartási száma : VARCHAR(1) Korlátozott alkalmasság : BIT(1) Az eü. tev. egy évet meghaladó szünetelt. ideje : VARCHAR(1) Honosított oklevél által tanúsított szakképesítés : VARCHAR(1) Honosítás száma : INTEGER Honosítás helye : VARCHAR(1) Honosítás időpontja : TIMESTAMP Honosító intézmény : VARCHAR(1) Munkahely neve : VARCHAR(1) Lakcím : VARCHAR(1) Munkahely címe : VARCHAR(1) Beosztása : VARCHAR(1) Szakképesítés szerinti munkakörökben eltöltött évek száma szerinti gyakorlati pontszám : INTEGER Elméleti továbbképzés pontszáma : INTEGER
9.8
Egészségügyi szakdolgozók alapnyilvántartása
Mivel az egészségügyi szakdolgozók alapnyilvántartásáról nem kaptunk konkrét adatstruktúra leírást, így csak azt tudjuk kijelenteni, hogy az egészségügyi szakdolgozók alapnyilvántartásba vételekor kitöltendő űrlap tartalmának minden részlete az EKNy rendszerébe vélhetőleg átkerülhet.
Stubenvoll Bt
105 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
A rendszer megvalósításának során ezeket az adatstruktúrákat be kell szerezni, és ezek alapján a rendszer adatbázis terveit módosítani kell. «table» Egeszsegugyi_szakdolgozotorzs Törzslap száma : INTEGER Név : VARCHAR(1) Születési név : VARCHAR(1) Leánykori név : VARCHAR(1) Születési hely : VARCHAR(1) Születési idő : TIMESTAMP Anyja neve : VARCHAR(1) Állampolgársága : VARCHAR(1) Legmagasabb iskolai végzettség : VARCHAR(1) Szakképesítés megnevezése, azonosító száma : VARCHAR(1) Szakképesítést szervező intézmény neve, címe : VARCHAR(1) Vizsgát szervező intézmény neve, címe : VARCHAR(1) Bizonyítvány, oklevél száma : VARCHAR(1) A képesítést szervező intézmény neve, címe : VARCHAR(1) A vizsgát szervező intézmény neve, címe : VARCHAR(1) Az alapnyilvántartás száma : VARCHAR(1)
9.9
Egészségügyi szakdolgozók alapnyilvántartása
Mivel az egészségügyi szakdolgozók működési nyilvántartásából nem kaptunk konkrét adatstruktúra leírást, így csak azt tudjuk kijelenteni, hogy az egészségügyi szakdolgozók működési nyilvántartásába vételekor kitöltendő űrlap tartalmának minden részlete az EKNy rendszerébe vélhetőleg átkerülhet. A rendszer megvalósításának során ezeket az adatstruktúrákat be kell szerezni, és ezek alapján a rendszer adatbázis terveit módosítani kell.
Stubenvoll Bt
106 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
«table» Egeszsegugyi_szakdolgozok_mukodesi Törzslap száma : INTEGER Név : VARCHAR(1) Születési név : VARCHAR(1) Születési hely : VARCHAR(1) Születési idő : TIMESTAMP Anyja neve : VARCHAR(1) Állampolgársága : VARCHAR(1) Lakcíme : VARCHAR(1) Szakképesítés megnevezése : VARCHAR(1) Szakképesítést szervező intézmény neve, címe : VARCHAR(1) Vizsgát szervező intézmény neve, címe : VARCHAR(1) Bizonyítvány, oklevél száma : VARCHAR(1) Nyelvvizsga típusa : VARCHAR(1) Korlátozott alkalmasság jelzése : VARCHAR(1) Szüneteltetett tevékenység jelzése : VARCHAR(1) Munkahely neve : VARCHAR(1) Munkahely kódszáma : VARCHAR(1) Munkahely címe : VARCHAR(1) Munkakör és kódszáma : VARCHAR(1) Gyakorlati pontszám : INTEGER Elméleti továbbképzés pontszámai : INTEGER
9.10 Gyógyszerek nyilvántartása
Stubenvoll Bt
107 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
9.11 Szolgáltatók nyilvántartása A szolgáltatók nyilvántartásából kellő mértékben felépített adatstruktúra rendelkezésünkre, melyek entitás halmazát az EKNy rendszerében ábrázoljuk.
áll
Az egyes entitások közötti kapcsolódási pontok viszont nem kerültek egyértelműen meghatározásra, pedig a köztük lévő összefüggési viszonyok logikailag beláthatók.
9.12 Szakmai kódnyilvántartás A szakmai kódnyilvántartás formai és tartalmi változtatás átemelhető az eredeti adatbázisból, az entitások között kapcsolat nem áll fenn, ezeket ábrázolni nem lehet.
9.13 Finanszírozási, besorolási algoritmusok A finanszírozási, besorolási algoritmusok az alábbi két entitásból áll, melyek egymással kapcsolati viszonyt nem, de a 8.14 fejezetben tárgyalt OENO és HBCS entitásokkal mutatnak kapcsolódási pontot.
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
10 A harmonizált adatmodell lehetőségei és korlátai A létező közhiteles nyilvántartások ismertetésekor megállapítottuk, hogy bár ezeket a nyilvántartásokat különböző szervezetek eltérő jogi és hatásköri szabályozási környezetben, egymástól függetlenül tartják karban, ezért egységesítésük megfontolandó, informatikai szempontból azonban harmonizálásuk a hasonló adattartalom okán részben lehetséges. Ugyanakkor már utaltunk arra, hogy a létező közhiteles nyilvántartások felmérése során dr. Sinkó Eszter a vártnál nagyobb nehézségekbe ütközött, ezért a tanulmányából átvett információ nem minden esetben szolgáltatott elegendő alapot egy megbízható adatmodell elkészítésére. Ezekben az esetekben az elkészített adatmodell – melyet a szokásos sárga helyett rózsaszín háttérrel rajzoltunk meg – az adatlapon, vagy egyéb feltételezéseken alapul. Ezért, mielőtt az adatbázis tényleges harmonizálását elvégeznénk, feltétlenül ellenőrizni kell a létező adatbázisok elemi struktúráit. A bemutatott adatmodellek mindegyike tartalmaz ismétlődően megjelenő elemi struktúrákat, a harmonizálás ezek mentén képzelhető el. Mindenekelőtt a • • •
név cím telefonszám
azok az adatok, melyek csaknem mindegyik struktúrában előfordulnak. Természetesen belső felépítésük a jelenlegi nyilvántartásokban nem egységes, ezért amennyiben egységes struktúrájú adatbázisban tároljuk, ezeket az adatokat konvertálni kell, melynek munkaigénye erősen függ a struktúrák különbözőségétől, de akár jelentős is lehet. A fentiek alapján elsősorban a 8 személyi nyilvántartás harmonizálása hoz jelentős eredményt, hiszen ezek jelenleg is igen nagy hasonlóságot mutatnak, de az intézmény nyilvántartás is tartalmaz azonos elemeket. A kódrendszerek önmagukon belül nyújtanak ilyen lehetőséget, a hatás a nyilvántartások egyszerűsége miatt nem jelentős, azonban a teljesség érdekében az alábbi, harmonizált adatmodell ezeket is magába foglalja.
Stubenvoll Bt
111 / 141
Budapest, 2004 szeptember 30
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
«table» INTEZMENY_x_TELEFON ID : INTEGER TELEFON_ID : INTEGER
0..* 1
ID : INTEGER TELSZAM : VARCHAR(64) FAX : BIT(1) TIPUS : DECIMAL(1, 0)
«table» ORVOSSZAKMAIKODOK KOD : VARCHAR(4) JELENTES : VARCHAR(255)
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
III. rész Az EKNy kialakítása
A tanulmány jelen, harmadik része az EKNy rendszer kialakításához ad útmutatást. Az első részben ismertetett elvek és a második részben bemutatott adatmodellezés alapján felvázoljuk a megvalósítandó rendszer tervét, amely a megvalósítás feladatspecifikációjaként is felfogható. Előljáróban meg kell említenünk néhány lényeges tényezőt: •
Az adatmodellezés alapján történő adatbázis tervezést meg kell előzze a létező közhiteles nyilvántartásokról rendelkezésre álló információk pontosítása, kiegészítése. A vonatkozó pontokra az adatmodellezésnél utaltunk.
•
Mivel az EKNy rendszer várható használatára vonatkozóan még nem állnak rendelkezésünkre becslések, a fizikai rendszertervezés megkezdése előtt döntés kell szülessék a rendszerrel szemben támasztott teljesítmény-követelményekről, elsősorban a párhuzamos lekérdezések várható mértékéről illetve az ebből következő sávszélesség-igényről.
•
A tanulmány I. részében bemutattuk a közhiteles adatokhoz való hozzáférés módjait, majd a rész végén felvázoltuk az EKNy rendszer javasolt architektúráját. Az alábbiakban javaslatunkat leszűkítjük arra a részhalmazra, melyet a 8.1 pontban felsorolt nyilvántartásoknak az EKNy rendszerében való kialakítása során meg kell valósítani. A többi hozzáférési módot, illetve az alábbiakat meghaladó architekturális megfontolásokat mint potenciális lehetőséget kell szem előtt tartani arra az esetre, amikor az EKNy rendszer a későbbiekben, az egészségügyi nyilvántartások korszerűsítése során, bővítésre kerül.
Stubenvoll Bt
113 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
11 A megvalósításra kerülő EKNy rendszer, mint logikai egész A létező közhiteles nyilvántartásokról és kezelésükről megkapott adatok az eredeti, az I. részben ismertetett tervektől eltérően kevésbé szigorú igényeket támasztanak a hardver park kialakításával szemben. Ezen okok miatt szükségessé vált a hardver architektúra újratervezése.
11.1 Az újratervezés okai Az EKNy rendszer nem kizárólag olyan adatokat tárol, melyek más adatbázisokból változtatás nélkül kerülnek átmásolásra, ezért megsérült adatbázis esetén annak tartalma az eredeti adatbázisokból garantáltan újra előállítható. Ennek következtében az I. rész végén bemutatott biztonsági adattöbbszörözésre a jelen megvalósítási ajánlásban nincs szükség. Másrészt mivel az EKNy rendszerrel szemben nem igény a 100%-os rendelkezésre állás, ezért azokra a biztonsági lépésekre, melyek az egyes szervereket többszörözik a rendszerben, ugyancsak nincs szükség. Ennek a szerverkettősségnek az lett volna az érelme, hogy ha egy adatbázis, alkalmazás vagy Web szerver, valamilyen strukturális, esetleg hardver hiba esetén kiesik, akkor a mások csatorna vonalon az adatok szolgáltatása zavartalan maradjon.
11.2 Javasolt architektúra
Stubenvoll Bt
114 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Stubenvoll Bt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
115 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
11.3 További javaslatok a hardver architektúrára Bár az egyes adatbázisokkal kapcsolatban nem érkezett meg minden információ, de a jelenlegi ismereteink alapján valószínűsíthető, hogy az adatok mennyisége elég alacsony ahhoz, hogy az egyes hardvereken elvégzett funkcionalitásokat össze lehessen vonni, és ezáltal kevesebb hardver kerüljön telepítésre.
Stubenvoll Bt
116 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
11.4 Tovább egyszerűsített architektúra A fenti javaslatok alapján a tovább egyszerűsített architektúra az alábbi ábrán látható. Távoli adatlekérdezés tárolt eljárásokkal
Adatok
Adatbázis és alkalamzás szerver
Kapcsolódó adatbázis szerver
Adat szolgáltatás
Tűzfal Adat szolgáltatás
Plumtree portál és Web szerver
Internet
`
Ezen az architektúrán a következő elosztásban helyezkednének el a szoftver rendszerek.
Stubenvoll Bt
117 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Stubenvoll Bt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
118 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
12 Az EKNy adatbank-funkcióinak ismertetése 12.1 Adattárolás Az első részben leírtaktól eltérően a meglévő rendszerek felmérése után egyértelművé vált, hogy a négy adathozzáférési mód közül csak kettőnek van végleges szerepe az EKNy rendszerben. Ezek a következők: •
Tükrözött adatok, az adatokat karbantartó szervezettől, az aktuális adatokat az EKNy rendszerbe másolva kerülnek tárolásra, és a Webes interfészen keresztül történő lekérdezések eredményeként a helyileg tárolt adatok közül kerül megjelenítésre a szükséges információ.
•
Interfészeken keresztül kezelt adatok, melyek csak az adatokat karbantartók szerverein lehet tárolni, ezért adatbázis interfészeket (meghívható tárolt eljárásokat) biztosítanak az adatokhoz történő hozzáféréshez. Ezekben az esetekben a jogosultságok elbírálását a megszólított rendszer látja el, az EKNy rendszer csupán az adatszolgáltatási kéréseket továbbítja az eredeti nyilvántartási rendszerhez, majd a válaszként adott adatokat a kérelmező felé.
Mostantól kezdve így is hivatkozunk rájuk.
12.1.1
Tükrözött adatok
A tükrözött adatok az eredetinek 1:1 másolatai, azonos struktúrában és tartalommal. Az EKNy rendszerben a jelenlegi közhiteles nyilvántartások közül az alábbiak kezelése történik ebben a rendszerben: • • • • • • • •
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Távoli adatok interfészen keresztül
Ezek a közhiteles nyilvántartások az alábbiak: • •
Országos Transzplantációs Nyilvántartás TAJ nyilvántartás
12.1.3
Adatbázis szinten
Adatbázis szinten kétféle jogosultsági kört kell megvalósítani, melyek elegendőek az adatok kellő biztonsággal történő kezeléséhez. Ezek a következők: • •
Csak olvasási jog Olvasási és korlátozott írási jog
Csak olvasási jog Mivel az EKNy rendszer a felhasználók számára csak a közhiteles adatok lekérdezését teszik lehetővé, azokhoz történő olyan jellegű hozzáférés, mely az adatok módosulását eredményezi, nem követelmény, sőt a rendszer feladatait megsértik, ezért alapvetően mindenki számára csak olvasási joggal lehetséges az adatokhoz történő hozzáférés. Természetesen az adatokhoz történő bizalmas hozzáféréseket is meg kell valósítani, de az az alkalmazás szinten történő jogosultság kezelés feladata. Olvasási és korlátozott írási jog A rendszer karbantartói számára szükséges, hogy írási joggal is hozzáférhessenek az EKNy rendszer adataihoz, de ez az írási jog kizárólag a betöltési interfészre korlátozódhat. Az innen a belső, lekérdezhető rendszerbe kerülő adatok írását, módosítását csak a betöltő (adatkonverziós) eljárások végezhetik el, oda közvetlenül senki nem nyúlhat. A betöltő eljárásoknak saját jogosultságuk van az adatok írására, mely garantálja, hogy a rendszer adataihoz senki illetéktelen ne nyúlhasson hozzá. Korlátozott írási jogot még azok a személyek kaphatnak, kiknek kellő jogosultságuk van naplózási információk beállítására, mely adatokat szintén adatbázisban kell eltárolni. Ebből következik, hogy ezek a személyek (vagy intézmények) csak és kizárólag a naplózásokat vezérlő táblákra vonatkozó írási joggal rendelkezhetnek.
Stubenvoll Bt
120 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
12.1.4
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Adatok frissítése
Az adatok frissítése az adatokat karbantartó szervezettől kell, hogy érkezzék. Legegyszerűbb módja, hogy SQL insert, update vagy delete utasításokkal a tárolt adatok az eredeti rendszernek megfelelő formát vegyen fel. A rendszer továbbfejlesztése során érdemes lesz egy automatikus rendszerkarbantartó módszer kidolgozásával foglalkozni, de ez a rendszer jelen állapotában nem igény.
12.1.5
Adatkonverziós eljárások
Mivel az EKNy adatbázisa az eredeti adatbázisok pontos másolata, struktúrája is megegyezik az eredetivel, ezért az eredeti adatok és az EKNy adatbázisa között adatkonverzióra nincs szükség. Amennyiben az EKNy rendszer megvalósításakor harmonizált adatbázis kialakítására kerül sor, és ugyanakkor az eredeti adatbázisok struktúrája nem változik, akkor viszont szükség lesz a két adatbázis közötti adatkonverzióra. Ennek módja, bonyolultsága és megvalósításának részletei azonban csak a konkrét kialakítások és az eredeti adatbázisok struktúrájának pontos ismeretében tervezhetők meg.
Stubenvoll Bt
121 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
13 Üzleti logika 13.1 Szerepe Az üzleti logika elsődleges szerepe, hogy az EKNy rendszer fő funkcionalitási tevékenységeit elvégezze. Az üzleti logikában valósul meg mindaz, ami programozást igényel. Ezekről a feladatokról a teljesség igénye nélkül egy rövid listát adunk: • • •
Az üzleti logikát J2EE technológia felhasználásával tanácsos megvalósítani, mivel ez a technológia számos olyan funkciót levesz a rendszer tervezőjének és implementálójának a válláról, mely programozás technikailag komoly kihívást jelent. Ennek következtében gyorsabban és olcsóbban kifejleszthető rendszer kerül megvalósításra, ahol tényleg a fontos részletek meglétére, nem pedig az alapműködés kellő stabilitására helyeződik a hangsúly. Ennek következtében az üzleti logikának J2EE kompatibilis alkalmazás szerveren kel futnia.
13.2 Adatok kinyerése 13.2.1
Tükrözött adatokból
A J2EE technológiából adódóan az adatok lekérdezése meglehetősen egyszerű folyamat. Az egyes entitásokra az üzleti logika szintjén hozzáférési interfészeket kell ráhúzni. A J2EE technológia teljes egészében elrejti az adatokhoz történő hozzáférés technikai részét, csupán az adatkapcsolat felvételéhez szükséges konfigurációkat kell beállítani. A megfelelő jogosultságok lekezelésének érdekében a programlogikában tárolt funkcionalitásnak kell gondoskodnia arról, hogy az egyes jogosultsági körrel rendelkező személyek az entitások milyen köréhez, és azok milyen halmazához férhetnek hozzá.
13.2.2
Interfészen keresztül kezelt adatokból
A J2EE technológia sajátossága, hogy a saját és a távolról kezelt adatok, továbbá a konkrét entitások és tárolt eljárások között nem tesz semmilyen különbséget, ugyanaz az interfész szolgáltatja a megszólított adatot.
Stubenvoll Bt
122 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
A különbség legfeljebb az adatkapcsolat felvételéhez szükséges konfigurációkban fedezhető fel.
13.3 Belső szerviz funkciók 13.3.1
Párhuzamosított adathozzáférés
Nagy rendszerek használata közben, az egyidejű adathozzáférés elengedhetetlen. Ilyenkor a felhasználók, a nélkül, hogy bármit is tudniuk kellene arról, hogy rajtuk kívül még ki használja a rendszert, teljes biztonsággal, az elfogadható válaszidő keretein belül hozzáférnek az információhoz. Mivel a korszerű adatbázis rendszerek és a J2EE technológia jó és magas szintű támogatást képes nyújtani ezen a területen, ezért az EKNy fejlesztése során nem kell különösebb logikát építeni az ilyen jellegű adatkiszolgálásra.
13.3.2
Zárolás
Az előző pont alatt tárgyaltakból kiindulva előfordul, amikor az adatokhoz egyszerre kívánnak egyes felhasználók hozzáférni, mások pedig módosítani azt. Ez komoly gondokat okozhat az adat integritásában. Hiszen kellemetlen eredményeket produkálhat, amikor két felhasználó is ugyan azokat az adatokat módosítja, akkor konkrétan melyikük eredményének kell érvényre jutnia? A problémát tovább dagasztja, amikor nem tudnak arról, hogy egyszerre dolgoznak ugyan azon az adaton ezért észre sem viszik, ha más eredmények kerülnek a rendszerben érvényre, mint amire számítanak. Az ilyen jellegű hibákat lehet az adatok zárolásával kiküszöbölni. Azokat az adatokat, melyek módosításra kerülnek, zárolni kell, módosítani, majd miután a kívánt eredmény került érvénybe, az adatok módosítását ismét engedélyezni lehet. Ilyenkor, ha más is módosítani kívánja az adatokat, annak zárolásáról visszajelzést kap. Az EKNy rendszerébe ültetve ezt a logikát, felmerül a zárolás igényének szükségessége. Az adatok kinyerése számos irányba történhet, de betöltése csak egy csatornán keresztül következhet be, ahol az adatok betöltése sorba rendezés eredményeként, nem produkálhat olyan hibaeseményt, ahol az adatok egyidejűleg változnának.
13.3.3
Frissítés
Minden nagy felhasználói kört kiszolgáló rendszer, a megfelelő sebesség elérése érdekében az adatokat valamilyen formában cache-eli, azaz az adatokat memóriában tartja, és a rá irányuló kéréseket onnan szolgálja ki. Stubenvoll Bt
123 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Mivel a korszerű adatbázis szerverek, a J2EE technológiát támogató alkalmazás szerverek és Web szerverek hatékony cache-elési mechanizmussal rendelkeznek, ahol az adatok kellő időben történő frissítése saját logikán alapulva megtörténik, ezért az EKNy rendszer fejlesztése során erre nem kell speciális logikát építeni.
13.4 Archiválás 13.4.1
Az adattár mentése
Mivel az adattár tartalma módosítás nélküli másolatot tartalmaz az adatokat szolgáltató rendszerekkel szemben, ezért nincs szükség adattár mentési funkciókra. A mentések gyakorlatilag az eredeti rendszerek maguk.
13.4.2
Az adattár visszaállítása
Minden intézkedés ellenére, melyeket az adatok biztonsága érdekében megvalósítunk, bekövetkezhetnek adathibák. Ezeknek a hibáknak, esetleg szándékos rongálásoknak a következményeit az adatok visszaállításával lehet megoldani. A visszaállításnak több lépése, kategóriája van. Az, hogy melyik visszaállítási lépést kell választani, attól függ, hogy milyen formájú, mértékű az adatok rongálódása. Az erről szóló döntést az adott helyzetben kell meghozza az üzemeltetéssel megbízott csoport ügyeletese, nagyobb káresemény gyanúja esetén annak vezetője. Ez a kérdés a katasztrófa-kezelésben is szabályozott kell legyen. Mivel mentések nem készülnek, az eredeti rendszer ismételt másolásával valósítható meg a rendszer visszaállítása.
13.5 Jogosultság kezelések Az alkalmazás szintjén lényegesen bonyolultabb jogosultság kezelést kell kialakítani, mivel az eltérő szervezetek illetve személyek eltérő jogosultsági körrel rendelkezhetnek, vagy más és más adatokhoz férhetnek hozzá napi munkájuk során. Mivel elég sok személyre kell a jogosultságokat kiosztani, tanácsos a szükséges jogosultsági köröket először szerepkörökre bontani, majd a szükséges szerepköröket a létrehozott felhasználókhoz hozzárendelni. Az ilyen jellegű jogosultság kiosztást a korszerű alkalmazás szerverek a J2EE technológia támogatásából kifolyólag automatikusan támogatják.
Stubenvoll Bt
124 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
13.5.1
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Szerepkörök
A szerepkörök tulajdonképpen egy bizonyos tevékenységi körhöz tartozó jogosultságok gyűjteménye. A szerepkörök alkalmazásával jól körül lehet határolni az egy adathalmazra, egy bizonyos tevékenységi körben kiosztandó jogosultságokat. Érdemes kétszintű szerepkör kiosztást alkalmazni, ahol az alsóbb szinten elemi tevékenységek köre kerül meghatározásra, mint pl.: mindenki számára hozzáférhető közhiteles adatok, speciális szervezetfüggő közhiteles adatok, naplózási adatok; a felsőbb szinten pedig az adott szervezetnél dolgozók beosztására jellemző, alsóbb szintű szerepkörökből összeállított halmazok kerülnek definiálásra. A mindenki számára hozzáférhető közhiteles adatok minden felsőbb szerepkörnek részre lesz, de a naplózási jogokat csak magasabb beosztásban lehet valaki számára kiosztani. Az előzetes felmérésékből a szerepkörökre vonatkozóan nem érkeztek meg a szükséges információk, ezért ezek egyértelmű meghatározása jelenleg nem lehetséges. Viszont a szerepkörök meghatározására a következő javaslatot tudjuk tenni. A szerepkörök meghatározását minden egyes tárolt adathalmazra, mint témakörre el kell végezni. A szerepkörök felbontását a legáltalánosabb halmaztól a legspecifikusabbig haladva kell elvégezni. Egy példával szolgálhatunk, ahol az érintett entitások egyes attribútumainak halmaza bővülhet, vagy változhat az egyes szintektől függően: •
Publikus, mindenki számára hozzáférhető adatok.
•
Intézmények, ahol az adott intézményben minden dolgozó számára hozzáférhető adatok köre kerül meghatározásra.
•
Osztályok, ahol az egyes osztályokra jellemző hozzáférhető adatok köre kerül meghatározásra.
•
Tevékenységek, itt az egyes dolgozók által elvégzett feladatkör alapján kerülnek a szerepkörök meghatározásra. Ez a korábbi a korábbi egymásra épülő szerepkörök határait átrúgja. Ezek a személyek általában lehetnek: o o o o
Személyzeti tevékenységet ellátók Adatvédelmi biztosok Vezetők Stb.
Adott esetben egy szerepkör több szerepkör együtteséből épül fel. Hiszen egy osztálynak a vezetője az adott osztályra vonatkozó minden adatot olvashat, továbbá mint vezető, ettől eltérő attribútumok megtekintésére is lehet joga. Ezek a szerepkörök kerülhetnek
Stubenvoll Bt
125 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
egymással átfedésbe, de lehetnek mindkét halmazban olyan részek is, ami a másik szerepkörrel nem hozzáférhető.
13.5.2
Felhasználók
A felhasználókat személyre szólóan kell létrehozni. Ennek konkrét oka van, mivel ennek alapján lehet a naplózásoknál végigkövetni a konkrét személy által elkövetett illetéktelen behatolási kísérleteket. Ha a szerepkörök kellő körültekintéssel kerülnek kialakításra, akkor egy felhasználó számára már csak az adott intézet (szervezet) megfelelő osztályának megfelelő pozíciójára jellemző felsőbb szintű szerepkört kell kiosztani. További jogosultság kiosztása számára nem indokolt. Ha a felhasználó számára mégsem elegendő a kiosztott szerepkör, akkor a szerepkörök kiegészítése, vagy új szerepkörök definiálása a megfelelő út további jogosultságok kiosztására. Felhasználók számára közvetlenül jogosultságokat nem szabad adni. A konkrét felhasználók jogosultságait akkor lehet kiosztani, amikor már egyértelmű, hogy milyen szerepkörökről beszélünk, és az is, hogy pontosan kinek kívánjuk ezt a szerepkört odaadni. Fontos, hogy minden regisztrálandó felhasználónak saját felhasználóneve és jelszava legyen, mert ezzel biztosítható a naplózás egyértelműsége.
13.6 Naplózások A rendszeren belül végzett tevékenységeket, az adatok jogilag érzékeny tartalma miatt feltétlenül szükséges naplózni. A naplózásokat két szinten kell elvégezni. • •
Adatmódosulások naplózása Lekérdezések naplózása
13.6.1
Adatmódosulások naplózása
Az adatok módosulásának naplózását kikerülhetetlenül naplózni kell. Azaz ez a tevékenység sosem kikapcsolható, minden újonnan bekerült, megváltozott illetve törtölt adatról, és a rajta elvégzett tevékenységről naplózást kell végezni. Ennek célja, hogy a szándékos adatmeghamisításokat ki lehessen szűrni, annak elkövetőjét, és az elkövetés időpontját vissza lehessen keresni. Ezt a fajta naplózást az adatbázis oldalán kell megvalósítani, mégpedig oly módon, hogy az adatokat tároló táblákra adatbázis triggereket kell elhelyezni, mely a tábla megváltozásának esetén automatikusan érvényre lép és egy, az eredeti tábla mintájára készített napló táblába feljegyzi a módosult adatot (törlés esetén a kitörölt adatot), a rajta elvégzett módosítás Stubenvoll Bt
126 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
típusát (beszúrás, módosítás, törlés), a módosulás időpontját és a módosítást elvégző személy azonosítóját. Nagyon fontos, hogy ide az alkalmazás szintjén meghatározott felhasználó azonosítója kerüljön tárolásra, és nem az adatbázishoz csatlakozóé, mert ez megakadályozza a felhasználó egyértelmű beazonosítását. A triggereknek saját jogosultsági körrel kell rendelkezniük, mely a felhasználó jogosultsági körétől független. Erre azért van szükség, mert a bejelentkező felhasználók alapvetően más jogosultsággal rendelkeznek, és adott esetben a napló táblákba írásra nincs joguk. A triggerek jogosultsági köre és program logikája biztosítja, hogy más kulcsfontosságú adatok ne módosulhassanak.
13.6.2
Lekérdezések naplózása
A lekérdezések naplózására összetettebb logikát kell felépíteni, mivel •
nem mindig szükséges a hozzáférések naplózása,
•
a naplózásokat személyekhez, munkacsoportokhoz és területekhez is kötni kell tudni,
•
ezen megfigyelések eredményeinek törlését megoldhatóvá kell tenni,
•
a naplóbejegyzések törlését külön logikával védeni kell, hogy a megfigyelt személy ne tudja megsemmisíteni őket.
Ez annyit jelent, hogy a lekérdezések naplózását magasabb szinten kell megvalósítani, mint az adatmódosulások naplózását. Azaz ezeket a naplózásokat programlogikából kell megvalósítani, hogy a kellő intelligenciával rendelkezzenek. Mivel a hozzáférések naplózása igen nagy mennyiségű adatot generálhat, ezért csak indokolt esetben szabad ilyen megfigyelést alkalmazni. A túl nagy mennyiségű megfigyelés könnyen túlterhelheti a rendszer merevlemez kapacitását, ami a rendszer leállásához vezethet. A naplózások során meg kell tudni különböztetni konkrét személyeket, munkacsoportokat (pl.: egyik szervezet valamelyik osztálya), és területeket (az EKNy rendszeren belüli adat csoport). Mindhárom kategória naplózására lehetőséget kell biztosítani. Személyre azért, hogy ha gyanítható az adott személy munkakörébe nem tartozó adatkeresések elvégzése, aminek következménye adott esetben illetéktelen harmadik fél számára azok kiadása. Munkacsoport, ahol a gyanús személy kiléte ismeretlen, de az ügyosztály meghatározható. Lehetőséget kell biztosítani továbbá arra, hogy a fenti kategóriákat keverni lehessen. Pl.: Egy bizonyos területről, gyaníthatóan egy bizonyos ügyosztály dolgozója segítségével adatok szivárognak ki. Ilyenkor a munkacsoportot és az adatterületet vegyítve kell
Stubenvoll Bt
127 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
alkalmazni, ahol meghatározásra kerül az, hogy egy bizonyos területen melyik ügyosztály tevékenységét kívánjuk megfigyelni. Minél tágabb felhasználói kör megfigyelése történik minél tágabb területen, annál nagyobb merevlemez kapacitást igényel a megfigyelés.
13.6.3
Napló állományok megtekintése
A megfigyelések további biztonságtechnikai okokat vetnek fel. A megfigyelő indokoltan figyelt-e meg, vagy csak valamilyen személyes vagy illegális haszonszerzési okból? Ezért a megfigyelőnek tudnia kell, hogy a megfigyelt személy milyen adatok után érdeklődött, de mégsem tudhatja meg azok pontos tartalmát, mert az könnyen visszaélésekhez vezethet. Tehát a naplózott adatoknak tartalmazniuk kell olyan információkat, melyek alapján egyértelműen beazonosítható a gyanús tevékenység helye, de a megfigyelő mégsem láthatja meg az adatokat teljes valójukban. Maga a megfigyelő adott esetben nem is olyan személy, aki egyértelműen meghatározhatja, hogy a gyanús személy tényleg tilosban jár-e. Ezért ennek eldöntésére harmadik személy bevonására lesz szüksége (pl.: egy osztályvezető, a gyanús személy közvetlen főnöke stb.). Éppen ezért a naplóállományokba minden információnak be kell kerülnie, de az adatok bizalmasan kezelendő részének titkosítottan kell megjelennie a naplózó képernyőjén. Ha a naplózó személyben az a gyanú támad, hogy a megfigyelt személy nem a munkakörének megfelelően használja a rendszert, akkor harmadik személy részére a már megtörtént naplózási adatokra (de csak azokra, a még meg nem történtekre semmi szín alatt) ideiglenes olvasási jogot ad, akkor az a személy megtekintheti ezeket a naplózási rekordokat. Ahhoz, hogy a harmadik személy a bizalmasan kezelendő adatokat megtekinthesse, az eredeti adatokon is megfelelő jogosultságokkal kell rendelkezzen, különben a napló adatokat hasonló képen tekintheti csak meg, mint a megfigyelő.
13.6.4
Napló állományok törlése
Mivel ezeknek a megfigyeléseknek a naplózása csak addig érdekes és addig tanácsos megőrizni, amíg a személy ártatlansága, vagy bűnössége be nem igazolódik, ezért utána az ilyen napló adatokat törölni kell tudni. Ezekből következik, hogy a naplóadatokat csak akkor lehessen törölni, ha az adatokról már mentés történt, tehát a naplózás ténye, és a megfigyelt esemény a mentésekre minden féle képen rá kell kerülnie. Ennek biztosítását két féle javaslattal szolgálunk: •
Egy arra kijelölt (a mentések lebonyolításáért felelős) személy, a mentések elvégzése után megjelöli azokat a napló adatokat, melyek archiválásra kerültek, tehát adatvesztés nélkül törölhetőek az adatok.
Stubenvoll Bt
128 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
•
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Az archiválás olyan programlogikán keresztül történik meg, ahol az archiváló programrész a legutolsó mentés időpontját feljegyzi és a napló állományokból történő törlés lehetősége ettől a feljegyzett időponttól függ. Ezt úgy kell elképzelni, hogy az adatbázisban egy időpont tárolásra kerül. A naplózásokat elvégző személy a napló adatokat törlésre jelöli meg, és ezek az adatok törlésre megjelölésre kerülnek. Ezeket az adatokat a rendszer innentől kezdve rejtetten kezeli, tehát nem mutatja meg egészen addig, míg archiválásra nem kerültek. Ha az archiválás megtörtént, a törlésre megjelölt adatokat a rendszer saját maga automatikusan eltávolítja. Természetesen ha az archiválás már korábban megtörtént, az adatok azonnal törlődhetnek.
A naplózási események törlését csak kitüntetett személy engedélyezheti, tehát amikor a megfigyelést elvégző személy a naplóadatokat törlésre megjelöli, akkor azok törlése csak akkor történhet meg, ha az arra kijelölt személy a beleegyezését adta.
13.6.5
Naplózási jogosultságok
A naplózási jogosultságokkal rendelkező személy mások tevékenységeinek megfigyelésére képes. Mivel itt a fő hangsúly a tevékenységek megfigyelése, ezért a tevékenységek közben lekérdezett adatokat nem tekintheti meg. Ezek az adatok számukra rejtetten jelennek meg, hiszen különben olyan információhoz juthatnának, amihez alapvetőleg nincs joguk. A naplózást elvégző személyeknek egy külön szervezeti részegységhez kell tartozni, mely csak és kizárólag a naplózásért felel. Az egyéb osztályok alkalmazottai, vezetői nem kaphatnak ilyen jogosultságot, hiszen az akár munkajogi visszaélésekhez is vezethetnek. Tehát a jogosultságok kiosztásánál erre szigorúan oda kell figyelni. A már naplózott adatokhoz a naplózást elvégző személy adhat olvasási jogot adott esetben azon személy a főnökének, akinek a tevékenységeit megfigyeltél, de ezt a jogot csak ideiglenesen, pár órás, vagy pár napos periódusra, és csak a már megtörtént megfigyelésekre, azaz ha a személyen még gyűlnek a naplózási adatai, azokról az olvasási jogot kapott személy automatikusan nem értesülhet. Azokat csak egy újabb ideiglenes olvasási jog kiosztása után tekintheti meg. A naplózást elvégző személyek között kell legyen egy kitüntetett szereppel ellátott személy, mely a naplózásokat elvégző személyeket figyelheti meg. Lehetőleg csak őket. Továbbá ő az a személy, aki beleegyezését adhatja a törlésre megjelölt adatok eltávolításához.
Stubenvoll Bt
129 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
14 Az EKNy Webes közzétételi felület funkciói 14.1 Szerepe A Webes közzétételi funkciók tulajdonképpen dinamikus oldalak generálásából állnak, ahol a böngészések vagy keresések során a felhasználók a megfelelő adatokhoz tudnak hozzáférni. A listák összeállítása az üzleti logika szintjén valósul meg, éppen ezért a Web szerver J2EE kompatibilis kell legyen, annak érdekében, hogy a megfelelő kapcsolatot az alkalmazás szerverrel képes legyen fenntartani, továbbá, hogy a szükséges (dinamikus tartalmú) oldalak megjelenítését képes legyen elvégezni.
14.2 Listázás Listák előállítása alapvetően az adatbázisban tárolt, dinamikusan lekérdezhető adatok halmazára értelmezhető, melyek előállítása két körre bonthatók: • •
Alapértelmezett listák Tartalom szerinti keresések listája
14.2.1
Alapértelmezett listák
Az alapértelmezett listák esetében az adatok között történő böngészés, vagy célirányos keresés eredményeként előálló adathalmaz megjelenítése a cél. Ilyenkor egy táblázatos formában megjelenített lista tökéletesen kiszolgálja a felhasználó igényeit, ahonnan minden számára releváns információt leolvashat. Ezek a listák tartalmazhatnak tovább vezető hivatkozásokat is, melyek adott esetekben további szűkítő keresések eredményeként előálló listák lehetnek.
14.2.2
Tartalom szerinti keresések listája
A tartalom szerinti keresések listája egy olyan lista, ami szövegesen megmutatja a kulcsszavak alapján történő keresések eredményeinek hivatkozási helyeit. Jó példa rá az Interneten jól ismert más tartalom szerinti keresők, lásd. Google, Altavista stb. Az ilyen keresések eredményeként előálló listák a megtalált kulcsszavak előfordulását hangsúlyozzák ki, melyeken történő továbbhaladás eredményeként már a célirányos kereséssel összeállított alapértelmezett listák készülnek.
Stubenvoll Bt
130 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
14.3 Keresési módok A felhasználó szemszögéből megközelítve az adatokat több féle módon kereshetők: • • •
Továbbirányítás Célirányos keresés Tartalom szerinti keresés
14.3.1
Továbbirányítás
A felhasználó böngészés közben az adatok egymáshoz viszonyuló kapcsolatait kihasználva jut el a számára értékes információhoz. Az oldalak egymás után kötése következtében újabb és újabb Web oldalak nyílnak meg. Ez mód nem automatizált kereső rendszerekre építkezik, de a felhasználó szemszögéből nézve mégis egyfajta keresés.
14.3.2
Célirányos keresés
Célirányos keresés esetén a felhasználó konkrét információ kikeresését szeretné elvégezni. Ilyenkor egy forma oldalnak kell a rendelkezésére állnia, ahol egyes mezők kitöltésével a kívánt információt megjelenítheti. Ezek mögött a keresési esetek mögött gyakorlatilag SQL lekérdezések bújnak meg, melyek célirányosan a megfelelő táblákból válogatják le a szükséges adatokat. Ez a keresési mód felel meg legjobban az EKNy rendszer igényeinek, mivel itt determinisztikus módon, ismert struktúrából hívjuk le az adatokat.
14.3.3
Tartalom szerinti keresés
Bizonyos esetekben a felhasználó számára ismeretlen, hogy pontosan mely területről szeretne információ megtudni, csak bizonyos kulcs szavakat ismer, melyek érdekesek a számára. Ezekben az esetekben fordulhat egy általános kereső oldalhoz, mely a megadott kulcsszavak előfordulását keresi ki a tárolt adatok közül. Ilyenkor egy olyan listát állít össze, melyek gyakorlatilag hivatkozások a megtalált adatokra. Az ezeken a hivatkozásokon történő továbbhaladás eredményeként kaphatja meg a felhasználó a számára szükséges teljes információt. A kódrendszerekben, esetleg a finanszírozási algoritmusokban elképzelhető ez a fajta keresés az EKNy rendszerben is. Természetesen itt igen kis mennyiségű adatot kell
Stubenvoll Bt
131 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
lekeresni, melynek ráadásul még a lelőhelye is pontosan ismert, ezért ez a keresés csak a felhasználó szemszüögéből hasonlít az Internetről ismert kereséshez.
14.4 Illeszkedés Igen fontos szempont, hogy az EKNy rendszer tökéletesen illeszkedjék a használatban lévő webes megjelenítő rendszerekhez. Ezért szükséges lépés a jelenlegi rendszerek feltérképezése és a kapcsolódás szintjének meghatározása. Jelenleg egy ilyen webes megjelenítő van, az ESZCSM karbantartásában lévő ágazati portál, mely egy Plumtree rendszer.
14.4.1
Plumtree
Mivel a Plumtree egy portál alapú rendszer, ami J2EE kompatibilis Web szervereken képes futni, ezért az EKNy rendszerrel való együttműködés jól megoldható. Bár a jelenleg meghatározásra került rendszerben a megfelelő szerep illetve jogosultságkörök nem kerültek egyértelmű meghatározásra, a Plumtree-vel történő együttműködést nem csak megfontolás szintjén kell lekezelni. Ennek oka, hogy bár jelen pillanatban nem tűnik indokoltnak egy széles jogkörrel és felhasználó csoporttal működni képes portálrendszer használata, de az ESZCSM jövőbeli tervei között a számos jogosultságkezelést igénylő szolgáltatások megjelenése várható, továbbá az EKNy is idővel (folyamatos továbbfejlesztések eredményeként) igényli majd a megfelelő infrastruktúra meglétét. Ez az előre gondolkodás megelőzi a jogosultságokkal kapcsolatos problémák kialakulását.
14.5 Felhasználók kezelése A Plumtree portál rendszer üzleti forgalmazása nevesített felhasználói licencelésen alapul. Ez bizonyos értelemben sok az EKNy rendszer számára. A közhiteles nyilvántartás rendszerébe akár több tízezer felhasználó is csatlakozhat, de jogosultságkörből csak pár tizet kell tudni megkülönböztetni. Az összes felhasználó nevesített kezelésére viszont a hozzáférések naplózása érdekében van szükség. Éppen ezért az azonosításra és a hitelesítésre egy kétkörös megoldást tanácsos megvalósítani, az alábbi ábra szerint.
Stubenvoll Bt
132 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Plumtree
EkNy
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Jogosultságkör
Egyedi felhasználó
A beérkező, nem nyilvános adatokra vonatkozó kérések (a még azonosítatlan felhasználótól), első körben a felhasználó azonosítását igényli. Ilyenkor a felhasználó látszólag a Plumtree-ben megvalósított ágazati portálhoz intézett kérdést, de tulajdonképpen az EKNy rendszer kezeli le, mint nevesített felhasználót. A felhasználóhoz, mint csoport, egy Plumtree azonosító van hozzárendelve, ami a felhasználó jogosultsági körét határozza meg. Azaz a Plumtree-n belül a csoportok kerülnek implementálásra, és az egyedi felhasználók az EKNy rendszerében. Természetesen egyes kitüntetett személyek egyedi konfigurációval (jogosultság körrel) rendelkezhetnek, ezért az EKNy és a Plumtree között egy az egyben megfeleltetés is lehet.
14.5.1
Jogosultság
A Plumtree rendszere tartalmazza azokat a jogosultsági szabályokat, melyek az ágazati portál számára érvényesek. Ez alól az EKNy sem kivétel. A Plumtree-ben megfogalmazott jogosultságkörök egyfajta profile-ként üzemelnek, melyhez az EKNy rendszerének üzleti logikáját futtató alkalmazás szerver profile-jai vannak hozzárendelve.
Stubenvoll Bt
133 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Profile
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Plumtree
Profile 1 Alkalmazás szerver Profile 2
Ezzel kétszintű profile kezelés valósítható meg melynek előnye, hogy az adott témakörök az alkalmazás szintjén csoportosításra kerültek, de az adott munkaterülettől függő témakör csoportosításokat a jogosultság elbírálási szintjén lehet összeállítani.
14.5.2
Azonosítás
Az egyed azonosításának nem a testre szabott jogosultságkezelés az oka, hiszen jogosultsági kör szempontjából alig néhány tíz esetről beszélünk, míg az EKNy rendszert egyedileg használóknál több ezerről. Az egyedek azonosítása a naplózások és visszakövethetőségük miatt elengedhetetlen.
Stubenvoll Bt
134 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Amikor a felhasználó bejelentkezik az EKNy rendszerébe, annak a felhasználónak azonosítása megtörténik. Ez a felhasználó hozzá van rendelve egy Plumtree-ben implementált profilhoz. Ez az összerendelés teszi lehetővé a bejelentkezett felhasználó bejutását az ágazati portál nem nyilvános részére, ami az EKNy rendszerbe történő bejutást is eredményezi. Mivel a Plumtree szintjén megvalósított felhasználok tulajdonképpen profile csoportok, melyek nagyobb létszám belépését engedélyezik az EKNy rendszerébe, ezért az alkalmazás szerver szintjén lévő felhasználók és a Plumtree szintjén lévő profile-ok csak együtt adhatnak ki megbízhatóan hitelesített felhasználót. Az a felhasználó, aki csak a Plumtree profile segítségével próbál az EKNy rendszerbe bejutni, valószínűleg illegális cselekvéseket tervez, ezért megakadályozható a bejutása. Persze vannak kivételek. Létezhetnek olyan Plumtree felhasználók, akik ténylegesen felhasználók az ágazati portálon belül. Ezeknek a felhasználóknak szabad kell legyen az átjárás az EKNy rendszerbe a saját jogkörüknek megfelelően. Ehhez viszont az kell, hogy a Plumtree felhasználónak az EKNy rendszerében a felhasználói párja meglegyen.
Stubenvoll Bt
135 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
15 Üzemeltetés 15.1 Adatbázis kezelése Az adatbázisban eltárolt adatokra nem határoztunk meg szigorú archiválási tevékenységeket, mivel ezek más intézmények által karbantartott adatok tükrözött másolatai. Ennek ellenére javasoljuk az adatok rendszeres mentését a minél egyszerűbb visszaállíthatóság érdekében. Az adatok mentésének menetére viszont nem adunk konkrét utasítást. Fel lehet használni az első részben tett javaslatot, de az üzemeltetés a számára legkényelmesebb megoldást alakíthatja ki. Az adatok elmentésére és visszaállítására javasoljuk az adatbázis szerver export-import funkcióit. Az adatbázisban bekövetkezett hibákra, inkonzisztenciára a rendszer által jelzett hibaüzenetek, végfelhasználói levelek, telefonok hívhatják fel a figyelmet, melyek adott esetben az adatok hivatkozási láncának sérülésére utal.
15.2 Alkalmazás szerver kezelése Az alkalmazás szerver a konkrét keresési és jogosultság kezelési programlogikát tartalmazza, mely a rendszer üzemeltetése során nem változik, csak továbbfejlesztések esetén, amiről a szoftver szállító cég mindig teljes telepítő készletet köteles adni. Ezen okok miatt az alkalmazás szerver tartalmáról nem szükséges mentéseket készíteni. Rendszerhiba esetén a rendszer újratelepítésével orvosolható a probléma. Az üzleti logikában bekövetkezett hibákra, inkonzisztenciára a rendszer által jelzett hibaüzenetek, végfelhasználói levelek, telefonok hívhatják fel a figyelmet, melyek adott esetben a feldolgozási kiszolgálási hibákra utalnak.
15.3 Web szerver kezelése A Web szerveren tárolt része a rendszernek a megjelenítésért felel. Ez tartalmazza a designt, és az üzleti logika felé a kapcsolatot. Mivel ennek fejlesztése is a szoftver szállító cég feladatainak körébe tartozik, ezért ennek folyamatos mentése szintén nem igény. Rendszerhiba esetén a rendszer újratelepítésével orvosolható a probléma.
Stubenvoll Bt
136 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
A Webes megjelenítésben bekövetkezett hibákra, inkonzisztenciára a rendszer által jelzett hibaüzenetek, végfelhasználói levelek, telefonok hívhatják fel a figyelmet, melyek adott esetben a megjelenési, oldalelérési hibákra utalnak.
Stubenvoll Bt
137 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
16 Katasztrófa védelem Mivel az EKNy rendszer jelenleg javasolt kiépítésében semmilyen saját kezelésű adattal nem rendelkezik, ezért még a teljes rendszer pusztulása esetén is biztonsággal újra előállítható a teljes adatbázis. Ennek következtében az EKNy katasztrófa védelem szempontjából nem igényel különösebb előírásokat.
Stubenvoll Bt
138 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
17 Képzési terv 17.1 Alapképzés EKNy rendszer hátteréül szolgáló közhiteles nyilvántartások szakmai tartalma (alapjai), az adatkezelésre vonatkozó legfontosabb jogi szabályozás és a kezelő intézmények és személyek adatai. Időtartama: 2 óra Témakörök: •
Közhitelesség fogalmának megfogalmazása, hogy minden közhiteles adatokon dolgozó személy számára érthető legyen ennek fogalma
•
Közhitelesnek minősülő adatok körének meghatározása, ami igen fontos, mivel sokan a közhitelességet a nyilvánossággal keveri
•
Nyilvánosnak minősülő adatok közének meghatározása
•
Az adatokat kezelő intézmények bemutatása, és az általuk kezelt adatok körének meghatározása
•
Karbantartói személyek és szerepkörök ismertetése
17.2 Adatfrissítés Az EKNy rendszerben tárolt adatok frissítése, az adatokat kezelő intézmények részéről szolgáltatott közhitelesnek minősülő adatok alapján. Időtartam: 2 óra Témakörök: •
Az egyes intézményekkel történő kapcsolattartás menetének ismertetése
•
Az egyes kezelői intézmények által karbantartott adatok körének felelevenítése az alapképzésből, az adatok tartalmának megismerése
•
Az adatok bekérési menetének ismertetése
Stubenvoll Bt
139 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
•
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
Az adatok EKNy rendszerbe történő betöltésének ismertetése
17.3 Rendszerkarbantartás A rendszer üzemeltetőit el kell látni azon információkkal, mely az EKNy rendszer karbantartási tevékenységeit jelentik. Időtartam: 8 óra Témakörök: •
Az adatok elmentésnek menetéről tanácsos képzést tartani, mely az adott adatbázis szoftver tükrében lehet megtenni (bár nem követelmény az adatok archiválása, a hatékony adat-visszaállítás érdekében a karbantartóknak ismerniük kell a használt adatbázis rendszer ilyen lehetőségeit)
•
Adat visszaállításáról hasonló érvek miatt, mint az adatmentésnél, szintén érdemes egy képzést tartani
•
Ismertetni kell, hogy miként lehet a program logikát visszaállítani az alkalmazás szerveren
•
Illetve, hogy miként lehet a program logikát visszaállítani a Web szerveren
17.4 Naplózási ismeretek A rendszer felügyeletével járó naplózások elvégzéséhez szükséges képzés. Időtartam: 4 óra Témakörök: •
Alapismeretek, azaz mit jelent a naplózás, milyen felelősséggel jár, milyen következményei lehetnek, mind a rendszer kapacitásaira, mind morális értelemben
• • • •
Naplózások indítása, leállítása Naplózási feltételek megfogalmazása Naplózott adatok elemzése Naplózott adatok törlése
Stubenvoll Bt
140 / 141
Budapest, 2004 szeptember 30
eEgészség Program – 27. projekt
Elektronikus Közhiteles Nyilvántartások – Megvalósítási Tanulmány
17.5 Jogosultság karbantartás Az EKNy rendszert számtalan, jogosultsággal rendelkező személy is használhatja, kiknek nem csak nyilvános adatokhoz kell hozzáférniük. Hogy ezek a személyek milyen jogosultságokkal rendelkezhetnek, azokat hogy lehet valakihez hozzárendelni, arról ennek az oktatásnak kell szólnia. Időtartam: 4 óra Témakörök: • • • • •
Plumtree és EKNy rendszer között jogosultság viszony ismertetése Elemi jogosultságok fogalmának ismertetése Szerepkörök fogalmának ismertetése Jogosultságok szerepkörökbe csoportosítási lehetőségének ismertetése Szerepkörök személyekhez rendelésének ismertetése
