Az egészségügyi információs rendszerek követelményei

Átírás

1 Az egészségügyi információs rendszerek követelményei (verzió: 9.0) Összeállította: a GYEMSZI szakértői munkacsoportja november

2 Tartalomjegyzék Tartalomjegyzék Bevezető Előszó... 1 Általános feladat meghatározás... 1 A jelen dokumentum célja... 2 A dokumentum kapcsolata az orvosszakmai környezettel Szószedet... 4 Követelmények és minősítés Központi kormányzati egészségügyi informatikai fejlesztések, a rendszerkövetelmények anyag illeszkedése Ágazati központi e-egészségügyi kulcsprojektek TÁMOP Humánerőforrás (HR) monitoring rendszer TÁMOP Országos egészségmonitorozási és kapacitástérkép adatbázis- és alkalmazásfejlesztés TIOP Nemzeti Egészségügyi Informatikai (e-health) Rendszer - Elektronikus közhiteles nyilvántartások és ágazati portál fejlesztése TIOP Nemzeti Egészségügyi Informatikai (e-health) Rendszer: központi informatikai rendszerek fejlesztése az intézményen belüli betegazonosítási rendszerek fejlesztésének biztosításához és az intézményen belüli betegazonosítási rendszerek fejlesztése EKOP 2.3. Egészségbiztosítási ügyfélkapcsolatok fejlesztése, egészségügyi rendszerekbe integrált adatkezelés és azonosítás megvalósítása TIOP Nemzeti Egészségügyi Informatikai (ehealth) Rendszer - Térségi, funkcionálisan integrált intézményközi információs rendszerek kiépítése TÁMOP Nemzeti Egészségügyi Informatikai (ehealth) Rendszer bevezetésének támogatása módszertan - és képzésfejlesztés A Semmelweis-Terv egyéb fejlesztéspolitikai konstrukcióihoz (pályázataihoz) való viszony Az informatikai rendszerek követelményei Az informatikai infrastruktúra architektúrális követelményei Bevezetés Jogi formában rögzítendő ajánlások az egészségügyi informatikai rendszerek védelme érdekében Általános architekturális követelmények Infrastruktúrális követelmények Mentési, archiválási, visszatöltési követelmények Biztonságos működéssel-működtetéssel kapcsolatos követelmények Az egészségügyi ellátási szintek specifikus követelményei Az alapellátás specifikumai Az szakellátás specifikumai A betegfelvétel során elvárt minimális funkcionalitás A Járóbeteg szakellátás során elvárt minimális funkcionalitás A fekvőbeteg szakellátás során elvárt minimális funkcionalitás Az elektronikus kórlaptól és lázlaptól elvárt minimális funkcionalitás Az ápolási dokumentációtól elvárt minimális funkcionalitás Intézményi működést támogató informatikai rendszerek általános és specifikus követelményei Intézményi működést támogató informatikai rendszerek általános követelményei (valamennyi ilyen típusú megoldásnál) Intézményi működést támogató informatikai rendszerek specifikus követelményei (a releváns megoldásoknál) Intézményközi rendszerszolgáltatások általános és specifikus követelményei Intézményközi rendszerszolgáltatások általános követelményei Intézményközi technológiai protokollok követelményei Összeállította a GYEMSZI szakértői munkacsoportja i

3 Tartalomjegyzék 4.5 Üzemeltetési követelmények Szolgáltatásmenedzsment kérdések Szolgáltatás tervezés Szolgáltatás bevezetés Szolgáltatás üzemeltetés A fejlesztési pályázat és a megvalósítási projekt követelményei, minősítése Az intézmény felkészültségének követelményei A fejlesztés elhelyezése az intézmény működésében Intézményi követelmények a fejlesztés előkészítésére A beszállító felkészültségének és ajánlatának követelményei Beszállítói követelmények Az ajánlott megoldás illeszkedése a kiíráshoz A fejlesztés előkészítésének, megvalósításának és eredményének, követésének követelményei A fejlesztés előkészítésének tervezési feladatai és módszerei A Projekt Alapító Dokumentum követelményei A fejlesztéssel kapcsolatos szerződés(háló) kialakításának követelményei Szoftverszerződésekkel kapcsolatos elvárások A fejlesztés megvalósítása követésének követelményei A fejlesztés eredményének követelményei A követelmények alapján folytatott minősítés módszertana, folyamata és szervezete A minősítés célkitűzése, alanyai Információs rendszerek Elvárás a minősítő eljárással szemben Az eljárás kimeneti pontja A minősítés eredményterméke A minősítés eredményének hatása a vizsgált objektumra, intézményre és ágazati szervekre Információs rendszerfejlesztési projektek Elvárás a minősítő eljárással szemben Az eljárás kimeneti pontja A minősítés eredményterméke A minősítés eredményének hatása a vizsgált objektumra, intézményre és ágazati szervekre Információs rendszerfejlesztési projektet vezető egészségügyi intézmény Elvárás a minősítő eljárással szemben Az eljárás kimeneti pontja A minősítés eredményterméke A minősítés eredményének hatása a vizsgált objektumra, intézményre és ágazati szervekre A minősítő eljárás módszertana A minősítő eljárás során alkalmazott módszer Információs infrastruktúra minősítése Egészségügyi információs rendszerek szolgáltatásainak minősítése Információs rendszerfejlesztési projekt minősítése Szervezet minősítése az információs rendszer fejlesztési projekt szempontjából A rendszerminősítés folyamata, a minősítések publikálása Információs rendszer minősítésének folyamata Fejlesztési projekt minősítésének folyamata Szervezet minősítésének folyamata A rendszerminősítés szervezete/intézménye A minősítő szervezet/intézmény jogállása Javasolt jogszabályi változtatások Mellékletek A követelmények rendszerét meghatározó fejezetek Az egészségügyi információs rendszerek nemzetközi minősítési követelményei és gyakorlata A fejezet célja A globális egészségügyi trendek hatása az egészségügyi informatikára Összeállította a GYEMSZI szakértői munkacsoportja ii

4 Tartalomjegyzék Az Európai Unió egészségügyi ellátással kapcsolatos szabályozása és politikája Egészségügyi gazdasági információs rendszerek és VIR rendszerek speciális adatkezeléssel kapcsolatos minősítése ajánlásai Törvényi háttér Hatókör Személyi adatok védelme a nem klinikai rendszerekben A személyes adatok kezelésével kapcsolatos tevékenységek naplózása A személyes adatok továbbításával kapcsolatos tevékenységek naplózása Egyéb adatok továbbításával kapcsolatos elvárások Intézményi portálok közzététellel kapcsolatos tartalmi követelményei Törvényi háttér Szervezeti és személyzeti adatok Tevékenységre, működésre vonatkozó adatok Gazdálkodási adatok Várólistával kapcsolatos adatok Közbeszerzési eljárással kapcsolatos adatok A telemedicina alkalmazásának helyzete Magyarországon, a telemedicina rendszerkövetelményei Szabványosítás Finanszírozás Orvosi gyakorlatba vétel Jogszabályi környezet IT konszolidációs munkacsoport + Nemzeti Fejlesztési Minisztérium (NFM) által gondozott IT követelmény-rendszer integrálása, intézményi üzemeltetési-szabályozási konzekvenciák meghatározása Előzmények, összefoglaló Az egészségügyi információs rendszerkövetelmények anyag megfelelése a kormányzati infokommunikációs konszolidációs intézkedési tervben leírtakhoz Informatikai szabályozás és informatikai szervezete kormányzat / egészségügy Konklúzió A dokumentum szerzői Összeállította a GYEMSZI szakértői munkacsoportja iii

5 Bevezető 1 Előszó BEVEZETŐ A 21. század első évtizedében jelentős erőfeszítések történtek 1 az egészségügyi ágazatban működő információs rendszerek közötti interoperabilitás felépítésére. Az informatikai rendszerek integrálhatóságát ma is annak érdekében kell megtenni, hogy egyrészt az informatikai megoldások valóban segítsék a felhasználóikat a társadalmat érő egészséggel kapcsolatos hatások (betegellátás, megelőzés, rehabilitáció, népegészségügy, stb.) kezelésében, másrészt az egészségügyet szervező, döntési helyzetbe kerülő szereplők legyenek azok állami, vagy szakmai szervezetek valós információkat kaphassanak a működő egészségügyről, jó döntések meghozatalához. A jelen dokumentum a fenti igény kielégítését kívánja támogatni, azok számára készült, akik az egészségügyi informatika működtetésében, fejlesztésében dolgoznak, hogy tevékenységük eredményeképpen ki tudjon alakulni az a szakmailag és módszertanilag korszerű ismeretekre alapozott, transzparens informatikai üzemeltetési és fejlesztési szolgáltatási tér, amely mind az ellátó intézmények, mind az ágazatirányító intézmények részéről minősíthető, és egyre inkább homogenizált, magas szolgáltatási szinteken szolgálja az ágazat informatikai működtetését. Általános feladat meghatározás Az ágazati informatikáért felelős kormányzati szerv az ESKI (2011. május 1-től GYEMSZI) azt a feladatot kapta, hogy dolgozzon ki egy feltételrendszert (stratégiai fejlesztési projekt tartalmak, azokat működtető intézmény és folyamat rendszer, ágazati informatikai koordináció) amely elősegíti egymással együttműködő ágazati informatikai folyamatok és rendszerek kialakulását, ezáltal az ágazatban keletkező információkat elérhetővé teszi mindazok számára, akik munkájához azok szükségesek. A tervek között egy fontos tématerület a folyamatban lévő és jövőbeli információs beruházások és fejlesztések olyan mederbe terelése, hogy módszertanilag a legkorszerűbb követelmények által ezek kivitelezése és fenntartása ellenőrizhetővé és minősíthetővé váljék. Fontos az uniós források összehangolt felhasználása, és az egyes egyedi beruházások olyan szemléletű tervezése, hogy az őt körülvevő rendszerekkel együttműködők legyenek, készüljenek fel a később bevezetésre kerülő más megoldások hatásainak kezelésére. Fontos 1 Az első az között lezajlott világbanki Kórházvezetést Támogató Információs rendszerfejlesztési (KTI) projekt volt, amely a szakellátásban (főleg a kórházi fekvőbeteg ellátásban) volt hivatva integrált HIS rendszereket fejleszteni, ezáltal letisztítani a hektikusnak mondható, uralkodó informatikai piacot, másrészt a kórházakat csoportokba szervezve kialakítani olyan együttműködéseket, amelyek a szabványosság és interoperabilitás szabályrendszerével kívánta a színvonalat emelni, a hazai kórházakat a projektszerűen végiggondolt fejlesztési folyamatra rávezetni. A KTI 24 kórházra korlátozódott, mivel az 1998 ban történt kormányváltás a világbanki kölcsönt amely 1992 ben köttetett drágának ítélte, és a projektet az első fázisa után leállította, bár készen állt a második követő fázis, amely a kórházak döntő többségére kiterjesztette volna a projekt eredményeit. A piac viszont az első fázis hatására letisztult, a jelenleg működő 4 5 meghatározó jelentőségű informatikai fejlesztő a KTI program hatására lett piacvezető. A második a HEFOP (Humán Erőforrás Fejlesztési Operatív Program) 4.4 intézkedése volt az első Nemzeti Fejlesztési Terv keretében a hátrányos helyzetű 3 régió interoperábilis egészségügyi intézményközi rendszerének kialakítására. Tekintettel arra, hogy a KTI tervezői indították útjára a HEFOP 4.4 et, sok kitűzött cél a világbanki fiaskó pótlását, illetve újragondolását valósította volna meg. Jelentős hangsúlyt kapott VOLNA az intézmények közötti információcsere, az interoperabilitás olyan akkor már máshol megjelenő szolgáltatásokkal kiegészítve, mint az e Recept, e Konzílium, stb. Az intézkedés végrehajtásakor az egészségügyi kormányzat viszont nagyobb teret hagyott az intézményen belüli fejlesztéseknek (érthető okokból), amely eredményeképpen csak egy korlátozott funkcionalitású, és a bekapcsolt intézményeket mélyen megosztó intézményközi rendszer alakulhatott ki, amely a szabványosítás területén sem ért el áttörést, az egészségbiztosítás, az alapellátási rendszerek kívül maradtak a projekt terjedelmén. Összeállította a GYEMSZI szakértői munkacsoportja 1

6 Bevezető továbbá a fejlesztési projekteket végrehajtó informatikai szállítók, valamint a velük üzleti kapcsolatban álló egészségügyi intézmények IT szervezetei számára olyan szakmaimódszertani ismereteket koncentráltan összegyűjteni, ezekre az ismeretekre követelményeket megfogalmazni, amelyeket egy egészségügyi intézmény önmaga értelemszerűen nem tudna kellő koherenciával összeállítani. A jelenleg működő információs rendszerek sem maradhatnak ki a fenti megfontolások szerinti vizsgálatból, hiszen a folyamatos fejlesztések közepette azok tovább kell, hogy működjenek. Szükséges tehát egy általánosan (de egészségügyi ágazat-specifikusan) megfogalmazott feltételrendszer kidolgozása mellett olyan értékelési rendszer megalkotása is, amely a feltételek teljesülését vizsgálja a működő rendszerek esetén. Nem feledkezhet el az egészségügyi informatikáért felelős szerv arról sem, hogy foglalkozzon az egészségügyi intézmények a projektek kedvezményezettjei fejlesztésben betöltött szerepének meghatározásával, azzal a szervezeti követelményrendszerrel, amely biztosítja a fejlesztési projektek zökkenőmentes és hatékony levezetésének lehetőségét az egyes intézményeken belül. A jelen dokumentum célja A GYEMSZI a fenti célokat egy ajánlásrendszerrel is segíteni kívánja. A feladat meghatározásában lényeges szempont volt a közérthetőség, a száraz, tudományoskodó megfogalmazások kerülése, valamint a kidolgozandó informatikai feltételrendszer és a rendszerminősítési kritériumok praktikus, gyakorlati alkalmazhatósága. Ugyanakkor le kell szögezni, hogy a megfogalmazás egyedisége ellenére a hazai és nemzetközi informatikai sztenderdek, módszertanok és ajánlások az anyag összeállításánál figyelembe lettek véve (ITIL, uniós- és általános pályázati követelmények, szabványok, közismert projektvezetési módszertani alapok - PRINCE2, PMI stb.). Tehát összefoglalva a jelen dokumentum céljai: Ajánlás, illetve követelményrendszer gyűjteményt közzétenni az egészségügyben megvalósuló informatikai üzemeltetési feladatok, valamint végrehajtandó informatikai fejlesztések (uniós forrásból támogatott központi projektek, intézményi pályázatok) színvonalas megvalósítása és a későbbiekben együttműködni képes megoldások létrehozása érdekében; Alapkövetelményt adni egy jövőbeli minőség-hitelesítési folyamatnak, amely a követelmények alapján áll, és azok szerint kerül végrehajtásra. A Semmelweis tervben megfogalmazott cél, hogy a jelen követelményrendszer alapján az ágazati informatika bekerüljön az akkreditálandó területek közé, az alábbiakra való közvetlen hatással: o Az ágazati adat-áramlás és intézményközi interoperabilitás o Üzemeltetési sztenderdek, szolgáltatási színvonal és szintek egységesedése, a színvonal emelkedése o Az ágazat stratégiai fejlesztési projektjeivel való összhang biztosítása informatikai képességek szintjén o Ágazati szereplők (intézmények, kórházak, stb.) közpénzzel támogatott informatikai fejlesztéseinek kötelező tartalmi elemei o Ágazati szoftver / informatikai rendszer akkreditáció bírálati szempontjai o Informatikai beruházások költségeinek jelentős csökkentése o Az ágazaton belüli és kívüli informatikai szállítóktól való függőség csökkentése Összeállította a GYEMSZI szakértői munkacsoportja 2

7 Bevezető Az egészségügyi kormányzat határozott szándéka a Semmelweis terv megalkotását tekintve mintaként az ajánlásgyűjtemény folyamatos gondozása. A dokumentum kapcsolata az orvosszakmai környezettel Az eredeti szándék szerint egy informatikai szemléletű ajánlásgyűjtemény kell, hogy elkészüljön. Az anyag viszont nem tud, és nem is akar attól eltávolodni, hogy az egészségügyben működő információs (informatikai) rendszerek kérdéseit alapvetően nem lehet a gyógyító tevékenységtől, annak törvényszerűségeitől elvonatkoztatni. A jelen ajánlásgyűjtemény nem kíván orvosszakmai (vagy bármely más szakmai) folyamatokat alkotni, viszont az orvosszakmai folyamatokat informatikai aspektusból jól és magas színvonalon kiszolgáló működés ágazat specifikus feltételeit kívánja összegezni. Ezért bár nem tér ki a kiszolgálandó egészségügyi szakmai folyamatok ismertetésére mégis azzal a céllal lép fel, hogy azokat kell alátámasztania. Összeállította a GYEMSZI szakértői munkacsoportja 3

8 2 Szószedet adatcsoport: olyan, összetartozó adatsorok, melyek valamely adatkezelési okból logikai egységek képeznek (pl. egy beteg laboratóriumi leletsorozata). adatszerkezet (adatstruktúra): az adatszerkezetek adatcsoportok osztályai, definiált belső és külső kapcsolatokkal. aktív fekvőbeteg szakellátás finanszírozása: DRG-alapú, homogén betegségcsoportokba (HBCS) való besorolásra támaszkodó esetátalány finanszírozás. architektúra: egy rendszer alapvető szerkezeti felépítése, amely a komponenseiben, ezek egymáshoz ill. a környezethez való kapcsolódásaiban, valamint azon elvekben fejeződik ki, amelyek a rendszer tervezését, működését és továbbfejlesztését meghatározzák. beszállító: az a cég vagy szervezet, amely az információs fejlesztések kapcsán az egészségügyi intézmények számára javakat szállít, megoldást fejleszt és szolgáltatást nyújt, valamint rendelkezik ezen tevékenységek végzéséhez szükséges ismeretekkel és képességekkel. egészségügyi adat: a betegről, a beteg állapotáról és az ellátó intézmény működéséről szóló elemi ismeret. eredménytermék: a minősítő eljárás által célba vett eredmények (a minősítés eredménye) összefoglaló dokumentuma(i) fejlesztés: az informatikai erőforrások megteremtésére, bővítésére, korszerűsítésére vonatkozó folyamat (projekt) akár belső (saját), akár külső (EU-s, Norvég-Alap, stb.) vagy vegyes (külső és belső) finanszírozású HIS (Healthcare Information System) : Egészségügyi információs rendszer intézmény: az egészségügyi ágazatban a betegellátással, népegészségüggyel és finanszírozással kapcsolatban álló szervezet. minősítés alanya: az információs rendszer, az informatikai fejlesztési projekt valamint az információs beszállító, vagy ilyet üzemeltető egészségügyi költségvetési intézmény szervezete, amely vonatkozásában a követelményeknek való megfelelés vizsgálata folyik. minősítő eljárás: a követelményeknek való megfelelés vizsgálatának összefoglaló megjelölése informatikai megoldásszállító: Olyan cég, vagy konzorcium, amely egy szerződéses partnerként képes a fejlesztés minden aspektusát maga megvalósítani illetve megvalósíttatni, beleértve a szükséges hardver, szoftver elemeket, a szükséges oktatást, képzést, implementációt, adaptációt valamint kellő színvonalú üzemeltetést és rendszertámogatást. Projekt menedzsmentet és informatikai szakmai hátteret tud biztosítani a megvalósítás és a szolgáltatási szerződés teljes időtartama alatt. A kiírásban megfogalmazott célok megvalósulásáért kellő jogi és szakmai garanciát tud vállalni. Az elvárásoknak megfelelő szoftvereket tudja biztosítani. Folyamatosan rendelkezik (a megvalósítási és a támogatási szakaszban is) e szoftverek üzemeltetéséhez, módosításához szükséges engedélyekkel, szakértelemmel és szakembergárdával. Összeállította a GYEMSZI szakértői munkacsoportja 4

9 Folyamatosan biztosítani tudja (a megvalósítási és a támogatási szakaszban is) az elvárásoknak megfelelő hardver eszközök beszerzéséhez, telepítéséhez, paraméterezéséhez, javításához, működtetéséhez szükséges szakértelmet és szakembergárdát vagy bizonyítottan szerződéses jogviszonyt létesít ezen funkciók ellátására a projekt megvalósítás és üzemeltetés teljes szakaszára. A megvalósított rendszerre vonatkozóan jogszabálykövetést, szoftverfejlesztést, készenlétet és ügyeletet valamint hibaelhárítást tud biztosítani. információs rendszer: az informatikai erőforrások összessége, amely szolgáltatások nyújtása formájában támogatja az egészségügyi intézmény munkáját járóbeteg szakellátás (és diagnosztika) finanszírozása: OENO-kódok szerint, beavatkozásokhoz kapcsolódó német pontszámon alapuló teljesítményfinanszírozás. kimeneti pont: a minősítő eljárás eredménytermékének előállítási pontja, általában az eljárás vége kritikus hiba: kritikus hibának kell tekinteni minden olyan rendellenességet, amelynek fellépése miatt a rendszer illetve a szolgáltatási folyamat megsérti a rendelkezésre állásra és a válaszidőre előírt követelményeket. minősítő szerv: a minősítési eljárás viszonylatában nevesített, abban résztvevő, ellenőrző vagy irányító hatáskörű (informatikai) szervezet SLA: az angol Service Level Agreement kifejezés rövidítése, ami magyarul szolgáltatási szint megállapodást jelent. SNMP: Simple Network Management Protocol SOA (Service Oriented Architecture): magyar terminológiával Szolgáltatás Alapú Architektúra. Software as a Service (SaaS): Alkalmazás (szoftver) biztosítása a felhasználóknak szolgáltatásként. A szolgáltatás menedzselt informatikai alkalmazás biztosítását jelenti, így az alkalmazás napi működtetését, üzemeltetését, felügyeletét a szolgáltató végzi, ezért szerződéses felelősséget vállal; az alkalmazás szerver oldali infrastruktúrája, az alkalmazás licenszek a szolgáltató eszközei közt vannak nyilvántartva; a szolgáltató a szolgáltatást írásban foglalt szolgáltatási szerződésen keresztül biztosítja az igénybevevő számára. szemantikus interoperabilitás (semantic interoperability): az adatok olyan megosztásának képessége heterogén rendszerekkel, ami érthetővé teszi azokat formálisan definiált domén koncepciók szintjén. vékony kliens: olyan a felhasználói munkaállomásokon alkalmazott technológia melynek következtében a felhasználó rendelkezésére álló eszközön (állapot mentes célhardver) alkalmazás nem fut. Ez az eszköz kizárólag az input output forgalom biztosítására szolgál. A célhardver helyett gyári vékonykliens emulációt biztosító (deszktop virtualizáció) megoldás is ennek tekinthető (pl. Citrix). Összeállította a GYEMSZI szakértői munkacsoportja 5

10 KÖVETELMÉNYEK ÉS MINŐSÍTÉS 3 Központi kormányzati egészségügyi informatikai fejlesztések, a rendszerkövetelmények anyag illeszkedése 3.1 Ágazati központi e-egészségügyi kulcsprojektek Az anyag elkészítésének fő célja, hogy megfelelő szakmai támaszt, hátteret és közvetlenül átültethető követelményrendszert nyújtson az ágazatban a jövőbeni kormányzatilag elindítandó központi informatikai projektekhez és az intézmények infokommunikációs fejlesztéseihez, amelyek az egészségügy általános hazai megújítását célzó Semmelweis Terv 2 és a kormányzat infokommunikációs stratégiai programjának, a Digitális Megújulás Cselekvési Terv 3 nek is fontos részét képezik. A Nemzeti Egészségügyi Informatikai Rendszer (e-health) megvalósítását célzó, annak érdekében kidolgozott koncepció fejlesztéspolitikai intézkedései, vagyis a Társadalmi Infrastruktúra Operatív Program (TIOP), Társadalmi Megújulás Operatív Program (TÁMOP) és Elektronikus Közigazgatás Operatív Program (EKOP) as konstrukciók megvalósítását (azokat nem konkrétan nevesítetten) a Semmelweis Terv 1208/2011. kormányhatározat 13. pontja irányozza elő. Az egészségügyi ágazati informatikai koncepció, az azokban megvalósítani tervezett intézkedések, fejlesztések alapvető céljai a következők: Az állam fokozott szerepvállalása az ellátásszervezésében és kapacitás-tervezésében. Transzparens ágazati működés és elszámolás kialakítása. Integrált támogató rendszerek megalkotása a funkcionális területi integráció, a progresszív ellátásszervezés és az intézményközi együttműködés lehetővé tételére. Szükséglet alapú kapacitástervezést szolgáló informatikai megoldások. A központi kormányzati egészségügyi informatikai projektek kapcsán használt fogalomrendszer: - Központi projektek: A Semmelweis Terv szakmai tartalmának megvalósítását támogató informatikai stratégiai központi fejlesztési projektportfólió (TIOP-TÁMOP-EKOP projektek) - Egységes elvek, követelmények és protokollok alapján működő integrált, egyes kiemelt funkciókat központilag biztosító egészségügyi ágazati informatikai rendszer (e-health rendszer): a központi projektek keretében induló fejlesztések eredményeként létrejövő rendszer, melynek két pillére: A. Központi komponensek TÁMOP Humánerőforrás (HR) monitoring rendszer TÁMOP Országos egészségmonitorozási és kapacitástérkép adatbázis- és alkalmazásfejlesztés 2 Semmelweis Terv eroforras miniszterium/egeszsegugyert felelosallamtitkarsag/hirek/kormanyhatarozat az egeszsegugyi struktura atalakitasrol 3 Digitális Megújulás Cselekvési Terv fejlesztesi miniszterium/infokommunikacioertfelelos allamtitkarsag/hirek/digitalis megujulas a magyar kreativitas kiteljesiteseert Összeállította a GYEMSZI szakértői munkacsoportja 6

11 TIOP Nemzeti Egészségügyi Informatikai (e-health) Rendszer - Elektronikus közhiteles nyilvántartások és ágazati portál fejlesztése TIOP Nemzeti Egészségügyi Informatikai (e-health) Rendszer: központi informatikai rendszerek fejlesztése az intézményen belüli betegazonosítási rendszerek fejlesztésének biztosításához és az intézményen belüli betegazonosítási rendszerek fejlesztése EKOP 2.3. Egészségbiztosítási ügyfélkapcsolatok fejlesztése, egészségügyi rendszerekbe integrált adatkezelés és azonosítás megvalósítása TIOP Nemzeti Egészségügyi Informatikai (e-health) Rendszer - Térségi, funkcionálisan integrált intézményközi információs rendszerek kiépítése TÁMOP Nemzeti Egészségügyi Informatikai (e-health) Rendszer bevezetésének támogatása módszertan - és képzésfejlesztés B. Központilag szabályozott egységes elvárások alapján folyamatosan fejlesztett lokális rendszerek A projektek / rendszerek egymáshoz kapcsolódását az alábbi ábra szemlélteti: Az e-health rendszer összefoglaló ábrája Összeállította a GYEMSZI szakértői munkacsoportja 7

12 Az intézményi nézet a következő: Az e-health rendszer intézményi koncepciója A GYEMSZI jövőképe szerint az e-health rendszer az egyes kiemelt fejlesztési projektek eredményeként úgy alakul ki és működik, hogy: minden egészségügyi intézmény, ideértve a járó- és fekvőbeteg ellátási egységeket megmarad önálló entitásnak, saját hálózaton, saját rendszerekkel, saját eszközökkel, de úgy, hogy lesznek olyan alkalmazások, amelyeket egy központi SaaS rendszer biztosít. minden egység elektronikusan kapcsolódik egymáshoz, ezáltal minden egység számára biztosított az integrált működés lehetősége (kétirányú adatkommunikáció közvetlenül vagy egy központon keresztül). Megépül egy új egészségügyi informatikai szolgáltató központ, amely integrációs és intézményközi adatkommunikációt biztosító központi funkciót egyaránt betölt. Ez jelent: irányítást, mely a GYEMSZI hatáskörébe utalt feladat (SaaS rendszer működtetése, szerverpark üzemeltetés, központi szolgáltatások tervezése és folyamatos továbbfejlesztése, licencek biztosítása, help-desk fenntartása, adatvédelmi, adatbiztonsági, kommunikációs követelmények érvényesítése, lokális IT rendszerek fejlesztésével és üzemeltetésével kapcsolatos specifikációk karbantartása, oktatás). Az irányítás részeként a GYEMSZI hatáskörébe tartozik az egészségügyi informatikai ágazati stratégia elkészítése és karbantartása. A GYEMSZI az érvényes informatikai stratégiának alárendelten a központi komponensek eredményeként Összeállította a GYEMSZI szakértői munkacsoportja 8

13 o professzionális szakmai mátrix irányítási rendszert épít ki az egészségügy valamennyi lokális informatikai szervezettel rendelkező entitása esetében o professzionálisan szolgálja ki a területi ellátásszervezőket és működteti az ágazatirányításhoz szükséges valamennyi magas szintű, összegzett információs és elemzési bázisokat o professzionális oktatási rendszert épít ki és működtet (oktatás, oktató képzés, oktatási segédletfejlesztés /szoftver stb.) o virtuális és valós fejlesztési pilot- és teszt környezeteket épít ki és működtet. infrastruktúrát, amely professzionális, adat/biztonságtechnikailag legmagasabb szintű szerverközpontot/szolgáltatóközpontot jelent, ahol indextárolás és adattárolás folyik; alkalmazásokat, szoftver szolgáltatásokat (pl. bérszámfejtési modult, portált), amelyeket a fenntartó biztosít az entitásoknak, díjmentesen); az intézmények szabályozott hozzáféréssel rendelkező munkatársai részére adathozzáférési jogosultságot és lehetőséget, amikor konkrét esetekben konkrét páciensek esetében, teljes esettörténet és leletek állhatnak rendelkezésre. A központi rendszerben ugyanazok az adatok vannak nyilvántartva, mint az egyedi entitásoknál, de minőségileg másként, esettörténetbe rendezve, minden elemei adattal egyetemben (leletek). Az egyes entitásoknál az egészségügyi ellátások során képződött egészségügyi dokumentációk/adatok automatikusan kerülnek be az adatközpontba. A jövőben cél az, hogy az egészségügyi szakmai testületek által definiált szabványos egészségügyi dokumentumok (ide értve a gyógyszerterápiás, a környezetre veszélyt hordozó jellemzőinek stb. adatait) egységes adatszerkezetben központilag tárolódjanak. A központilag tárolt adatok erős autentikáció és a páciens nyilatkozata függvényében a gyógyítás érdekében elérhetők az arra jogosult entitások számára. Extra hozadék, hogy működő módon definiálódnak azon szabványos egészségügyi dokumentumok melyek jelenleg intézet- és szakmaspecifikus módon vannak jelent a rendszerben, ráadásul EU és nemzetközi projektekhez kapcsolva megnyílik az út a konkrét nemzetközi interoperabilitás irányába. A konstrukciókhoz, fejlesztésekhez a következőképpen kapcsolódik és illeszkedik a rendszerkövetelmények és audit anyag TÁMOP Humánerőforrás (HR) monitoring rendszer Konstrukció forráskerete: 500 millió Ft Eljárásrend: kiemelt projekt Kedvezményezett: GYEMSZI és EEKH konzorciuma A projekt célja olyan egységes ágazati HR monitoring rendszer és adattárház kiépítése, amely jól szolgálja a kormányzati és/vagy ágazati, intézményi, képzőhelyi szintű döntés- Összeállította a GYEMSZI szakértői munkacsoportja 9

14 előkészítését és döntéstámogatását, illetve támogatja az ágazati HR-stratégia kialakítását, továbbá lehetővé teszi az ágazati humánerőforrás jellemzők, trendek nyomon követését. A rendszerkövetelmények és audit anyag kapcsolódása a konstrukcióhoz: A projektből származtatott követelmények: Központi projekt felé szabott követelmény: Interface kialakításának szükségessége, mely lehetővé fogja tenni, hogy az egyes intézményeknél működő HR rendszerek automatikusan csatlakozhassanak a HR monitoring adatbázishoz. Lokális rendszerek felé szabott követelmény: Az anyag intézményi működést támogató rendszerek fejezetében (4.3) az alap, járó- és fekvőbeteg ellátó intézményeknél az ott működő (vagy bevezetésre kerülő) HR, bérszámfejtési moduloknál ( ) követelményként javasoljuk feltüntetni a létrejövő központi HR monitoring rendszer felé (amikor az is rendelkezni fog ilyen kapcsolódási képességgel, vagyis nyitott lesz a közvetlen adatkommunikációra) interface kialakítását TÁMOP Országos egészségmonitorozási és kapacitástérkép adatbázis- és alkalmazásfejlesztés Konstrukció forráskerete: 1 milliárd Ft Eljárásrend: kiemelt projekt Kedvezményezett: GYEMSZI, ÁNTSZ és OEP konzorciuma A projekt célja, hogy létrejöjjön egy, a magyar lakosság egészségi állapotát, és az egészségügyi rendszer leíró jellemzőit monitorozó rendszer, amely támogatja az egészségorientált kormányzati és egészségpolitikai döntéshozatal kialakítását. A projekt keretében kialakításra kerül a lakosság egészségi állapotát, az egészségügyi ágazat kapacitásait és valós felhasználásait jellemző módszertan, szabályozásra kerülnek az egészségügyi ágazat országos és helyi intézményeivel való szakmai együttműködések, információ szolgáltatási tartalmak, valamint létrejönnek azon csatornák, melyeken keresztül a monitorozó szervezet eredmény termékei visszacsatolásra kerülnek. A rendszerkövetelmények és audit anyag kapcsolódása a konstrukcióhoz: A projektből származtatott követelmények: Központi projekt felé szabott követelmény: Interface kialakításának szükségessége, mely lehetővé fogja tenni, hogy az egyes intézményeknél működő vezetői információs és döntéstámogató rendszerek automatikusan csatlakozhassanak a kapacitástérkép adatbázishoz Lokális rendszerek felé szabott követelmény: Javasoljuk, hogy az alap, járó- és fekvőbeteg ellátó intézményeknél az ott működő (vagy bevezetésre kerülő), az anyag részében található specifikációkkal rendelkező Döntéstámogató (vezetői információs) rendszereknél legyen meg az a Összeállította a GYEMSZI szakértői munkacsoportja 10

15 képesség, mely lehetővé teszi (amennyiben az létre fog jönni) az Országos egészségmonitorozási és kapacitástérkép adatbázis közvetlen lekérdezését TIOP Nemzeti Egészségügyi Informatikai (e-health) Rendszer - Elektronikus közhiteles nyilvántartások és ágazati portál fejlesztése Projekt forráskerete: 2,1 milliárd Ft Eljárásrend: kiemelt projekt Kedvezményezett: GYEMSZI, ÁNTSZ, OEP és EEKH konzorciuma A projekt célja, hogy megvalósuljon a közhiteles elektronikus törzsek előállítása, valamint a törzsek frissítését, karbantartását biztosító ügyviteli folyamatokat kiszolgáló informatikai rendszerek, a törzsek biztonságos, hiteles elektronikus közzétételét biztosító rendszer létrehozása és üzembe helyezése. A projekt révén létrejön az ágazat közhiteles alapadatainak katalógusa és ezek egészségügyi ágazati portálon megvalósított nyilvántartási rendszere. Meghatározásra kerülnek az egyes adatkörök elsődleges felelősséggel bíró egyszeres adatgazdái. Az egészségügyi ágazat szereplői - és bármely egyéb szereplő - csakis a létrejövő közhiteles portálon keresztül juthat közhiteles egészségügyi ágazat alapadatokhoz. Áttekintésre, szabványosításra és egységesítésre kerül az ágazatban használatos legfontosabb jelentések adattartalma. A rendszerkövetelmények és audit anyag kapcsolódása a konstrukcióhoz: A projektől származtatott követelmények: Központi projekt felé szabott követelmény: Interface kialakításának szükségessége, mely lehetővé fogja tenni, hogy az egyes intézményeknél működő egészségügyi szakmai informatikai rendszerek lekérdezhessék az egészségügyi ágazat közhiteles adattörzseit, illetve az intézmények képesek legyenek jelentéseiket a központi validátorhoz eljuttatni. Lokális rendszerek felé szabott követelmények: Az anyag Az alapellátás specifikumai és a A szakellátás specifikumai részekben alapvető követelményeként javasoljuk deklarálni a közhiteles portállal való vertikális kétirányú adatkommunikációt valamennyi egészségügyi intézményben működő informatikai rendszer esetében. Emellett érdemes a 4.4 Intézményközi rendszerszolgáltatások általános és specifikus követelményei részben is kitérni arra, hogy az ilyen rendszereknél szükséges lenne megfelelő interfész kialakítása az elektronikus ágazati portál és közhiteles validátor felé (amikor majd az létrejön és működik). Amennyiben lesz TIOP nek közép magyarországi régiós (KMR) tükörkonstrukciója annál is értelemszerűen ugyanúgy javasoljuk az anyag illesztését. A TIOP KMR-es tükörprojekt indítása, finanszírozásának előteremtése az EU-s források felhasználásának szabályai, a szükséges arányosítás miatt gyakorlatilag elkerülhetetlen, bár egyelőre a Közép Magyarországi Operatív Program (KMOP) as Akciótervében nincs ilyen intézkedés. Összeállította a GYEMSZI szakértői munkacsoportja 11

16 3.1.4 TIOP Nemzeti Egészségügyi Informatikai (e-health) Rendszer: központi informatikai rendszerek fejlesztése az intézményen belüli betegazonosítási rendszerek fejlesztésének biztosításához és az intézményen belüli betegazonosítási rendszerek fejlesztése Konstrukció forráskerete: 4,2 milliárd Ft Eljárásrend: kiemelt projekt Kedvezményezett: GYEMSZI A projekt célja egy központi elektronikus alkalmazás-szolgáltató központ kialakítása az egészségügyi ellátórendszerben, amely lehetővé teszi az intézményi feladatellátás és belső működés támogatását a megosztott szolgáltatások elvének alkalmazásával, költséghatékony és finanszírozható működés biztosításával. A központ szolgáltatása kiterjed az intézményen belüli elektronikus páciensazonosítás megteremtése mellett a vényforgalom szabályozásán keresztül, a kórházi rendszerekből közvetlenül, zárt rendszerben automatikusan generálódó betegforgalmi jelentésekig (amelyek a finanszírozási elszámolás alapját is képezik) és az intézményi működést támogató informatikai megoldásokig. A projekt főbb elemei a következők: Informatikai rendszerek kialakítása az elszámolási tranzakciók küldéséhez és fogadásához a szolgáltató intézményeknél és a központi elszámoló intézményeknél. Az intézményi rendszerekhez való csatlakozást lehetővé tevő szabványos szoftverek fejlesztése. Országos erecept és háziorvosi rendszer illesztése az elszámoló rendszerhez. A transzparens elszámolás alapköveként szolgáló elektronikus azonosító kártya kezeléséhez szükséges rendszerek biztosítása az intézményeknek. Az egészségügyi ellátórendszer intézményei számára transzparens elszámoláshoz szükséges országosan egységes komponenseket támogató szoftverek internetalapú szolgáltatásként nyújtása egy professzionális, adat és biztonságvédelmileg magas színvonalú ASP / SaaS központból. Regionálisan integrált intézményközi kórházi információs rendszer fejlesztése. Az integrálandó tartalmak és technológiai protokollok meghatározása, kifejlesztése. Országosan egységes központi szoftverkomponensek fejlesztése. A rendszerkövetelmények és audit anyag kapcsolódása a konstrukcióhoz: A projektből származtatott követelmények: Központi projekt felé szabott követelmények: A létrehozni kívánt Országos Egészségügyi Core-SaaS központ megvalósíthatósági tanulmányába, illetve később a projekt közbeszerzési dokumentációjának műszaki mellékletében a szolgáltatásportfólióba (annak leírásába) beemelni javasoljuk a jelen anyag 4.3 Intézményi működést támogató rendszerek részben meghatározott megoldásokat, az ott felsorolt követelmények szerint. Vagyis valamennyi 4.3 részben felsorolt alkalmazást a központnak javasolt lenne tudnia szolgáltatni az egészségügyi intézményeknek SaaS módon. Ezenkívül a szolgáltatásportfólióban a központi erecept és háziorvosi rendszereket a részben meghatározott releváns alapspecifikumok alapján javasoljuk megjeleníteni. Összeállította a GYEMSZI szakértői munkacsoportja 12

17 Szintén szükségesnek tartjuk a központ megvalósíthatósági tanulmányának működtetéssel kapcsolatos részeiben az 4.5. Üzemeltetési követelmények maximálisan érvényesüljenek. A rendszerkövetelmények és audit anyag Az alapellátás specifikumai és a A szakellátás specifikumai részekben javasolt kitérni az intézményen belüli betegazonosítással kapcsolatos informatikai (hardver, szoftver) követelményekre, úgy, hogy azok felhasználásra tudjanak kerülni a TIOP projekt megvalósíthatósági tanulmányának vonatkozó részeiben, illetve később a projekt közbeszerzési dokumentációjának műszaki mellékletében. Célszerűnek tartanánk, hogy a megvalósuló projekt szakmai monitoringja (pl. helyszíni ellenőrzése) során az azt végző TÁMOP-TIOP Közreműködő szervezet (KSZ), vagyis az ESZA Nonprofit Kft. munkatársai részéről számon legyenek kérve a projektgazdától a fenti részekben leírt követelmények. Lokális rendszerek felé szabott követelmény: Valamennyi releváns egészségügyi intézményi informatikai rendszernél számon kérni javasoljuk (amennyiben majd az létrejön és működik) a TIOP központhoz, az azok által szolgáltatásokhoz, komponensekhez való csatlakozás képességét. Tekintettel arra, hogy a TIOP projektben fog létrejönni a funkcionális integrációkat kiszolgáló egységes és központi kapcsoló-adatbázis ( integrációs motor ) a 4.4 Intézményközi rendszerszolgáltatások általános és specifikus követelményei részben fel kell tüntetni a megfelelő interfész kialakításának képességét az Országos Egészségügyi Core-SaaS központ, és azok szolgáltatott megoldásai (különösen a háziorvosi és e-recept rendszer) felé (amikor az létrejön és működik). Amennyiben lesz TIOP nek közép magyarországi régiós (KMR) tükörkonstrukciója annál is értelemszerűen ugyanúgy javasoljuk az anyag illesztését. A TIOP KMR-es tükörprojekt indítása, finanszírozásának előteremtése az EU-s források felhasználásának szabályai, a szükséges arányosítás miatt gyakorlatilag elkerülhetetlen, bár egyelőre a Közép Magyarországi Operatív Program (KMOP) as Akciótervében nincs ilyen intézkedés EKOP 2.3. Egészségbiztosítási ügyfélkapcsolatok fejlesztése, egészségügyi rendszerekbe integrált adatkezelés és azonosítás megvalósítása Konstrukció forráskerete: millió Ft Eljárásrend: kiemelt projekt Kedvezményezett: KIFÜ/ OEP A projektben valós ügyfélkapcsolati rendszer (CRM) kialakítása történik meg, elsősorban a szolgáltatók, mint ügyfelek felé biztosítva a hatékony kapcsolattartást, ügyintézést, az alapvető nyilvántartások szolgáltató képes alapnyilvántartássá szervezését. A projekt lehetővé teszi az ellátások finanszírozásának jobb megalapozását, pontosabb követését. Ennek része a még mindig létező floppys adatszolgáltatások helyett valódi monitoringot lehetővé tevő rendszer kialakítása, támaszkodva az e-kézbesítési szolgáltatására, felhasználva a (részben megújuló) űrlapos jelentési megoldásokat, de lehetővé téve a gépi adatszolgáltatást az auditált egészségügyi rendszerek számára. Összeállította a GYEMSZI szakértői munkacsoportja 13

18 A projekt része egy új szolgáltatói információs rendszer kialakítása, továbbá célja az egészségügyi reform alapkövének számító Nemzeti Egészségügyi Informatikai (ehealth) rendszerhez, a TIOP és TIOP konstrukciók által támogatott egészségügyi (intézményi és intézmények közötti) informatikai fejlesztésekhez alapvető fontosságú adatkezelési és azonosítási rendszer megvalósítása, mely magában foglalja a személyes egészségügyi azonosító, Nemzeti Egységes Kártyarendszerben létrehozott szabványokon alapuló megoldásának létrehozását, az ehhez szükséges infrastruktúra kiépítését (egészen az egészségügyi intézményi végponti elfogadóhelyekig), az e-taj funkcionalitásra vonatkozó alkalmazás- és addicionális komponensek kifejlesztését, a fenntartó szervezet működési folyamatainak újjászervezését mind a központi elszámoló intézményeknél, mind az országos szolgáltató egységeknél. A projekt fő céljai röviden: 1. Nyilvántartások korszerűsítése 2. Ügyfélkapcsolati rendszert kialakítása 3. Elszámolási rendszerek korszerűsítése 4. e-taj rendszerhez kapcsolódó infrastrukturális fejlesztések 5. e-taj funkcionalitásra vonatkozó alkalmazás- és addicionális komponensek kifejlesztése A rendszerkövetelmények és audit anyag kapcsolódása a konstrukcióhoz: A projektből származtatott követelmények: Központi projekt felé szabott követelmények: A rendszerkövetelmények és audit anyag Az alapellátás specifikumai és a A szakellátás specifikumai részekben javasolt kitérni a betegazonosítással kapcsolatos informatikai (hardver, szoftver) követelményekre, úgy, hogy azok felhasználásra tudjanak kerülni az EKOP projekt megvalósíthatósági tanulmányának vonatkozó részeiben, illetve később a projekt közbeszerzési dokumentációjának műszaki mellékletében. Az OEP részprojekttel kapcsolatban nem rendelkezünk bővebb információkkal, ezért annak rendszerkövetelmények és audit anyaghoz való kapcsolódására nem tudunk még kitérni TIOP Nemzeti Egészségügyi Informatikai (ehealth) Rendszer - Térségi, funkcionálisan integrált intézményközi információs rendszerek kiépítése Konstrukció forráskerete: 3,2 milliárd Ft Eljárásrend: kiemelt projekt Kedvezményezett: GYEMSZI A projekt célja az ágazaton belüli horizontális (a betegellátás folyamatát, illetve a beteg rendszeren belüli mozgását követő) adatáramlás biztosítása, az egészségügy szolgáltatók informatikai rendszerei közötti szemantikai interoperabilitás megteremtése melyek révén erősebbé válhat az intézmények közötti kooperáció. A projekt kizárólag regionális illetve lokális fejlesztéseket tartalmaz. Összeállította a GYEMSZI szakértői munkacsoportja 14

19 Főbb elemek: Regionálisan integrált intézményközi kórházi információs rendszerek lokális hardver és szoftver fejlesztése Az integrálandó tartalmak és technológiai protokollok meghatározása, kifejlesztése Interfészek és üzenettípusok fejlesztése vonatkozó sztenderdek alapján Regionális telemedicina szolgáltatások infrastruktúrájának kiépítése a funkcionálisan integrált intézményi rendszerekhez kapcsolódóan A betegek önrendelkezési jogait támogató informatikai megoldások fejlesztése A rendszerkövetelmények és audit anyag kapcsolódása a konstrukcióhoz: A projektből származtatott követelmények: Központi projekt felé szabott követelmények: Javasoljuk, hogy a projekt megvalósíthatósági tanulmányában, illetve később a projekt közbeszerzési dokumentációjának műszaki mellékletében felhasználásra vagy közvetlen beillesztésre kerüljenek az anyag 4.1 Az informatikai infrastruktúra architekturális követelmények, a 4.4 Intézményközi rendszerszolgáltatások általános és specifikus követelményei, az 4.5 Üzemeltetési követelmények szolgáltatásmenedzsment kérdések és a mellékletben szereplő 8.4 Telemedicina alkalmazásának helyzete Magyarországon, a telemedicina rendszerkövetelményei fejezetek részeinek releváns elemei. Célszerűnek tartanánk, hogy a megvalósuló projekt szakmai monitoringja (pl. helyszíni ellenőrzése) során az azt végző TÁMOP-TIOP Közreműködő szervezet (KSZ), vagyis az ESZA Nonprofit Kft. munkatársai részéről számon legyenek kérve a projektgazdától, illetve a fejlesztési támogatásban részesülő intézményeknél mind a négy részben leírt követelmények. Amennyiben lesz TIOP nek közép magyarországi régiós (KMR) tükörkonstrukciója annál is értelemszerűen ugyanúgy javasoljuk az anyag illesztését. A TIOP KMR-es tükörprojekt indítása, finanszírozásának előteremtése az EU-s források felhasználásának szabályai, a szükséges arányosítás miatt gyakorlatilag elkerülhetetlen, bár egyelőre a Közép Magyarországi Operatív Program (KMOP) as Akciótervében nincs ilyen intézkedés TÁMOP Nemzeti Egészségügyi Informatikai (ehealth) Rendszer bevezetésének támogatása módszertan - és képzésfejlesztés Konstrukció forráskerete: 1 milliárd Ft Eljárásrend: kiemelt projekt Kedvezményezett: GYEMSZI A projekt célja az egyedileg azonosított betegadatok ágazati feldolgozási folyamatainak (beleértve az egyedi ellátási eseteket leíró kódolási folyamatokat, az elszámolási rendszereket és technikákat) korszerűsítése, az emberi erőforrás fejlesztése. A projekt főbb elemei: módszertani koherencia biztosítása, a szükséges (tovább-) képzések (egészségügyi dolgozók képességfejlesztése) lebonyolítása az egyetemek közreműködésével, az intézményeknél újonnan bevezetett infokommunikációs rendszerek használatának betanítása. Összeállította a GYEMSZI szakértői munkacsoportja 15

20 A rendszerkövetelmények és audit anyag kapcsolódása a konstrukcióhoz: A projektből származtatott követelmények: Központi projekt felé szabott követelmények: Javasoljuk, hogy a TÁMOP projekt scope-ja terjedjen ki valamennyi rendszerkövetelmények és audit anyag Az alapellátás specifikumai, A szakellátás specifikumai és 4.3 Intézményi működéstámogató rendszerek fejezeteiben feltüntetett megoldásokkal kapcsolatos felhasználói képzésre, betanításra. A projekt megvalósíthatósági tanulmányának kidolgozásában célszerűnek tartanánk felhasználni az 5.1 Az intézmény felkészültségének követelményei részben leírtakat. Ezenkívül a kormányzati infokommunikációs konszolidációs intézkedési terv közigazgatási humánerőforrás fejlesztése intézkedésében (lásd fejezet) leírtakkal való összhang megteremtése érdekében javasoljuk, hogy a projekt térjen ki a módszertan és tananyagfejlesztéseken és az ellátórendszeri felhasználók informatikai jellegű képzésén túl az egészségügyi informatikai szakemberállomány fejlesztésére, képzésére, életpálya modelljük kidolgozására is (akár az előirányzott 1 milliárd Ft forrás nagyságának újragondolásával). 3.2 A Semmelweis-Terv egyéb fejlesztéspolitikai konstrukcióihoz (pályázataihoz) való viszony Az előző részben felsorolt központi projektekhez való illesztésen túl javasoljuk, hogy az elkészülő anyagot használják fel a TIOP és Regionális Operatív Programok (ROP-ok) as olyan egészségügyi konstrukcióihoz is a kiírások mellékleteként, illetve a közbeszerzések műszaki dokumentációjánál, ahol az intézmények számára támogathatók infokommunikációs fejlesztések a projektekben. Kívánatosnak tartanánk, hogy a rendszerkövetelmények és audit anyag releváns részeit az egyes infokommunikációs fejlesztéseket is támogató pályázatok, azok közbeszerzési dokumentációinak mellékleteként a Nemzeti Fejlesztési Ügynökség deklarálja, valamint a TÁMOP-TIOP Közreműködő szervezet (KSZ), vagyis az ESZA Nonprofit Kft., illetve a ROP KSZ VÁTI Nonprofit Kft. munkatársai vegyék figyelembe és kérjék számon mind az intézményi projektek értékelésekor, mind azok (helyszíni) szakmai monitoringja során. Az egyes konstrukciók és az anyag javasolt kapcsolódását (illesztését, felhasználását) a következő táblázatban mutatjuk be: Vonatkozó TIOP- ROP konstrukciók Rendszerkövetelmények anyag releváns részei az uniós forrás felhasználás különböző szakaszaiban Pályázati melléklet, Értékelés Közbeszerzési melléklet Monitoring TIOP Regionális járóbeteg 4.1; 4.2.2; 4.1; 4.2.2; 4.2.4; 4.1; 4.2.2; Összeállította a GYEMSZI szakértői munkacsoportja 16

21 Vonatkozó TIOP- ROP konstrukciók Rendszerkövetelmények anyag releváns részei az uniós forrás felhasználás különböző szakaszaiban Pályázati melléklet, Értékelés Közbeszerzési melléklet Monitoring szakellátó intézmények fejlesztése 4.2.4; ; ; 4.2.5; 4.5 TIOP Aktív kórházi ellátásokat kiváltó járóbeteg szolgáltatások fejlesztése 4.1; 4.2.2; 4.2.4; ; 4.2.2; 4.2.4; 4.2.5; ; 4.2.2; 4.2.4; 4.2.5; 4.5 TIOP Sürgősségi ellátás fejlesztése (SO1 és SO2) 4.1; 4.2.2; 4.2.4; ; 4.2.2; 4.2.4; 4.2.5; ; 4.2.2; 4.2.4; 4.2.5; 4.5 TIOP Struktúraváltoztatást támogató infrastruktúra-fejlesztés a fekvőbeteg-szakellátásban 4.1; 4.2.2; 4.2.4; ; 4.2.2; 4.2.4; 4.2.5; ; 4.2.2; 4.2.4; 4.2.5; 4.5 TIOP Korszerű regionális onkológiai hálózat kialakítása és fejlesztése 4.1; 4.2.2; 4.2.4; ; 4.2.2; 4.2.4; 4.2.5; ; 4.2.2, 4.2.4; 4.2.5; 4.5 DAOP Alap és járóbeteg ellátás fejlesztése 4.1;4.2.1; 4.2.2; 4.2.4; ; 4.2.1; 4.2.2; 4.2.4; 4.2.5; ; 4.2.1; 4.2.2; 4.5 DAOP Rehabilitációs és hosszú idejű ápolási ellátás fejlesztése 4.1; ; 4.2.2; 4.2.4; 4.2.5; ; 4.2.2; 4.2.4; 4.2.5; 4.5 DDOP Egészségügyi és szociális ellátás fejlesztése 4.1; 4.2.2; 4.2.4; , 4.2.2; 4.2.4; 4.2.5; ; 4.2.2; 4.2.4; 4.2.5; 4.5 ÉAOP Egészségügyi intézmények fejlesztése 4.1, 4.2.1; 4.2.2; 4.2.4; ; 4.2.1, 4.2.2; 4.2.4; 4.2.5; ; 4.2.1; 4.2.2; 4.2.4; 4.2.5; 4.5 ÉMOP Egészségügyi alapellátás fejlesztése 4.1; 4.2.1; ; 4.2.1; 4.2.2; 4.2.4; 4.2.5; ; 4.2.1; 4.2.2; 4.2.4; 4.2.5; 4.5 ÉMOP Rehabilitációs és hosszú idejű ellátás fejlesztése 4.1; 4.2.1; 4.2.2; 4.2.4; ; 4.2.1, 4.2.2; 4.2.4; 4.2.5; ; 4.2.1, 4.2.2, 4.2.4; 4.2.5; 4.5 Összeállította a GYEMSZI szakértői munkacsoportja 17

22 Vonatkozó TIOP- ROP konstrukciók Rendszerkövetelmények anyag releváns részei az uniós forrás felhasználás különböző szakaszaiban Pályázati melléklet, Értékelés Közbeszerzési melléklet Monitoring KDOP Az egészségügyi ellátórendszer fejlesztése, hatékonyságának növelése 4.1; 4.2.1, 4.2.2; 4.2.4; ; 4.2.1; 4.2.2; 4.2.4; 4.2.5; ; 4.2.1; 4.2.2; 4.2.4; 4.2.5; 4.5 NYDOP Egészségügyi szolgáltatások fejlesztése 4.1; 4.2.1; ; 4.2.4; ; 4.2.1; 4.2.2; 4.2.4; 4.2.5; ; 4.2.1; 4.2.2; 4.2.4; 4.2.5; 4.5 Megjegyezzük, hogy a táblázatban felsorolt konstrukcióknál a es időszakban, illetve a jelenleg is futó pályázati kiírásoknál megtalálható (volt) Infokommunikációs minimumkövetelmények segédlet. Ezeket megvizsgálva javasolnánk azok teljes frissítését, illetve újragondolását a rendszerkövetelmények és audit anyag által leírtak alapján. Összeállította a GYEMSZI szakértői munkacsoportja 18

23 4 Az informatikai rendszerek követelményei 4.1 Az informatikai infrastruktúra architektúrális követelményei Bevezetés Cél, hogy a követelményrendszer bekerüljön az ágazat akkreditálandó területei közé és az alábbi területekre hatással legyen: 1. Az ágazati adat-áramlás és intézményközi interoperabilitás 2. Üzemeltetési sztenderdek, szolgáltatási színvonal és szintek egységesedése, a színvonal emelkedése. 3. Az ágazat stratégiai fejlesztési projektjeivel való összhang biztosítása informatikai képességek szintjén. 4. Ágazati szereplők (intézmények, kórházak, stb.) közpénzzel támogatott informatikai fejlesztéseinek kötelező tartalmi elemei 5. Ágazati szoftver / informatikai rendszer akkreditáció bírálati szempontjai 6. Informatikai beruházások költségeinek jelentős csökkentése az ágazatban és ágazaton kívül informatikai szállítótól való függőség csökkentése Az alábbi fejezetekben rögzített bármely követelménytől egy konkrét rendszer illetve annak megvalósítása eltérhet akkor, ha olyan alternatív megoldással helyettesítik, amely az adott környezetben legalább olyan gazdaságos, és a rendszer külső kapcsolatait nem befolyásolja Jogi formában rögzítendő ajánlások az egészségügyi informatikai rendszerek védelme érdekében 1. Az egészségügyi ellátó intézménynek ki kell alakítania az egészségügyi tevékenységének ellátásához használt informatikai rendszer biztonságával kapcsolatos szabályozási rendszerét és gondoskodnia kell az informatikai rendszer kockázatokkal arányos védelméről. 2. A szabályozási rendben ki kell térni az információtechnológiával szemben támasztott követelményekre, a használatából adódó biztonsági kockázatok felmérésére és kezelésére a tervezés, a beszerzés, az üzemeltetés és az ellenőrzés területén. 3. Az egészségügyi intézmény köteles az informatikai rendszer biztonsági kockázatelemzését szükség szerint, de legalább kétévente felülvizsgálni és aktualizálni. 4. Az informatika alkalmazásából fakadó biztonsági kockázatok figyelembevételével meg kell határozni a szervezeti és működési rendeket, a felelősségi, nyilvántartási és tájékoztatási szabályokat, a folyamatba épített ellenőrzési követelményeket és szabályokat. 5. Az egészségügyi intézménynek ki kell dolgoznia az informatikai rendszerének biztonságos működtetését felügyelő informatikai ellenőrző rendszert és azt folyamatosan működtetnie kell. 6. A biztonsági kockázatelemzés eredményének értékelése alapján a biztonsági kockázattal arányos módon gondoskodni kell legalább az alábbiakról: a) a rendszer legfontosabb elemeinek (eszközök, folyamatok, személyek) egyértelmű és visszakereshető azonosításáról, Összeállította a GYEMSZI szakértői munkacsoportja 19

24 b) az informatikai biztonsági rendszer önvédelmét, kritikus elemei védelmének zártságát és teljes körűségét biztosító ellenőrzésekről, eljárásokról, c) a rendszer szabályozott, ellenőrizhető és rendszeresen ellenőrzött felhasználói adminisztrációjáról (hozzáférési szintek, egyedi jogosultságok, engedélyezésük, felelősségi körök, hozzáférés naplózás, rendkívüli események), d) olyan biztonsági környezetről, amely az informatikai rendszer működése szempontjából kritikus folyamatok eseményeit naplózza és alkalmas e naplózás rendszeres (esetleg önműködő) és érdemi értékelésére, illetve lehetőséget nyújt a nem rendszeres események kezelésére, e) a távadatátvitel bizalmasságáról, sértetlenségéről és hitelességéről, f) az adathordozók szabályozott és biztonságos kezeléséről, g) a rendszer biztonsági kockázattal arányos vírusvédelméről. 7. Az egészségügyi intézménynek tevékenysége ellátásához, nyilvántartásai naprakész és biztonságos vezetéséhez meg kell valósítania a biztonsági kockázatelemzés alapján indokolt védelmi intézkedéseket és rendelkeznie kell legalább a következőkkel: a) informatikai rendszerének működtetésére vonatkozó utasításokkal és előírásokkal, valamint a fejlesztésre vonatkozó tervekkel, b) minden olyan dokumentációval, amely az egészségügyi ellátási tevékenységet közvetlenül vagy közvetve támogató informatikai rendszerek folyamatos és biztonságos működését - még a szállító, illetőleg a rendszerfejlesztő tevékenységének megszűnése után is - biztosítja, c) az egészségügyi szolgáltatások ellátásához szükséges informatikai rendszerrel, valamint a szolgáltatások folytonosságát biztosító tartalék berendezésekkel, illetve e berendezések hiányában az ezeket helyettesítő egyéb - a tevékenységek, illetve szolgáltatások folytonosságát biztosító - megoldásokkal, d) olyan informatikai rendszerrel, amely lehetővé teszi az alkalmazási környezet biztonságos elkülönítését a fejlesztési és tesztelési környezettől, valamint a megfelelő változáskövetés és változáskezelés fenntartását, e) az informatikai rendszer szoftver elemeiről (alkalmazások, adatok, operációs rendszer és környezetük) olyan biztonsági mentésekkel és mentési renddel (mentések típusa, módja, visszatöltési és helyreállítási tesztek, eljárási rend), amelyek az adott rendszer helyreállíthatóságát a rendszer által nyújtott szolgáltatás kritikus helyreállítási idején belül lehetővé teszik. Ezen mentéseket kockázati szempontból elkülönítetten és tűzbiztos módon kell tárolni, valamint gondoskodni kell a mentések forrásrendszerrel azonos szintű hozzáférés védelméről, f) jogszabályban meghatározott nyilvántartás ismételt előhívására alkalmas adattároló rendszerrel, amely biztosítja, hogy az archivált anyagokat a jogszabályokban meghatározott ideig, bármikor visszakereshetően, helyreállíthatóan megőrizzék, g) a szolgáltatásai folyamatosságát akadályozó rendkívüli események kezelésére szolgáló tervvel. 8. Az egészségügyi intézménynél mindenkor rendelkezésre kell állnia: a) az informatikai rendszer felépítésének és működtetésének az ellenőrzéséhez szükséges rendszerleírásoknak és modelleknek, Összeállította a GYEMSZI szakértői munkacsoportja 20

25 b) az informatikai rendszernél az adatok szintaktikai szabályainak, az adatok tárolási szerkezetének, c) az informatikai rendszer elemeinek az egészségügyi előírások által meghatározott biztonsági osztályokba sorolási rendszerének, d) az adatokhoz történő hozzáférési rend meghatározásának, e) az adatgazda és a rendszergazda kijelölését tartalmazó iratnak, f) az alkalmazott szoftver eszközök jogtisztaságát bizonyító szerződéseknek, g) az informatikai rendszert alkotó ügyviteli, eglszségügyi szoftvereszközök teljes körű és naprakész nyilvántartásának. 9. A szoftvereknek együttesen alkalmasnak kell lenni legalább: a) a működéshez szükséges és jogszabályban előírt adatok nyilvántartására, b) az egészségügyi adatok és az egészségügyi dokumentumok biztonságos nyilvántartására, c) az egészségügyi intézmény tevékenységével összefüggő informatikai rendszerekhez történő közvetlen vagy közvetett csatlakozásra, d) a tárolt adatok ellenőrzéséhez való felhasználására, e) a biztonsági kockázattal arányos logikai védelemre és a sérthetetlenség védelmére. Az egészségügyi intézménynek belső szabályzatában meg kell határoznia az egyes munkakörök betöltéséhez szükséges informatikai végzettséget és ismereteket Általános architekturális követelmények Az informatikai rendszereknek hardver és szoftver komponensek tekintetében, valamint architekturálisan meg kell felelni a fejlesztéskor elvárható szakmai színvonalnak. Gazdaságossági és fenntarthatósági, valamint interoperabilitás szempontból elvárás a SOA 4 típusú megoldások alkalmazása. A megfelelő fejlesztési technológia kiválasztásával időtálló 5, fenntartható rendszereket A kell fejleszteni. Robosztus architektúra: Az alkalmazások architektúráját úgy kell megtervezni és megvalósítani, hogy az képes legyen a megcélzott (ágazati vagy intézeti) számú A felhasználó biztonságos és gyors kiszolgálására. (Az elvárt gyorsaság megítélésénél az adott funkciók specifikációjánál megadott érték az irányadó). A megfelelőséget számítással kell alátámasztani és teszteléssel ellenőrizni. Architektúra 6 : a megvalósításra kerülő alkalmazás kettő (kliens- szerver), vagy több A rétegű (multi-tiered) architektúrára 7 épüljön. Méretezhetőség: Az alkalmazások architektúrájának (hardver és szoftver) biztosítania kell az intézmény vagy régióhoz tartozó teljes intézményrendszernek, mint felhasználó A számhoz szükséges méretre való felbővítés lehetőségét. A megfelelőséget számítással kell alátámasztani. 4 SOA (Service Oriented Architecture), magyar terminológiával Szolgáltatás Alapú Architektúra. A SOA nyílt, szabványos komponens technológia, amelynek építőelemei a szolgáltatások. A szolgáltatások önállóan is működőképesek legyenek, platform és eszközfüggetlenek (tetszőleges technológiával készülhetnek), szabványos, jól definiált interfésszel rendelkezzenek, és szabványos adatcsere és kommunikációs protokollokkal legyenek érhetők el az elosztott hálózatokban. 5 Az időtállóságnál figyelembe kell venni a évi XLVII. Törvény ben foglalt adatmegőrzési időtartamokat. Nyilatkozat és megvalósítási leírás szükséges az időtállóság megvalósításáról. 6 Az architekturális elvárások az ajánlásgyűjtemény készítésének időszakában elvárható és ajánlott architektúrát definiálják. Terveink szerint ez és egyéb műszaki paraméterek a technológiai fejlődésnek megfelelően folyamatosan frissítésre kerülnek. 7 Pl. three tier architektúra kliensl, alkalmazás szerver (application server), adatbázis szerver (database server) Összeállította a GYEMSZI szakértői munkacsoportja 21

26 A A A A A A A A A A A A A A A Hibatűrő, redundáns kialakítás: Mind egyedi eszköz telepítése esetén, mind szolgáltató központoknál olyan mértékben szükséges hibatűrő, redundáns infrastruktúrát kialakítani, amely összhangban áll a vállalt szolgáltatási szint (kiemelten a rendelkezésre állás) paraméterekkel. A megfelelőséget számítással kell alátámasztani. Ki kell alakítani a feladatátvételi topológiát 8. Meg kell határozni, hogy mely eszközök szolgálnak egymás tartalékaiként, illetve az egyes tagok milyen szerepet (aktív kiszolgálói, tartalék) játszanak. A hardveres redundancia mellett az alkalmazás-szoftveres redundáns megvalósítása a rendelkezésre állás érdekében indokolt. A hálózati szempontból redundáns kapcsolatot kell biztosítani a kliensekkel. Integrált működés: Biztosítani kell, hogy az alkalmazások egymással, és a működés szempontjából elengedhetetlenül fontos államigazgatás, finanszírozás, stb. kapcsolódó rendszereivel integráltan működjenek. Az integrált működéshez az alkalmazásoknak a szabályozott módon szabványos, dokumentált interfész felületekkel kell rendelkeznie. Ezért elvárás o A kommunikációs interfész megfelelőségéhez szükséges a kommunikáció logikai modelljének kidolgozása. o A kommunikációs üzenetek részletes belső felépítésének dokumentálása és az üzenetek részletes (minden üzenettípusra kiterjedő) használati esetdiagramjának (use case diagram) megadása. o A központilag definiált üzenet minták magyarázattal ellátott megvalósítása elengedhetetlen o A rendszert fel kell készíteni a felhasználó által definiált szabványos üzenet minták önálló előállítására o A megvalósított interfészt dokumentáltan, előre mutató módon fel kell készíteni a keretrendszer kapcsán várható jövőbeli kapcsolatok egyszerű lehetőleg paraméterezéssel történő kialakítására. o A kialakított szoftver architektúra vonatkozásában a működéssel kapcsolatos e- Közigazgatási Keretrendszerek 9 elvárásai az irányadók. Az informatikai szállító mutassa be, hogy a tervezés során mely elvárások lettek a rendszer kialakításánál figyelembe véve. Felhasználói interfész: Az alkalmazások felhasználói interfészét az egyes alkalmazások esetében úgy kell kialakítani, hogy azok biztosítsák az alkalmazás képernyők, oldalak elvárható sebességű, elérhetőségét az általánosan elterjedt, kereskedelmi forgalomban rendelkezésre álló hálózati kapcsolatokon keresztül 10. A hivatalos iratok elektronikus kézbesítése és az elektronikus tértivevénnyel kapcsolatban a évi LII. tv. Követelményei az irányadóak. A tükrözés 11 vagy a megfelelő szintű RAID 12 biztonsági szintű konfiguráció alkalmazása a betegadatokat tartalmazó alrendszerek esetében kötelező. A hardvereszközök méretezésénél az általános lekérdező modult használók teljesítményigényével is kalkulálni kell Pl: feladatátvételi pár topológia, forró tartalék, feladatátvételi gyűrű, stb Az elvárt válaszidőket alkalmazás típusonként, funkciónként egyedileg kell specifikálni. 11 Operációs rendszer és a felhasználói szoftverek számára minimálisan elvárt a 2db HDD ből kialakított RAID 1 (tükrözés) tömb 12 Betegadatok tárolása esetén minimálisan elvárt a minimum 4 db HDD ből álló RAID 5 tömb kialakítása. Javasolt a minimum 5 db HDD ből kialakított RAID 6 tömb kialakítása mivel így kétszeres meghajtó meghibásodás is kiküszöbölhetővé válik. Összeállította a GYEMSZI szakértői munkacsoportja 22

27 4.1.4 Infrastruktúrális követelmények A környezeti hibaforrásokat minimálisra kell csökkenteni. Az alkalmazásokat futtató A hardver környezetet minimálisan a következő paraméterekkel rendelkező gépteremben 14 kell elhelyezni ahol biztosított: A o a gépek hőtermelésének megfelelő 15 légkondicionálás; A o az eszközök illetéktelen személyek általi hozzáférése elleni védelme; A o az előírásoknak megfelelő tűzvédelmi infrastruktúra; A o a szolgáltatást igénybe vevő, felhasználók számának, és a használt alkalmazásoknak megfelelő 16 sávszélességű hálózati 17 csatlakozás; A o az alkalmazások által kezelt adatok üzemszerű 18 működéséhez szükséges háttértároló eszköz és szoftver; A o az alkalmazások által kezelt adatok rendszeres mentéséhez szükséges mentési eszköz és mentő szoftver; A o az alkalmazások által kezelt adatok rendszeres archiválásához 19 szükséges eszköz, archiváló szoftver, kellő számú licence és tároló kapacitás; A o a gépek teljesítmény felvételének megfelelő, szünetmentes áramellátást biztosító rendszer 20 ; o A szerver számítógépek és a szünetmentes áramforrásoknak A rendelkezniük kell távmenedzsment 21 kommunikáció funkcionalitással az szállított és megmaradó eszközpark operációs rendszer platformok mindegyikére (pl. Win, Linux, ) A A A A A o o A beüzemelt szerver(ekre) telepíteni kell a szünetmentes áramforráshoz szükséges kommunikációs szoftvert a szabályos leállítási és riasztási (értesítési) folyamat megvalósítása érdekében. Javasolt a szolgáltatói rendszerek hardver, szoftver, és hálózati elemeinek monitorozását és távfelügyeletét biztosítani képes felügyeleti rendszer, o melynek segítségével a vállalt szolgáltatási színvonalnak megfelelő távfelügyeleti feladatok elvégezhetősége biztosított o melynek segítségével a vállalt SLA szintek 22 folyamatosan mérhetők és dokumentálhatók o melynek segítségével lehetőség van riasztási értékek és szintek beállítására, valamint a riasztások többféle eszközön történő egyidejű elküldésére 13 A hardver eszközöket úgy kell méretezni, hogy lekérdező modult csúcsidőben történő használata ne okozzon válaszidő növekedést. 14 Mind lokális mind hosting megvalósítás esetében elvárás 15 A gépek hőtermelését a pontos hardver konfigurációt figyelembe véve számítással kell dokumentálni. 16 A sávszélesség megfelelősségét számítással kell dokumentálni. 17 Pl: internet, bérelt vonali, mobil, stb. 18 Az üzemszerű működés feltételeit írásban definiálni kell 19 Az archiváló eszköz típusát és az előírásoknak megfelelő garantált adatmegőrzési időtartamot gyártói garanciákkal kell alátámasztani. 20 A szünetmentes áramellátást minimálisan az átlagos terhelés 130% ra kell méretezni. A méretezés során az elvárt áthidalási időt is figyelembe kell venni a számítások során. A szünetmentes ellátás méretezését számítással kell dokumentálni. 21 pl. SNMP (Simple Network Management Protocol) 22 Az SLA az angol Service Level Agreement kifejezés rövidítése, ami magyarul szolgáltatási szint szerződést jelent. Az SLAban kerülnek meghatározásra az megvalósított szolgáltatások kritikus és mérhető pontjai. A legfontosabb SLA értékekkel foglalkozunk részletesen. Összeállította a GYEMSZI szakértői munkacsoportja 23

28 A o rendszeres hardver és szoftver önellenőrzés beállíthatósága. Hiba esetén 9-4 legyen mód a riasztások többféle eszközön történő egyidejű elküldésére Mentési, archiválási, visszatöltési követelmények Elektronikusan tárolt adataink fokozottan ki vannak téve a hardver meghibásodások veszélyének. A meghibásodás esetén bekövetkező kár csökkenthető, illetve a rendelkezésre állás növelhető, ha a rendszeren ütemezetten biztonsági mentéseket végzünk. A biztonsági mentés nem egyezik meg az archiválással, amelynek feladata eredendően nem a biztonság növelése, hanem egy korábbi állapot eltárolása. Biztosítani kell az adatok és rendszerek időszakos napi, heti, havi, éves mentését a A vállalt szolgáltatási szinthez illeszkedő mentési rend alapján 23. A mentő és archiváló rendszerek tegyék lehetővé az operációs rendszer és a szoftver A környezet és a beállított rendszerparaméterek mentését is 24. Ezen mentéseket kockázati szempontból elkülönítetten és tűzbiztos módon kell tárolni, A valamint gondoskodni kell a mentések forrásrendszerrel azonos szintű hozzáférés védelméről. A mentő és archiváló rendszerek biztosítsák a mentett adatok és a rendszerparaméterek A hibamentes, konzisztens visszaállítását. A mentő és archiváló rendszerek tegyék lehetővé az elektronikus adathordozókon tárolt adatok, állományok utólagos elérhetőségét (elolvashatóságát), használatát. Ezt a A szolgáltatást mindenkor biztosítani kell az erre szolgáló eszközök esetleges módosítása, cseréje esetén is. A megoldásszállító készítsem mentési, archiválásai és visszaállítási tervet melyben A részletesen specifikálja az eljárások kivitelezési módját. A megoldásszállító készítsen katasztrófa elhárítási tervet az üzemszerű működés és A az üzleti folyamatok helyreállítása érdekében Az egészségügyi dokumentációnak és az egészségügyi ellátás során képződött A adatoknak az adathordozón minimálisan a törvényben előírt időtartamig 26 történő megőrzését, archiválását biztosítani kell. Ideális állapot a páciens személyes életút archívumának a biztosítása. Az ütemezett mentéseket a rendszerek és az alkalmazások leállítása nélkül kell tudni A elvégezni(hideg mentés) 27. A rendszer minimálisan az alábbi mentésekre legyen felkészítve: o Full Backup 28 A o Incrementális Backup 29 ( mind a Kummulatív backup 30, mind a Differenciál backup 31 elfogadott) 23 A mentési rendet úgy kell kialakítani, hogy maximum egy napnyi adatvesztés mellett az alkalmazások működőképessége helyreállítható legyen. 24 system backup 25 EuroRec EU Lásd évi XLVII. törvény 30. (1) Az egészségügyi dokumentációt a képalkotó diagnosztikai eljárással készült felvételek, az arról készített leletek, valamint a (7) bekezdés kivételével az adatfelvételtől számított legalább 30 évig, a zárójelentést legalább 50 évig kell megőrizni. (8) Az adatmegőrzés érdekében folyamatosan biztosítani kell, hogy az adathordozó az adott technikai feltételek mellett olvasható maradjon, vagy olvasható állapotba kerüljön. 27 hideg mentés: amikor az adatbázis tartalmát befagyasztjuk a mentés idejére és a változásokat nem végzik el benne, hanem feljegyezzük a transaction log ba. A mentés befejeződését követően az el nem végzett módosításokat a rendszer végrehajtja az adatbázison, így annak fizikai tartalma rövid idő alatt utoléri az on line működést. 28 A rendszer minden adata válogatás nélkül mentésre kerül. 29 A mentés alkalmazása esetén nem kerül elmentésre minden adat, hanem csak azok, amelyek egy korábbi mentés óta megváltoztak (ekkor a visszaállításhoz természetesen több biztonsági mentésre is szükség van). Az inkrementális mentésnek két alapvető fajtája van: a kumulatív és a differenciális mentés. Ezek segítségével többféle mentési stratégia kidolgozható. Összeállította a GYEMSZI szakértői munkacsoportja 24

29 Elosztott rendszereknél az inkonzisztencia (dominó effektus) elkerülése érdekében a A biztonsági mentéseket koordináltan kell végezni az egymással kommunikáló adatbázisok esetében Biztonságos működéssel-működtetéssel kapcsolatos követelmények Az egészségügyi ellátó intézménynek ki kell alakítania az egészségügyi tevékenységének ellátásához használt informatikai rendszer biztonságával kapcsolatos szabályozási rendszerét és gondoskodnia kell az informatikai rendszer kockázatokkal arányos védelméről. A szabályozási rendben ki kell térni az információtechnológiával szemben támasztott követelményekre, a használatából adódó biztonsági kockázatok felmérésére és kezelésére a tervezés, a beszerzés, az üzemeltetés és az ellenőrzés területén. A A A A A A A A A A Az egészségügyi intézménynek tevékenysége ellátásához, nyilvántartásai naprakész és biztonságos vezetéséhez meg kell valósítania a biztonsági kockázatelemzés alapján indokolt védelmi intézkedéseket és rendelkeznie kell legalább a következőkkel: o informatikai rendszerének működtetésére vonatkozó utasításokkal és előírásokkal 32, valamint a fejlesztésre vonatkozó tervekkel, o olyan rendszergazdai, felhasználói és üzemeltetői dokumentációval, amely az egészségügyi ellátási tevékenységet közvetlenül vagy közvetve támogató informatikai rendszerek folyamatos és biztonságos működését - még a szállító, illetőleg a rendszerfejlesztő tevékenységének megszűnése után is - biztosítja 33, o az egészségügyi szolgáltatások ellátásához szükséges informatikai rendszerrel, valamint a szolgáltatások folytonosságát biztosító tartalék berendezésekkel, illetve e berendezések hiányában az ezeket helyettesítő egyéb - a tevékenységek, illetve szolgáltatások folytonosságát biztosító - megoldásokkal, o olyan informatikai rendszerrel, amely lehetővé teszi az alkalmazási környezet biztonságos elkülönítését a fejlesztési és tesztelési környezettől, valamint a megfelelő változáskövetés és változáskezelés fenntartását, o az informatikai rendszer szoftver elemeiről (alkalmazások, adatok, operációs rendszer és környezetük) olyan biztonsági mentésekkel és mentési renddel (mentések típusa, módja, visszatöltési és helyreállítási tesztek, eljárási rend), amelyek az adott rendszer helyreállíthatóságát a rendszer által nyújtott szolgáltatás kritikus helyreállítási idején belül lehetővé teszik 34, o jogszabályban meghatározott nyilvántartás ismételt előhívására alkalmas adattároló rendszerrel, amely biztosítja, hogy az archivált anyagokat a jogszabályokban meghatározott ideig, bármikor visszakereshetően, helyreállíthatóan megőrizzék, o a szolgáltatásai folyamatosságát akadályozó rendkívüli események kezelésére szolgáló tervvel. A biztonsági kockázatelemzés eredményének értékelése alapján a biztonsági kockázattal arányos módon gondoskodni kell legalább az alábbiakról: o a rendszer legfontosabb elemeinek (eszközök, folyamatok, személyek) egyértelmű és visszakereshető azonosításáról, 30 A kumulatív mentés során mindig az utolsó teljes mentés óta megváltozott adategységek kerülnek elmentésre. 30 A Differenciál mentés során mindig az utolsó teljes mentés (Full backup)óta megváltozott adategységek kerülnek elmentésre. 32 Adatvédelmi szabályzat, Biztonsági Politikák (felhasználói policy, rendszergazdai policy, fejlesztői policy, ), Felhasználó Hozzáférés Management, Távoli hozzáférés szabályzata, 33 Rendszergazdai leírások, beüzemelési, beállítási, működési és üzemeltetési paraméterek, hibaelhárítási útmutatók 34 Részletesen specifikációt lást a Mentési, archiválási, visszatöltési követelmények Összeállította a GYEMSZI szakértői munkacsoportja 25

30 A A A A A A A A A A A A A A A A A A A o az informatikai biztonsági rendszer önvédelmét, kritikus elemei védelmének zártságát és teljes körűségét biztosító ellenőrzésekről, eljárásokról, o a rendszer szabályozott, ellenőrizhető és rendszeresen ellenőrzött felhasználói adminisztrációjáról (hozzáférési szintek, egyedi jogosultságok, engedélyezésük, felelősségi körök, hozzáférés naplózás, rendkívüli események) o olyan biztonsági környezetről, amely az informatikai rendszer működése szempontjából kritikus folyamatok eseményeit naplózza és alkalmas e naplózás rendszeres (esetleg önműködő) és érdemi értékelésére, illetve lehetőséget nyújt a nem rendszeres események kezelésére, o a távadatátvitel bizalmasságáról, sértetlenségéről és hitelességéről, o az adathordozók szabályozott és biztonságos kezeléséről, o a rendszer biztonsági kockázattal arányos vírusvédelméről 35, annak rendszeres, központi frissítéséről és folyamatos menedzsmentjéről o a felhasználó munkaállomásokon használt levelező rendszer biztonsági kockázattal arányos többszintű spam és vírusvédelméről, annak rendszeres, központi frissítéséről és folyamatos menedzsmentjéről. Az egészségügyi intézménynél mindenkor rendelkezésre kell állnia: o az informatikai rendszer felépítésének és működtetésének az ellenőrzéséhez szükséges rendszerleírásoknak és modelleknek, o az informatikai rendszernél az adatok szintaktikai szabályainak, az adatok tárolási szerkezetének, o az informatikai rendszernél a tárolást adatok lekérdezési mechanizmusának, o az informatikai rendszer elemeinek az egészségügyi előírások által meghatározott biztonsági osztályokba sorolási rendszerének, o az adatokhoz történő hozzáférési rend meghatározásának, o az adatgazda és a rendszergazda kijelölését tartalmazó iratnak, o az alkalmazott szoftver eszközök jogtisztaságát és követését bizonyító szerződéseknek. A kapcsolattartáshoz szükséges adatoknak (cím, név, telefonszám, ), o az informatikai rendszert alkotó ügyviteli, egészségügyi szoftvereszközökön használt szoftverek verziókövetését naplózó és nyilvántartó dokumentációnak, illetve az ehhez kapcsolódó verzió leírásoknak és teszt jegyzőkönyveknek, o az informatikai rendszert alkotó ügyviteli, egészségügyi szoftvereszközök teljes körű és naprakész nyilvántartásának. Központi kiszolgáló szerverpark létrehozása esetén az informatikai célrendszerek együttműködéséről és a szolgáltatásaik egységes használatát biztosító feltételekről gondoskodni kell. Biztosítani kell az közszolgáltatás biztonságáról szóló 223/2009. (X. 14.) Korm. rendeletben foglalt elvárások teljesülését 36, azaz: o az informatikai célrendszer tervezésére, a célrendszer elemeinek beszerzésére, valamint a célrendszer előállítására (különösen fejlesztésére, testre szabására, paraméterezésére, telepítésére) és felülvizsgálatára kiterjedő, a rendeletben meghatározott feltételeknek megfelelő minőségirányítással kell alátámasztania 35 A vírusvédelmet mind szerver mind kliens oldalon biztosítani kell. Külön figyelmet kell fordítani a vékonykliensek vírusvédelmére is. 36 A kormányrendeletben foglalt elvárások teljesítéshez nyújt segítséget és megfelelő megoldásokat a Közigazgatási Informatikai Bizottság (KIB) 25. számú ajánlása Összeállította a GYEMSZI szakértői munkacsoportja 26

31 az eljárási és biztonsági követelmények teljesülését; o megfelelő biztonsági követelmények teljesítéséhez szükséges folyamatok és A eljárások kidolgozását és bevezetését. Ügyfél azonosításával kapcsolatos eljárás esetén olyan biztonsági követelményeknek A megfelelő elektronikus űrlapot kell az ügyfél rendelkezésére bocsátani, amelynek elektronikus aláírásával az ügyfél azonosításra kerül. Ügyfél azonosításával kapcsolatosan aláírandó elektronikus űrlapot olyan egyedi űrlap A azonosítóval (sorszámmal, időjelzéssel stb.) kell ellátni, amely kizárja az elektronikus aláírással ellátott űrlap ismételt felhasználását. Távoli elérés esetén szavatolni kell a hálózat és az azon működő hardver eszközök, alkalmazások védelmét másrészt pedig magának a kommunikációnak a biztonságosságát. Az intézeti IT biztonsági szabályzatban részletes leírást kell arról készíteni, hogy hogyan biztosítható (milyen biztonsági protokollal, milyen biztonsági A beállításokkal, hardver vagy szoftver kulccsal, több szintű autentikációval) a hálózat az alkalmazások és a kommunikáció biztonsága. A szabályzat kialakításában a IT biztonság kialakításáért és üzemeltetéséért felelős szervezetnek és az alkalmazás fejlesztőjének is részt kell vennie. Ha a rendszerben intelligens kártya, vagy token segítségével lehet autentikálni, akkor a A kártya és kulcsmenedzsment a biztonsági szabályzattal összhangban, a korszerű kriptográfia eszközök segítségével kell, hogy történjék. A A rendszer tegye lehetővé a biztonsági funkciók auditja során a rögzített és tárolt audit logok megtekintését, elemzését. A rendszer logolja és jelezze a biztonságot veszélyeztető eseményeket tegye lehetővé a A biztonsági funkciók auditja során a rögzített és tárolt audit logok megtekintését, elemzését Az informatikai célrendszerre vonatkozó informatikai biztonsági előírások 40 teljesülését meghatározott időközönként (az éves minőségbiztosítási audit kapcsán) A rendszeresen felülvizsgálni, ellenőrizni szükségesés független szakértővel ellenőriztetni (minősíttetni) javasolt. Időszinkronizálás A pontos rendszeridő 41 ismerete és használata egy hálózatban legalább olyan fontos, mint a megfelelő biztonsági stratégia. A beépített hardveróra (BIOS) nem felel meg az alkalmazások például adatbázisok követelményeinek. A rendszeridő kézi javítása számos problémához vezethet, egy hibás beállítás visszafelé a kritikus alkalmazások tekintetében hibás működését vagy inkonzisztenciát eredményezhet. A hálózatban általában az összes eszköz rendszeridejét szinkronizálni kell. A kézi időbeállítás nem tekinthető jó megoldásnak. Az informatika világában több megfelelő mechanizmust biztosított e probléma megoldásához. A hálózat megbízható időkiszolgálói segítségével folyamatosan ki kell igazítani a rendszeridőt. A A A HIS rendszerben működő illetve azzal online vagy offline kapcsolatban lévő minden eszköz és szoftver időszinkronizálását ugyan arról a helyről kell megvalósítani. Intézményen belül biztosítani kell a szerver, kliens eszközök és alkalmazások időszinkronizálásának megoldását. 37 EuroRec:EU EuroRec: EU EuroRec: EU Az előírásokat a 195/2005. (IX. 22.) Korm. rendelet változásának megfelelően módosítani szükséges. 41 A gyakorlatban többféle forrásból kaphatunk pontos időt. pl: az atomórák által előállított idő,a GPS (Global Positioning System), stb. Összeállította a GYEMSZI szakértői munkacsoportja 27

32 Megoldásszállítónak be kell mutatnia, hogy hogyan, milyen módon és milyen A gyakorisággal kerül megvalósításra a HIS szerver,adatbázis kezelő szoftver és az alkalmazás órájának szinkronizálása. A Az időszinkron állítás úgy kell megvalósítani, hogy a szinkronizálás idejére ne kelljen az alkalmazást leállítani. A Interneten keresztül szabványos protokoll segítségével kell az időszinkronizálást megvalósítani. Nyelvi követelmények Ezen pontban leírtak evidenciának tűnhetnek, ám a pályázatok kiírása során bizonyos esetekben nem kizárható a csak nemzetközi referenciákkal rendelkező informatikai szállító. A megajánlott szoftver felhasználói felületén (legkésőbb az oktatás és az éles próbaüzemi procedúra időszakára) minden szöveges kommunikáció legyen A nyelvtanilag helyes, az adott nyelv karakterkészletét szabályosan jelenítse meg. Alapértelmezésben magyar nyelvű felültetet biztosítani kell, további nyelvi felület megengedhető, de a magyar nyelvű felület hiánya csak előzetes megegyezés esetén engedhető meg. A A rendszer minden eleme helyesen kezelje a magyar nyelvi előírásokat (pl. névsorba rendezés) és a magyar ékezetes karaktereket mind a képernyőn mind a nyomtatásban. A rendszerhez minden funkcionális nyomtatási igényeit ki tudják szolgálni és A csatlakoztathatók legyenek a magyar piacon kapható standard nyomtatók (lézer, mátrix, etikett, karszalag, stb.). A nyomtatók rendszerhez illesztésének ne legyenek speciális igényei. A A rendszergazdai felületeknél törekedni kell a magyar nyelv használatára, de megengedett az angol nyelv használata is. A Minden oktatás nyelve alapértelmezés szerint magyar legyen. További nyelveken történő oktatást előzetesen egyeztetni szükséges. A A felhasználói dokumentációk nyelve magyar. A A rendszergazdai dokumentációknál is törekedni kell a magyar nyelvű verzióra, de indokolt esetben megengedett az angol nyelvű is. A projekt dokumentumok hivatalos nyelve magyar legyen kivéve ha a kiírás másként nem rendelkezik, de ebben az esetben is gondoskodni kell a projekt szempontjából A meghatározó dokumentumok hivatalos magyar fordításról. Ezzel kapcsolatban elvárt minimális projekt menedzsment dokumentumok: Szerződés,PAD, Teljesítés igazolások, Átadás-átvételi dokumentumok, Projekt vezetői megállapodások, Változás kezelés, Próbaüzemi jegyzőkönyvek) A A megajánlott rendszer felhasználói felületének a nyelve legyen állítható. A A megajánlott rendszer nyelvi beállítottsága egyes felhasználóhoz, vagy felhasználó csoporthoz legyen kapcsolható. A hazai törvényi előírásoknak való megfelelés (jogszabályi megfelelés) Az informatikai szállítónak be kell mutatnia, hogy a megajánlott rendszer teljes körűen A megfelel a megajánlott egészségügyi munkahelyre 42 vonatkozó magyar jogszabályi előírásoknak és az aszerinti működésnek. A A szoftvernek alkalmasnak kell lennie a működési és finanszírozási gyakorlatnak A megfelelő: o szervezeti struktúra leképezhetősége a szoftver telepítése, paraméterezése és megjelenése során. 42 Alapellátás, ambulancia, szakrendelő, fekvőbeteg ellátás, krónikus ellátás, egynapos sebészet,stb. illetve ezek vegyesen. Összeállította a GYEMSZI szakértői munkacsoportja 28

33 A o törzsadattárak kialakíthatóságára. A o Ellátás biztosító személyek személyes és szakmai adatainak rendszerbe történő rögzíthetősége. A o Páciens törzsadatok rögzíthetősége. A o Ellátó egységek adatainak rögzíthetősége. A o Szabványos regionális és ágazati szintű működés és kommunikáció kialakíthatósága. o Az ellátás folyamata során a magyar szakmai, működési és finanszírozási A gyakorlatnak megfelelő dokumentációs rend kialakíthatósága (Az intézményi folyamatok követése és támogatása). A o intézményvezetéssel, működéssel kapcsolatos automatikus lekérdezések definiálhatósága és ütemezett elkészítésére Az informatikai szállító által leszállított rendszernek minden olyan modulja A rendelkezzen szoftver akkreditációval, ahol ezt törvény előírja.(pl: receptíró alkalmazás) 43. A szállított szoftverekre a szerződés teljes időtartamára szóló díjmentes A jogszabálykövetést kell biztosítani a jogszabályban előírt határidőre és a rendszert mindenkor díjmentesen alkalmassá kell tenni a jogszabályban előírt határidőre az adatszolgáltatási kötelezettségeknek (pl: adatbevitel, kódszótárak, adatküldés). A jogszabályváltozások miatti módosítást abban az esetben is térítésmentesen kell A elvégeznie az informatikai szállítónak amennyiben változtatás elvégzéséhez az informatikai szállító olyan program modult fejleszt ki, amely az eddigi beüzemelt új modulok között nem szerepelt. A jogszabályi változásokat legkésőbb a hatályba lépést megelőző 3 munkanappal előbb A a rendszer éles verzióján át kell vezetni (Az éles rendszerre való telepítést meg kell előznie egy sikeres tesztüzemnek). A működtetéshez szükséges dokumentáció és oktatási anyag átadásának is ez a határideje. Visszamenőleges hatálybalépés esetén úgy kell a változást a rendszeren átvezetni, hogy biztosítani kell az egészségügyi intézmény számára, hogy a szükséges tevékenységet A visszamenőlegesen is elvégezhesse oly módon, hogy rá nézve negatív következményekkel vagy anyagi kárral ne szolgáljon. Ebben az esetben törekedni kell a lehető legegyszerűbb adatbevitel biztosítására. Az informatikai szállítónak biztosítania kell, hogy a szerződés megszűnése után a tárolt A adatok a jogszabályi előírásoknak megfelelően díjmentesen visszakereshetők maradnak. Az ajánlatban részletes leírást kell a megvalósítás módjáról adni 44. Működtetéssel kapcsolatos dokumentáció Az átadás átvétel során minimálisan az alábbi rendszergazdai dokumentumokat kell A átadni olyan részletezettséggel, hogy egészségügyi intézmény szakemberei a dokumentáció alapján az üzemeltetéssel kapcsolatos feladatokat el tudják látni A o Logikai rendszerterv A o Fizikai rendszerterv A o Működési folyamat és kommunikációs leírások 43 53/2007 (XII: 7.) EüM rendelet a gyógyszerrendeléshez használandó számítógépes program minősítésének szabályairól 44 A jelenlegi a virtualizált szoftverkörnyezetben történő adatmegőrzés tűnik a legmegfelelőbb megoldásnak. Ezért a megoldásszállítónak segítenie kell a szerződés megszűnése után a szervereken tárolt alkalmazások virtualizált környezetbe történő áttelepítésében. Összeállította a GYEMSZI szakértői munkacsoportja 29

34 A o Adatbázis szerkezet leírás 45 A o Interfész specifikációk 46 A A o Funkcionális tesztelési terv és annak eredménye o Terheléses tesztelési terv és annak eredménye A o Mentési visszaállítási terv 47 A o Telepítési és paraméteresési útmutatók 48 A A A A A A A A A A A A A A o Felhasználói kézikönyvek o Üzemeltetési kézikönyv és szolgáltatási szint leírás o Informatikai biztonsági szabályzat o Migráció leírás o A működtető szervezet installációs és konfigurációs tevékenységeire vonatkozó kézikönyv o Az illesztett rendszerek illesztési protokolljának leírása 49 o Távoli menedzsment kialakításának paraméterei (pl: VPN) o Felhasználói kézikönyv (modulonként) o Vészhelyzeti működési szabályzat o Az üzemeltetési szabályzat feladatlistájának részletes összeállítása 50 o Minőségellenőrzési jegyzőkönyvek o Megvalósítási dokumentáció 51 o Változáskezelést rögzítő dokumentáció mely a projekt teljes életszakaszában vezetendő dokumentum 52 Az Ajánlatevő köteles olyan részletezettségű dokumentációt biztosítani minden átadott modulhoz, amely alapján az egészségügyi intézmény szakemberei az elvárt 45 Az ellenőrzések a lekérdezések és az adatmigráció érdekében elkerülhetelen az adatbázis logikai, szerkezeti felépítésének dokumentáltsága. 46 Részletesen lásd Architekturális követelmények Általános architekturális követelmények 47 Részletesen lásd Architekturális követekmények Mentési, archiválási, visszatöltési követelmények 48 A telepítési útmutatóknak minden rendszerbe integrált eszköz és szoftver telepítési, paraméterezési beállítását tartalmaznia kell. A változáskezelésben frissíteni szükséges. 49 Lásd az archuterturális követelmény leírásoknál megfogalmazottak 50 Ez az egészségügyi intézmény és az Ajánlattevő közös feladata. 51 Ennek a dokumentumnak tartalmaznia kell a rendszer minden állítható paraméterének éles induláskori értékét 52 Ez az egészségügyi intézmény és az Ajánlattevő közös feladata. Összeállította a GYEMSZI szakértői munkacsoportja 30

35 A működtetési feladatokat el tudja végezni. A dokumentációkat elektronikus és minimum egy nyomtatott példányban is át kell adni. Ez alól kivételt képeznek az oktatási dokumentumok Az egészségügyi ellátási szintek specifikus követelményei Az alapellátás specifikumai Az alapellátás fogalma: társadalmilag, bizonyos funkcióval szervezett egészségügyi ellátás lakosság közelébe vitt formája. Az egyes alfejezetet a fontosság sorrendjében tárgyaljuk. Az informatikai követelményeket úgy határozzuk meg, hogy az alapkövetelményeken (biztonság, megbízhatóság, stb.) felül milyen elvárásai vannak a rendszereket kezelő orvosoknak, asszisztenseknek, az ellátottaknak, a szakmai (kereskedelmi) felügyeletet gyakorlónak és a finanszírozónak. Az informatika feladata: az egészségügyi ellátás alapellátói (orvosok, szakdolgozók) tevékenységeinek kiszolgálása az informatika eszközeivel, a betegellátás minőségének és hatékonyságának emelésével. Napjainkban az alapellátók szinte kivétel nélkül alkalmaznak informatikát. Az informatikai rendszerekkel szembeni követelményeket az általános információskommunikációs technológiai jellegű követelményeken kívül aszerint csoportosítjuk, hogy hogyan szolgálják ki a rendszerek által érintett személyeket és szervezeteket. Még mielőtt az egyes alapellátók rendszereit tárgyalnánk, általános minden ilyen rendszerre érvényes követelményeket fogalmazunk meg. Az alapellátás szintjéhez tartozó ellátási rendszerek közül a betegellátással foglalkozókra háziorvosi ellátásra (felnőtt, vegyes, gyermek és ügyeleti ellátások), a foglalkozás és üzemegészségügyi ellátásra, a védőnői szolgálatra vonatkoznak a definiált specifikumok. Az alapellátáshoz tartozó többi ellátással, közöttük a preventív és karitatív szolgálatokkal (a fogorvosi ellátás és az iskola egészségügyi ellátás, ifjúság és gyermekvédelem, a szociális betegellátás és intézményei), a gyógyszertárakkal a jelenlegi követelmény rendezés nem foglalkozik, de szükség szerint megjelöli az információrendszerek közötti kapcsolatokat Háziorvosi, házi gyermekorvosi rendszerek A háziorvosi ellátás társadalom egészségügyi konszenzusokon alapuló rendelkezések szerint meghatározott lakosságcsoport praxis ellátásra szerveződött ún. orvosi munkahelyen, illetve orvosi munkahelyek hálózatán, azaz az orvos beteg találkozások színhelyén (a rendelőben, a helyszínen) történik. Az orvosi munkahely adminisztratív megjelölése a háziorvosi rendelő (rendelők csoportja, hálózata), az ellátandókat a praxis jelöli (beleértve az ellátás különböző módon és formában szabályozott formáját). B B Az információrendszereknek az orvosi munkahelyeken, így a háziorvosi rendelőben is a gyógyító megelőző ellátás alapvető folyamatba rendezett tevékenységeit az egészségi állapot azonosítását, a diagnosztikai vizsgálatokat, a diagnózis felállítását, a terápiát és kezeléseket valamint az értékelő, minősítő tevékenységeket kell támogatnia. A tevékenységi sorhoz tartozik a rehabilitáció és a gondozás. A háziorvosi ellátás információ technológiai és kommunikációs (a továbbiakban: IKT) rendszer alap konfigurációja a személyes interaktív kapcsolatokért felelős perifériák 53 Az elvárásokat lásd az oktatási elvárások megfogalmazásánál Összeállította a GYEMSZI szakértői munkacsoportja 31

36 B B B B B B B B B B (képernyő, klaviatúra, egér, tárkiegészítők, intelligens kártyák hagyományos és WiFi változatai) mellett tartalmazzon opcionális lehetőségeket az egyéni mobil eszközök befogadására (okostelefon, i-phone, i-pad, NFC eszközök stb.). A konfigurációnak rendelkeznie kell olyan nyomtatási lehetőséggel, amely alkalmas a jogaszályokban előírt papíralapú dokumentációk előállítására (nyomtatására, kitöltésére) és helyet kell kapnia a rendszerben az elektronikus adathordozók (kártyák, CD, DVD olvasók, pendrive-ok) mellett papíralapú dokumentációkat beolvasó eszköznek is. A háziorvosi rendszer orvosi munkahelyet kiszolgáló konfigurációja önálló működésre legyen alkalmas, de hálózatba is köthető legyen (intranet) és rendelkezzen szélessávú internet eléréssel, valamint sokoldalú elektronikus információ (jel, szöveg, hang, kép) továbbítási levelezési lehetőséggel (extranet, internet). A rendszer hálózati, internet kapcsolatának sávszélessége és sebessége (műveleti sebessége) feleljen meg a konfigurációban alkalmazott IKT eszközrendszerek (alapszoftverek, középréteg kiszolgáló szoftverek, az alkalmazói réteg szoftverei) működési és felhasználói előírásának. A munkaállomás (-ok) architektúrája alkalmazkodjon a befogadó környezethez és a telepített futtató környezethez (Windows, Linux, stb.). A rendszerben alkalmazott IKT szoftverek legyenek jogtiszták, támogatottak, és legyen biztosítva a verziókövetésük, megfelelő, az orvosi munkahelyek működését folyamatosan biztosítani képes támogatásuk (medical support). A háziorvosi rendszer dedikált adatrendszereiről, a páciens, a gyógyító - megelőző tevékenységek információról, az ellátási kimenetek adatairól meghatározott rend szerint biztonsági másolatoknak kell készülniük. A másolatok fizikai elkülönítéséről az IKT előírásokat figyelembe véve kell gondoskodni. A rendszer, a teljes IKT konfiguráció legyen biztosított a fizikai védelme, legyen vírusés behatolás védett. A rendszer működése (adat és adatbázis kezelése, dokumentáció kezelés, a páciensek személyiség védelme) feleljen meg a hatályos hazai és nemzetközi adatkezelési jogszabályoknak. A háziorvosi ellátás a praxisban körülhatárolt lakosságcsoport alapellátás szintű egészségügyi ellátását jelenti, amelyet a háziorvosi információrendszernek a praxis információrendszernek kell kiszolgálnia, lehetőség szerint teljes körűen. A praxis információrendszer (praxis rendszer) működése feleljen meg a háziorvosi ellátást szabályozó működési rendnek, jogszabályoknak 54. A praxis ellátását kiszolgáló információrendszer ( praxis-rendszer, praxis-szoftver ) tulajdonosa, felhasználója, alkalmazója és az informatikai rendszer szállítója (fejlesztője, az IKT karbantartója, a folyamatos support fenntartója) között olyan szerződéses jogviszonynak kell lennie, amelynek garantálnia kell a rendszer zavartalan működését. A fontosabb elvárásokat a következő sorok tartalmazzák. Legyen a praxis-szoftver olyan, hogy az egyszemélyestől a csoportos praxisig képes 54 Az alapellátás feladatait, szervezeteit, működési rendjüket a hatályos törvények és jogszabályok keretében kialakított küldetésük, az orvostudomány és a társtudományok mindenkori elmélete és gyakorlata határozzák meg. A fentiek köré csoportosított rendező elveket különféle szervezeti és működési szabályzatok, hatásköri kompetenciák, orvosi protokollok és más dokumentumok tartalmazzák. Miután az alapellátást kiszolgáló egészségügyi informatika a klinikum, az orvosi munka szerves része, az alapellátás és ezen belül a háziorvosi ellátás információrendszereinek ezt az elméletet és gyakorlatot kell támogatniuk azzal, hogy rájuk vonatkoznak az alkalmazott informatika elméleti és módszertani szabályai is. Összeállította a GYEMSZI szakértői munkacsoportja 32

37 B B B B B B B B B B B B legyen kiszolgálni az háziorvosi munkahelyeket. Legyen a praxis-szoftver felkészítve a praxisban használt legáltalánosabb informatikai összeköttetésre alkalmas orvosi eszközök, osztott intelligenciájú műszerek (holter, EKG, spirometer, audiometer, telemetriás és ambiens-intelligens eszközök, stb.) interaktív kezelésére. Legyen a háziorvos és a praxis-szoftver fejlesztője között rendszeresített információs csatorna (ügyfélszolgálati célú), amelyen keresztül az észlelt rendellenességek jelezhetőek. Minden észlelt és valós szoftver hiba javítása az összes praxis-szoftver számára legyen automatikusan elérhető Legyen a praxis szoftver verziókövetett, az akkreditált frissítések lehetőleg automatikusan történjenek egy help-centerből, de legalább a verziók a háziorvosok számára on-line vagy adathordozón legyenek elérhetőek. Alapvető követelmény a praxis-szoftverben az elektronikus betegazonosítás, a TAJ és más egészségbiztosítási jogosultság, jogviszony ellenőrzés on-line megvalósítása a praxis telephelyén, telephelyein. A rendszerbe csak a csak a jogosult felhasználók léphetnek be, érhetik el és kezelhetik a praxis-szoftver betegadatait 55. Ehhez a hozzáférési jogosultság legyen beállítható és minden jogosultsági tranzakció legyen követhető digitálisan. A praxis-szoftver legyen képes exportálni a különböző formátumú tartalmakat többek között táblázatos formátumúakat a külső felhasználás számára. A betegek esettörténetében szereplő adatok kezelését naplózni kell olyan adattartalommal, amelyből az adatkezelés reprodukálható és ezzel együtt működjön a biztonságos és funkciók szerinti mentés. A rendezett archívum a praxis-szoftver alapvető szolgáltatása. A praxis-szoftver rendelkezzen különféle szolgáltatásokkal a páciensek irányába. Nevezetesen legyen időpont foglalási lehetőség a betegek számára, legyen beteghívó lehetőség és rendelkezzen a kommunikáció technológiai eszközeivel ( Legyen lehetőség a beteggel elektronikus úton érintkezni (elektronikus kapcsolat a beteggel: , sms, okos telefon, stb.). Emellett rendszer tartalmazzon olyan opciókat, amellyel a beteglátogatáskor az orvos munkája közvetlenül támogatható (okostelefon, laptop, notebook, ipod, tablet, stb.) Szükség esetén a képernyő tartalma és a billentyűzet adatbeviteli szolgáltatása legyen mind az orvos, mind pedig az asszisztencia számára egyszerre elérhető, azaz szinkronban szolgálja ki az orvost és az asszisztenciát. A rendszer legyen képes több telephelyen akár egyidejű működésre és rendelkezzen a helyettesítés lehetőségével A praxisban működő rendszerek között legyen olyan interaktív adatkapcsolat, amely lehetővé teszi az eredmények kölcsönös lekérdezhetőségét. A horizontális, alapellátáson belüli hálózaton kívül a rendszer legyen alkalmas a magasabb ellátási szintekkel (szakorvosi járó és fekvőbeteg ellátás, szakosított szakellátás intézményei) való interaktív adat, lehetőség szerint jel és képtovábbító 55 A betegadatok, gyakran használt kifejezés, azonban ez szélesebb értelemben értendő a gyógyító megelőző ellátás különféle rendszereit kiszolgáló információrendszerek esetében. Magába foglalja a páciens egészségi állapot tisztázásával, a diagnózishoz vezető vizsgálatokkal, a diagnózisokkal, az invazív és non invazív terápiákkal, a kimenetel és a minőség elemzésével kapcsolatos információkat. A betegadminisztráció kifejezés a betegadatok kezelését jelenti. Összeállította a GYEMSZI szakértői munkacsoportja 33

38 B B B B B B B B B B kapcsolatra valamint a telemedicina kompetenciáihoz tartozó szolgáltatások teljesítésére. A rendszernek legyen a jelentési kötelezettségeket is kiszolgáló állandó interaktív kapcsolódási lehetőségei az ágazati beszámoltatási jelentéseivel, adatbázisaival, az egészségügyi közhiteles adatbázisokkal és kódszótárakkal (ÁNTSZ, OEP, GYEMSZI) valamint lehetőleg nemzetközi tudásbázisokkal (pl.: bizonyítékon alapuló orvoslás). A felügyeleti szervekkel és nem ágazati közigazgatási szervekkel legyen lehetőség elektronikus kapcsolat felépítésére és a jogszabályokban, az ágazati beszámoltatási rendszerben előírt jelentéseket a rendszer automatikusan szolgáltassa. Legyenek epidemiológiai statisztikák elérhetőek és generálhatóak a rendszerben valamint a praxis kiszolgálásához, szakmai támogatásához szükséges hazai (szakmai kollégiumok, tudományos társaságok, kutató intézetek) és nemzetközi (WHO, OECD, nemzetközi társaságok) tudásbázisok és szótárak (BNO, FNO, OENI, stb.) szolgáltatásaikkal együtt legyenek hozzáférhetők. Legyenek a legfontosabb népbetegségek kezelésére és ellátására vonatkozó protokollok elérhetőek a háziorvos számára olyan módon, hogy az a gondozási feladatait támogassa. Az alapellátási információrendszereknek így a háziorvosi rendszernek is a meghatározó bázis rendszereleme a páciens rekord, pontosabban az elektronikus beteg rekord 56. Épp ezért a betegadminisztrációban és a praxis-rendszer minden moduljában biztosítani kell a páciens rekord kezelését, a páciens-orientált rendező elv érvényesítését. A beteg megjelenésének, és ellátásának adminisztrációja legyen folyamatszerűen megoldva, beleértve az OEP jelentések (változás-, TAJ-, ambuláns-, szűrési és tételes forgalmi jelentések) on-line szolgáltatásait is. A rendszer legyen képes a törzskartonhoz dokumentumokat, OLE objektumokat (kép, video, hang) csatolni. A betegadminisztráció legyen képes dokumentálni a beteg egészségi állapotát, annak változását meghatározó a háziorvos tudomására került jellemzőit, leírását: a beteg törzskartonját. A betegadminisztráció legyen képes a beteg adatai között lekérdezést végezni betegségre, betegségcsoportra, ellátási időszakra, alkalmazott terápiára, diagnosztikára, a manuális törzskarton adatainak kezelésére. A háziorvosi rendszer legyen képes a rendelés folyamatát kezelni, az ott felmerült aktivitásokat dokumentálni, vizsgálatkérő lapo(ka)t és konzílium kérés(eke)t előállítani nyomtatott formában, de állítsa elő elektronikus formában is, amennyiben a másik egészségügyi szolgáltatónál megvannak a fogadás feltételei. A rendszer legyen képes a háziorvos praxisában lévő gondozottakkal, veszélyeztetettségük miatti megfigyelést igénylőkkel való kötelező tevékenységeket tervezni, követni, ezzel kapcsolatosan figyelmeztetni. 56 Az egészségügyi információrendszerek mindazok, amelyek a populáció gyógyító megelőző ellátását támogatják, illetve annak szerves részét alkotják a páciensek, a betegek páciens orientált informatikai struktúrát, rekordot használnak az ellátás, a diagnózisok, az eredmények, terápia értékhordozó információinak rögzítésére, kezelésére, követésére. A szinonim elnevezések: elektronikus beteg vagy páciens rekord, kórlap, kórtörténet, leggyakrabban használt nemzetközi elnevezés: electronic medical record [EMR]. A személyre szabott egészségügyi ellátás terjedésével (personalized health) egyre gyakrabban jelenik meg a probléma orientált portábilis páciens rekord fogalma (az elektronikus jelzőt beleértik az alapelnevezésbe, magától értetődőnek tartva azt). Összeállította a GYEMSZI szakértői munkacsoportja 34

39 B B B B B Legyen a rendszer képes mindenfajta a praxisban dolgozó orvos számára megengedett készítményt előírását tartalmazó rendelvény (vény) előállítására (nyomtatására); opcionálisan a vény elektronikus feltöltésére a központi erecept felületre. A praxis-szoftver legyen képes a háziorvosi rendszer ügyeleti szolgálatát támogatni, a jelentkező betegek ellátási eredményeit rögzíteni, a szükséges a sürgősségi ellátás szempontjából fontos információkat értékelni és kezelni. A praxis-szoftver rendelkezzen a terápiát, a gyógyszerelést segítő adatbázis hozzáférésekkel, az esetleges tele-konzilium opcionális alkalmazásával. Az ügyeleti rendszer modul legyen képes az ügyeleti működésről szóló jelentéseket, elemzéseket, értékeléseket hagyományos és elektronikus formában elállítani és továbbítani. A program automatikusan állítsa elő az ügyeleten történt ellátások leletteit és ezeket elektronikus formában juttassa el az ügyeleti ellátáshoz területilag kapcsolódó praxisokhoz Gyógyszertári rendszerek Bár elméletileg a gyógyszertári rendszerek nem a klasszikus alapellátás részei, viszont a a gyógyszertárak szervezése, lakosság-közelisége, számossága és fontossága azt kívánja, hogy itt tárgyaljuk. A gyógyszertár egészségügyi szolgáltató és kiskereskedelmi tevékenységet végző egészségügyi intézmény. Gyógyszertár közforgalmú-, intézeti-, fiók- és kézigyógyszertári formában működhet. A gyógyszertár egészségügyi feladata a lakosság gyógykezeléséhez kapcsolódó gyógyszerek kiszolgáltatása, valamint az e gyógyszerekkel kapcsolatos, a betegségek megelőzését szolgáló, a betegekkel történő együttműködést megvalósító felvilágosító, tanácsadó szolgáltatás. Mivel a gyógyszerterápia elrendelői és annak kiszolgálói egyaránt korszerű információs rendszereket használnak, időszerű a közöttük való kommunikáció legfőképpen az e-recept szolgáltatás kiépítése. A gyógyszertári rendszereket jelen dokumentum kizárólag egészségügyi szempontból tárgyalja, nem foglalkozunk a gyógyszertárak kereskedelmi, gazdálkodási, pénzügyi elvárásaival. B B B B B A gyógyszertári rendszer értelemszerűen feleljen meg a hatályos egészségügyi jogszabályoknak és egyúttal támogassa a fiók-gyógyszertári, valamint kézigyógyszertári készletek kezelését. A rendszer segítségével legyen elkészíthető az egészségbiztosítási szerv felé a jogszabályokban meghatározott elszámolás (heti) és támogassa az expediálás folyamatát, az ügyfelek számára jelenítse meg a gyógyszervásárlás releváns információit (pillanatnyi összérték). A gyógyszertári rendszernek biztosítania kell a gazdálkodáshoz szükséges funkciókat: megrendelés, beszerzés, készletgazdálkodás, saját felhasználás, számlázás, számlavezetés, könyvvezetés, nyilvántartások vezetése, pénzügyi bizonylatok kezelése, hulladékkezelés, minőségbiztosítás A rendszer tartson kapcsolatot a gyógyszer szállítókkal, tartalmazzon paraméterezhető szolgáltatást a gyógyszer készletfogyás figyeléséhez a gyógyszerlejáratok követésével együtt. A rendszerek tartalmazzák a legfrissebb gyógyszer-helyettesíthetőségi táblázatot, és kontra-indikációs táblázatot és legyen képes a rendszeres gyógyszerelés követésére, a Összeállította a GYEMSZI szakértői munkacsoportja 35

40 B B készletek ehhez történő igazítására. A gyógyszertári rendszer működjön együtt az OEP rendszerével, és használja az elektronikus TAJ ellenőrzést és opcionálisan készüljön fel az e-recept funkció használatára és szolgáltatásaira. Legyen lehetőség a beteg kérésére gyógyszert rendelni, azaz a rendszer kezelje a készítendő gyógyszerek adminisztrációját (beteg visszahívási szám) Foglalkozás egészségügyi rendszerek A foglalkozás-egészségügyi szolgálat feladata hogy (i) felkutassa, folyamatosan ellenőrizze a munkahelyi (fizikai, szellemi, lelki) megterhelést és a munkakörnyezeti kóroki (fizikai, kémiai, biológiai, pszicho-szociális, ergonómiai) tényezőket; (ii), hogy javaslatot tegyen arra, milyen módszerekkel lehet mindezeket az egészséget nem károsító szinten tartani; (iii) hogy testi, szellemi és lelki egészségi állapotuknak megfelelően a munkavállalók képességeihez adaptálja a munkát; (iv) hogy a munkájukkal kapcsolatban ellenőrizze a munkavállalók egészségét. Ezeket a szolgáltatásokat alapszolgáltató, központ és szakellátó szinten nyújthatják. A foglalkozás-egészségügyi rendszerek a fenti feladatot támogatják. A foglalkozás-egészségügyi rendszerek a rájuk vonatkozó hatályos jogszabályoknak megfelelően működjenek, információrendszerük legyen képes a foglalkozásegészségügyi szolgáltató tevékenységét adminisztrálni és dokumentálni, mindenek előtt B a páciensek ellátását követni. Legyen képes a munkaköri, szakmai illetve személyi higiénés alkalmassági vizsgálatot B dokumentálni és a foglalkozási betegségek és fokozott expozíciós esetek kivizsgálását az elektronikus páciens rekordban. Legyen alkalmas szakorvosi, kórházi beutalót, konzíliumkérést, vizsgálati eredményt, B és más páciens orientált bizonylatot készíteni hagyományos és elektronikus formában Az információrendszer folyamatosan kövesse a dolgozók alkalmassági vizsgálatát, megjelenéseit, gondozási-szűrési adatait, tárolja a beutalásokat, vizsgálati B eredményeket és a felírt gyógyszereket, továbbá segítségével tételes és számszerű kimutatások, elemző statisztikák készíthetők, akár grafikus formában is és elektronikusan kezelhető módon. A rendszer végezze el a partner munkahelyek és munkahelyi bejelentők nyilvántartását, dokumentálja az üzemorvosi ellátás minden elemét az anamnézistől, az B alapvizsgálatokon, a higiénés adatlap vezetésen, a kötelező vizsgálatokon át, a munkaköri védőoltásokig. Legyen képes a közúti járművezetők egészségügyi alkalmassági vizsgálatának B dokumentálására, jogosítvány adatainak tárolására és segítségével legyen készíthető alkalmassági vélemény, egészségügyi nyilatkozat lőfegyver használati engedélyekhez. Tartalmazzon adatbázist az egyéni védőeszközökről, legyen képes a munkavégzés B egészségkárosító hatásának vizsgálatát dokumentálni, legyenek elemzési, értékelési lekérdezési és statisztikai funkciók. Legyen a rendszerben olyan informatikai panel, amely alkalmas a munkáltató B katasztrófamegelőző, -elhárító, -felszámoló és rehabilitációs tervének kidolgozására. Összeállította a GYEMSZI szakértői munkacsoportja 36

41 B B A rendszer legyen opcionálisan képes a háziorvosi rendszerhez hasonlóan - mindenfajta a sürgősségi ellátás számára megengedett készítményt előírását tartalmazó rendelvény (vény) elektronikus formában a leendő e-recept központnak továbbítani. A rendszer legyen képes a szükséges jogszabályokban előírt jelentések elkészítésére hagyományos és elektronikus formában és legyen képes elektronikus úton történő elküldésükre Védőnői rendszerek A védőnői szolgálat feladata a gyermekágyas nő gondozása, az újszülött-kor, a gyermekkor egészség-menedzselése, a család egészségnevelése, egészség-tanácsadása. Ehhez tartozik a védőoltási rendszer (kötelező, életkorhoz kötött) működtetése, az ezzel kapcsolatos jelentések készítése. A jogszabályoknak megfelelően a védőnők tevékenységének tárgyi feltételei között találjuk a számítógépet (1 db/2 fő), illetve hardver+szoftver+karbantartás követelményét. A rendszerek fenntartásáról a védőnői szolgálatot működtető szervezet biztosítja. B B B B B B A védőnői tevékenységeket támogató információrendszer elégítse ki a szakmai elvárásoknak, védőnőkre vonatkozó hatályos jogszabályoknak megfelelő követelményeket. A védőnői rendszer adminisztrálja a védőnő tevékenységét, a szükséges ellátásigondozási adatokat (gyermekágyas nyilvántartás, várandós törzslap, gondozási lap, újszülött nyilvántartás, újszülött gondozási lap, gyermek-egészségügyi törzslap, egyedi oltási lap, oltási összesítő). A védőnői rendszer segítségével ki lehessen mutatni a védőnői ellátás (gyermekágyas anya, újszülött) megfelelőségi indikátorait A védőnői rendszer segítségével legyen készíthető, módosítható a várandós gondozási terv. A védőnői rendszer legyen alkalmas a munkakör tevékenységeinek hagyományos adminisztratív támogatására, de rendelkezzen az adatbázisára támaszkodó elektronikus változatokkal is. A rendszer részletes (ki, hol, mit, mikor) és könnyen lekérdezhető tranzakciós és eseménynaplózással rendelkezzen minden tranzakcióról (pl: adat bevitel, módosítás, megtekintés, nyomtatás, törlés, adat továbbítás, adat leválogatás stb.) Az szakellátás specifikumai Tranzakció és eseménynaplózás a HIS rendszerekben A felhasználók az adatbázis-kezelő és az operációs rendszer tevékenységeit naplófájlban kell rögzíteni. Ebből megtudhatjuk mikor ki jelentkezett be és mit csinált a rendszerben. A naplózást lehetőség szerint úgy kell beállítani, hogy minél szélesebb körű legyen a tevékenységek naplózása. C A HIS rendszer működtetésével kapcsolatos eseményeket és az ehhez kapcsolódó információkat tárolni kell (bejelentkezés időpontja, felhasználó név,használt szoftver képernyő azonosító, tevékenység (új adat bevitel, törlés módosítás, stb.). 57 A HIS rendszerben működő minden eszköz időszinkronizálását ugyan arról a helyről kell megvalósítani. 58 EuroRec: EU Összeállította a GYEMSZI szakértői munkacsoportja 37

42 Az üzemeltetésével kapcsolatos eseményeket egy külön állományban naplózni kell (pl. C új verzió betöltés, új adatbázisok betöltése, hibaelhárítás, rendszer újra indítás, tesztelés, stb.). A rendszer részletes (ki, hol, mit, mikor) és könnyen lekérdezhető tranzakciós és C eseménynaplózással rendelkezzen minden tranzakcióról (pl: adat bevitel, módosítás, megtekintés, nyomtatás, törlés, adat továbbítás, adat leválogatás stb.) 60 C Minden beteg egyedileg és maradandóan legyen az HIS rendszerben azonosítva 61. C C C C C C C C C C C C C C Minden felhasználó egyedileg és maradandóan legyen a HIS rendszerben azonosítva. Az egészségügyi adatelem minden verziója egyedileg és maradandóan legyen azonosítva a HIS rendszerben. Minden egészségügyi adatelem maradandóan kapcsolódjon össze egy azonosított pácienssel a HIS rendszerben 62. Egy egészségügyi adatelem minden változása az elem új verzióját eredményezze a HIS rendszerben. Az egészségügyi adatelemek verziók időbélyeggel (bejegyzés dátumával és idejével) és a módosításért felelős személy azonosítójával ellátva listázhatók legyenek. Az egészségügyi adatelemek verziókövetését úgy kell megvalósítani, hogy a módosított adat eredeti tartalmát is meg kell őrizni. Az egészségügyi adatelem minden verziója érvényességi idővel rendelkezzen. Az egészségügyi adatelemek minden verziója rendelkezzen egy tevékenységi állapottal, státusszal (aktív, inaktív, feladott, érkeztetett, teljesített, lezárt, megtörtént vagy elmúlt, befejeződött, megszakadt, archivált, visszautasított, stb.) Egy egészségügyi adatelem minden verziója mellett kerüljön tárolásra az adat, amely azonosítja azt az aktor (személyt vagy automatát) aki ténylegesen rögzítette az adatot,. adatokat. Az egészségügyi adatelemek változtatásainak teljes története prezentálható. A rendszer tegye lehetővé a felhasználó számára az egyes egészségügyi adatelemek bizalmas kezelésének jelölését. A rendszerben törlésre jelölt adatok fizikálisan ne törlődjenek a rendszerből. Az egészségügyi adatelem törlésének eredménye egy új változata ennek az egészségügyi adatelemnek, "törölve" státusszal. A rendszerbe szerkesztett dokumentumok, dokumentum elemek (szekciók) előző verziói is megtekinthetők legyenek. 59 EuroRec: EU A HIS rendszerben működő minden eszköz időszinkronizálását ugyan arról a helyről kell megvalósítani. 61 A rendszert fel kell arra készíteni, hogy a páciens bármely kűlső azonosítóinak megváltozása esetén is a rendszerben az azonosítás, megfeleltetés egyértelműen megadható legyen 62 Lehetőséget kell biztosítani paciens adatok összefűzésére és szétválasztására (lásd a késöbbiekben) Összeállította a GYEMSZI szakértői munkacsoportja 38

43 Az egészségügyi dokumentumok adatvédelmével kapcsolatos adatvédelmi elvárások Az egészségügyi informatikai rendszerek, a páciensek egészségi állapotra vonatkozó személyes adatokat és az azokhoz kapcsolódó klinikai vizsgálati és finanszírozási adatokat, egészségügyi dokumentumokat, képi információkat, terápiás és gazdasági adatokat tartalmaznak. Az egészségügyi informatikai rendszerekben tárolt adatok védelme érdekében folyamatosan karbantartott tűzfal és folyamatosan frissített vírusvédelmi rendszerrel (a szervereken, klienseken) 63 kell az adatkezelőnek rendelkeznie. A vékony kliensek kártevő védelmével is foglalkozni kell! C C C C C C C C C Minden egészségügyi dokumentumot és annak minden verzióját egyedi azonosítóval és időpont megjelöléssel kell ellátni. Minden egészségügyi dokumentumnál egyértelműen azonosítani kell tudni a rögzítésének helyét (orvosi munkahely kódja)és a rögzítés idejét. Meg kell jelölni az adat rögzítőjét és a tartalomért felelős személyt (lehet azonos). A két felelősnek a rendszerben azonosíthatónak kell lennie. Az egészségügyi dokumentumokat a kezelő/adatrögzítő szerint is kell tudni lekérdezni. Az egészségügyi dokumentumoknak minimálisan az alábbi státuszok valamelyikével kell rendelkezni: aktív, jóváhagyott, törölt, előző verzió. A státuszt minden esetben meg kell jeleníteni. Az egészségügyi rendszerekben a dokumentumokhoz biztosítani kell a hitelesítési és időbélyegző szolgáltatás használatának lehetőségét. A rendszer minden adatbeviteli képernyőn ki kell jelezni a páciens intézményen belüli egyedi azonosítóját az adott kezeléshez tartozó egyedi megrendelés azonosítót és a páciens nevét. A rendszernek lehetővé kell tennie, hogy rendszergazda és csak ő erre a célra kialakított felületen teljes körűen menedzselje a jogosultságokat (felhasználói profilt hozzon létre, függesszen fel és töröljön, illetve módosítsa egy felhasználó jogosultságait). A rendszergazdai tevékenységeket megváltoztathatatlanul naplózni kell. C A rendszer felhasználóinak és adminisztrátorainak olyan szintű képzést kell kapniuk 72, 63 A tűzfalak és a vírusvédelem specifikációjával és minimális elvárásaival jelen anyag nem foglalkozik. 64 EuroRec: EU EuroRec: EU EuroRec: EU EuroRec: EU EuroRec: EU EuroRec: EU EuroRec: EU ; EU EuroRec: EU Összeállította a GYEMSZI szakértői munkacsoportja 39

44 hogy a feladataikat önállóan el tudják végezni. C C C C C C C Az egészségügyi adatokhoz való hozzáférést minden esetben meg kell előznie a megfelelő azonosításnak. A felhasználó orvos/szakdolgozó csak azokhoz az adatokhoz férhet hozzá, amelyekhez jogosultsága van. A rendszernek biztosítania kell a törvény szerinti páciens adatokhoz történő hozzáférés beállíthatóságát a szerepkörhöz kötött működést és beállításokat (kezelőorvosi, háziorvosi szerepkör) 75 A rendszernek biztosítania kell, hogy a megfelelő jogosultsággal rendelkező felhasználó megváltoztasson, vagy töröljön egészségügyi, vagy adminisztratív adatokat. A módosított/törölt adatokat tárolni kell a módosítás/törlés indoklásával, a módosító személyével és az időponttal együtt. Ezeket az adatokat különösen indokolt (kiemelt rendszergazdai jogosultsággal) esetekben meg kell tudni jeleníteni 77. A rendszernek biztosítania kell, hogy a páciens vagy megbízottja hozzáférhessen az elektronikus betegdokumentumokhoz vagy azok egy részéhez. A hozzáférés módját a helyi informatikai biztonsági szabályzatban kell meghatározni. Az autorizáció szintjét és az elérhető adatok körét a rendszerben rögzíteni kell. A hozzáférését naplózni kell biztonsági és audit célokra, ugyanígy a szolgáltatást nyújtó adatelérését is naplózni kell. A rendszernek meg kell felelni a hazai informatikai szabványok szerinti kommunikációnak 79. A rendszernek meg kell felelni a vonatkozó hazai és nemzetközi adatvédelmi jogszabályoknak Az alkalmazásokkal kapcsolatos jogosultság kezelés C C A rendszer tegye lehetővé a Megrendelő hozzáférési és jogosultsági policy-ének implementálását. A megajánlott rendszer legyen az SSO-ra felkészítve (a rendszerbe való belépéskor a felhasználónak mindössze csak egyszer kelljen azonosítania magát és ezután a rendszer minden erőforrásához és szolgáltatásához további autentikáció nélkül engedjen hozzáférést). A rendszer támogassa az intézmény biztonsági politikájának megfelelő jelszókezelést. Ha az intézmény nem rendelkezik biztonsági politikával/szabályzattal, akkor az alábbi jelszókezelési szabályokat kell alkalmazni: 72 Részletesen lásd az oktatásoknál. 73 EuroRec: EU EuroRec: EU A jogosultságot még idő és hozzáférési hely szerint is lehet paraméterezni. 76 EuroRec: EU Törvény által szabályozott esetekben. 78 EuroRec: EU EHR extract generálás, fogadás és kommunikáció (CEN 13606, MSZ 22800) Összeállította a GYEMSZI szakértői munkacsoportja 40

45 o A felhasználók egyszerű felületen saját maguk tudják a jelszavukat C megváltoztatni. C o A jelszó legalább 8 karakterből áll, melyben kisbetű, nagybetű és szám is van 2 80 C o A jelszavát mindenkinek magának meg kell tudni változtatni C C o A jelszót 1-3 havonta 83 legyen kötelező megváltoztatni, a változtatásra a rendszernek a lejárat előtt XX 84 nappal és ezután minden hozzáférésnél újra figyelmeztetnie kell a felhasználót. A rendszer figyelje az előző jelszavakat és ne engedjen előzőleg már használt jelszót használni a felhasználónak. o Amennyiben a jelszó lejár, új, egyszer használatos jelszót kell kérni a rendszeradminisztrátortól, amelyet azonnal meg kell változtatni. C o A jelszavakat csak vissza nem fejthető formában szabad tárolni C o Jelszót tilos telefonban, ben, szóban, vagy bármely más nem titkosított csatornán közölni, erre figyelmeztetni kell minden felhasználót. C o Sürgősségi esetre ki kell dolgozni a rendszer hozzáférés-kontroll 8 86 felülbírálatának lehetőségét. C C C C A jogosultság alapja a személy ellátásban betöltött szerepe kell, hogy legyen. o A felhasználó csoportok jogosultságát lehessen egyszerűen egy-egy személyhez hozzákapcsolni vagy elvenni o Legyen mód szerepkörökhöz kötődő másolható sémák létrehozására, amelyet az adott felhasználó adatainak beállításával lehessen személyre szabni. o A felhasználók HIS alkalmazáshoz történő hozzáférési jogosultságát személyre és szerepkörre szabottan (egy természetes személy több szerepkörben is lehet és az adatvédelmi törvény miatt ehhez különböző jogosultságok tartozhatnak) lehessen megadni. C Időszakos és csökkentett funkcionalitású jogosultságot lehessen kialakítani 87. C C C A rendszerben felhasználóként rögzített személyek adatait és a hozzájuk kapcsolódó naplóbejegyzéseket ne lehessen törölni csak a hozzáférés jogosultságát felfüggeszteni. A rendszer használatára jogosult felhasználók tevékenységéről a felhasználó által szabadon paraméterezhető napló állományt kell tudni készíteni. A megajánlott rendszer rendelkezzen olyan jogosultságmátrix kezelő rendszerrel, amelyben legyen mód egy-egy felhasználó hozzáférési jogosultság beállításával kapcsolatos összes funkció és opció beállítást, tevékenységek végzésével kapcsolatos minden jogosultságot lehetőség szerint egy funkción belül beállítani (új felvétel, 80 EuroRec: EU ; EU EuroRec: EU ; EU EuroRec: EU ; EU Legyen a rendszerben szabadon paraméterezhető. 84 Legyen a rendszerben szabadon paraméterezhető. 85 EU ; EU EuroRec: EU Például konzíliárusok számára Összeállította a GYEMSZI szakértői munkacsoportja 41

46 C megtekintés, megnyitás, szerkesztés, módosítás, nyomtatás, átemelés, validálás,stb.). A rendszernek a jogosultság beállításokat naplózni kell. A nevesített felhasználók listája legyen nyomtatható. Digitális aláírás, hitelesítés A rendszer legyen felkészítve az egészségügyi üzenetek digitális aláírásának megvalósítására és a finanszírozó által támogatott elektroniokus hitelesítési eljárásokra. A rendszernek támogatnia kell az OEP által támogatott elektronikus orvosi-, és C szakdolgozói hitelesítési és azonosítási módokat, valamit az elektronikus TAJ-kártya használatát. A megajánlott rendszer legyen képes digitális aláírással ellátott beérkező C dokumentumok fogadására és időpecséttel történő ellátására és a rendszerben történő tárolására. A megajánlott rendszer legyen képes kimenő dokumentumokat digitális aláírással C ellátni és archiválás céljából eltárolni. A használni kívánt digitális aláírásnak kétszintűen kell működnie: C o A természetes személy 89 digitális aláírása (minősített) C C C C o A természetes személy aláírását felülhitelesítő intézmény 90 aláírása (fokozott) Az aláírásokat és az esetleges XML szintű adat rejtjelezést 91 kezelő komponenseket a vonatkozó nemzetközi szabványoknak megfelelően és az EU által definiált algoritmusokkal kell megvalósítani. A megajánlott rendszer legyen felkészítve digitális aláírás modul használatára annak érdekében, hogy az aláírásra kijelölt végpontokon és folyamatlépésekben lehetőség legyen az ezt elváró rendszerek felé küldendő dokumentumok megjelenítésére és aláírására valamint időpecséttel való ellátására. Az üzenetek aláírásával kapcsolatban az MSZ szabványban előírtak a mérvadóak 92. Az üzenetek létrejöttekor biztosítani kell, hogy az egész üzenetet többen is elláthassák aláírással, illetve, hogy egy aláírt üzenet része lehessen egy másik, szintén (akár többszörösen) aláírt üzenetnek. Lehetővé kell tenni egyrészt egyenrangú aláírások, egymástól független elhelyezését, másrészt a már aláírt üzenetet egészében (a korábbi aláírással együtt) tanúsító aláírások elhelyezését. Ez utóbbi mechanizmus tetszőleges mélységben egymásba ágyazható szerkezetet hoz létre Interoperabilitás Lásd a 1.1 fejezetben ISO OID (Object IDentifier egyedi azonosító) rendszer használata C Az ISO OID-k (Object IDentifier egyedi azonosítók) rendszerének formális definícióját az X.208 (ASN.1), míg az OID-k kódolására vonatkozó ajánlást az X EuroRec: EU pl: orvos, informatikus 90 pl:intézményi célalkalmazás 91 pl: XAdES szabvány(xmldsig és a különböző XAdES formátumok) 92 Egyenrangú üzenet aláírás, beágyazó üzenet aláírás, kombinált üzenet aláírás Összeállította a GYEMSZI szakértői munkacsoportja 42

47 ITU-T ajánlás tartalmazza. Mivel a hazai és nemzetközi egészségügyi szabványok kötelező attribútumaikban alapvetően építenek az OID-k rendszerére 93, a szabványos kommunikáció és dokumentumok kialakításához szükséges az egészségügyi informatika területéhez kapcsolódó OID-rendszer használata. C C C C C C Az egészségügyi megoldásszállító rendszere legyen felkészítve az egységes ágazati portálon publikált az ágazatban használt közhiteles és közcélú adatok, illetve az egyes rendszerek működtetéséhez kapcsolódó nyilvános adatok, eljárásrendek, fogalomtárak, jelentések specifikációi, szolgáltatások specifikációi, metamodellek, validálási szabályok, kódszótárak, nyilvántartások, szabályok, kommunikációs előírások és protokollok automatikus letöltésére és a rendszerbe integrálására. Az egészségügyi megoldás szállító regisztrálva legyen a magyar ISO OID rendszerben, legyen hozzáférése a rendszerek működtetéséhez szükséges OID-khez. Az egységes ágazati kommunikációs érdekében használni kell a magyar ISO OID rendszerben publikált kódszótárakat és nyilvántartásokat. Az egységes ágazati dokumentációs rendszer során használni kell a magyar ISO OIDket. Az egységes ágazati kommunikációs- és jelentés-rendszer során használni kell a magyar ISO OID rendszerben publikált kommunikációs szabványokat és protokollokat. Az egységes ágazati EHR kommunikáció során használni kell a magyar ISO OID rendszerben publikált EHR archetípusokat Kódok, kódszótárak, szabályok Az ágazat szervezeti felépítése, bonyolult intézményrendszere, a gyógyítás szakterületi sokasága, a mindig egyedileg szabott volta sok adat- és kódszótárat feltételez. Az egészségügyi informatikai rendszerek jól specifikálható egyedi kódszótárakat használnak. A kódszótárak frissítése, verziókövetése rendszerbe integrálása a hibátlan szakmai működés legalapvetőbb feltétele. C C A megajánlott rendszer minimálisan verziózva tartalmazza: o az egészségügyben az orvosi, ápolási és a finanszírozási adatok leírásához szükséges kódszótárakat (BNO, OENO, HBCS, stb.), o a működtetéshez szükséges közhiteles kódszótárakat (pl: orvoskódok) o a beküldő egészségügyi intézményekkel kapcsolatos azonosítókat (pl. háziorvosok azonosítói, stb.) A megajánlott rendszer tartalmazza és kezelje a szakellátásra vonatkozó aktuális törzsadatokat és szabályzatokat 96 o 93 A HL7 közösség saját használatára óta mintegy 4800 OID t regisztrált a (joint iso itut.country.us.organization.hl7) node alatt EuroRec: EU EuroRec: EU ; EU pl: HBCS besorolási szabályok, járó szabálykönyv,stb. Összeállította a GYEMSZI szakértői munkacsoportja 43

48 C C C C C C A kódrendszerek verziókövetését támogatni kell a rendszernek. A megajánlott rendszerbe az egészségügyi intézet kérésére szakma specifikus és egyéb (pl: Európai szakmai társaságok kódrendszerei) és intézet specifikus kódszótárak valamint marker kódok legyenek illeszthetők kialakíthatók. 99 A megajánlott rendszer legyen időgép, amely a kódszótárakat verzió szerint tudja kezelni (érvényesség kezdete, érvényesség vége) úgy, hogy a megjelenítéskor mindig az adott időpontnak megfelelő adattartalom kerüljön kijelzésre illetve kinyomtatásra. A kódszótárakban lehessen kódra és szótöredékre keresni. Lehessen a szótárban előforduló mezőkre növekvő illetve csökkenő sorrendbe rendezni. Amelyik szótár egyedi egyéb rendszerezési móddal is rendelkezik annál azt a módot is meg kell tudni jeleníteni 100 (pl. BNO) A megajánlott rendszerben használt közhiteles kódszótárakat és a velük kapcsolatos használati útmutatókatlegyenek mindig szinkronban a közhiteles publikáció szerintivel Betegadminisztrációs rendszer A HIS rendszerek működésének legalapvetőbb modulja a betegadminisztrációs rendszer. Ezen modulban tárolt adatok struktúrája sajnálatos módon nem egységes ezért nem könnyű a rendszerek közötti páciens megfeleltetés. A modul adatmezői nagyon sok személyes és különleges adatot 101 tartalmaznak, ezért adatvédelmi szempontból is kiemelt figyelmet kell rá fordítani. Az anyag mellékletében összefoglaljuk az ezen modultól elvárt minimális funkcionalitást. C-7- A rendszer alkalmas legyen a személyi adatok idősoros követésére 103 (pl. névváltozás, igazolvány szám változás, lakcím megváltozása, telefonszám változás, stb.) C-7- A rendszernek tárolnia kell tudni igény alapján legalább egy kapcsolattartó személyt a kapcsolattartó információval. (telefon, ) C-7- Minél több természetes azonosító 106 alapján lehessen keresni (minimális elvárás: vezetéknév, keresztnév, anyja neve, születési dátum, nem, lakhely, lakcím) Minél több nem természetes azonosítót lehessen a rendszerbe rögzíteni és a rögzített azonosítók alapján keresni: o központilag generált egyedi azonosítók, pl. TAJ szám, C o a rendszer által generált egyedi azonosító, esetazonosító, megrendelés azonosító, vonalkódos azonosító stb. o intézeti egyedi azonosítók, pl.: karton szám, felvétel azonosító, média azonosító stb. A pácienshez kapcsolódó biztosítással és a majdani finanszírozással kapcsolatos adatok C idősoros nyilvántartása (biztosítottság, biztosító(k), stb.) 97 EuroRec: EU EuroRec: EU Amennyiben az egészségügyi intézmény egyedi adatok rendszerbe integrálását kéri abban az esetben is meg kell adni az adat forrását. 100 (pl. fejezetek szerinti tagozódás, fogalmi hierarchia, kereszthivatkozások, külső hivatkozások stb.) 101 Lásd: évi LXIII. Törvény 1. fejezet pont 102 EuroRec: EU ; EU A log állományokból megtekinthetők legyenek az előző verziók a módosító személye és a módosítás dátuma. 104 EuroRec: EU EuroRec: EU Természetes azonosító : valamely személy azonosítására használható adat, amelyet nem valamilyen mesterségesen rendelünk az adott egyénhez. Összeállította a GYEMSZI szakértői munkacsoportja 44

49 C C C C C Az On-line jogviszony ellenőrzésre legalább két független módon legyen lehetőség (pl: Interneten és mobil net). Műszaki hiba esetén a rendszer automatikusan váltson át a tartalék megoldásra 107. On-line jogviszony és jogosultság ellenőrzés 108 biztosítása mindenhol ahol a törvényi előírások elvárják. A megvalósított rendszerben meg kell oldani, hogy naponta egynél többször ne legyen egy betegnél TAJ szám ellenőrzés (TAJ szám proxy kialakítása). Betegmozgás adatok naplózása 109 (felvétel, távozás, áthelyezés, elbocsátás, más intézetbe helyezés, átvétel más intézettől, elhalálozás, adaptációs szabadság stb.) Legyen mód beteg adatok összefűzésére és szétválasztására. C Sürgős esetben legyen egyszerűsített felvételre lehetőség 110 C Paciensek közötti kapcsolat lehessen rögzíteni (pl:anya-gyerek(ek), gyámság stb.). C-7- A betegadminisztrációs rendszer folyamatosan bővíthető dokumentumsablon tárat tudjon kezelni (új beillesztése, módosítás, törlés stb.). C C C A dokumentumsablon tárba lehessen a törvények, jogszabályok és az egészségügyi intézmény által előírt dokumentumsablonokat, formanyomtatványokat beilleszteni melyeknek a kinyomtathatóságát és a példányszámát lehessen funkciókhoz rendelni (pl. egy páciens felvételekor automatikusan nyomtatódjon ki a személyi adatok kezelésével kapcsolatos beleegyező nyilatkozat, betegazonosító karszalag, stb.) A páciens rendelkezése szerint a HIS rendszerben tárolt adatok adathozzáférését lehessen korlátozni, titkosítani A betegadminisztrációs rendszerhez illeszthetők legyenek(lehetőleg szabványos módon) egyedi külső rendszerek és eszközök Alapvető járó és fekvőbeteg ellátási funkciók A következő táblázatban összefoglaljuk az alapvető ellátási funkciókat. Az anyag mellékletében összefoglaljuk az ezen moduloktól elvárt minimálisan funkcionalitást. A betegadminisztrációs rendszernek támogatnia kell az egy ellátási esemény C megközelítést. Meg kell tudni jeleníteni az adott egészségügyi ellátáshoz kapcsolható összes szolgáltatást és dokumentációt ( elektronikus kórlap funkció). C Legyen mód járó-fekvőbe, fekvőből-járóba való átminősítésre. Személyhez (pácienshez) köthető orvosi adatok rögzítésére legyen lehetőség (pl: C rizikófaktorok, allergia, gyógyszerérzékenység, igazolvány számok és érzékenység, stb.). C-8- Az adott orvosi szakterület által használt és a finanszírozáshoz szükséges kódszótárak biztosítása a rendszer használata során. C A kódszótárak használatát verziókezeléssel kell ellátni Ennek a követelménynek a technikai megvalósítása nem az Betegadminisztrációs rendszer feladata. 108 Műszaki hiba esetén a törvényi előírásoknak megfelelő időszakon belüli automatikus ellenőrzés. 109 pl: intézet, telephely, rendelő, osztály, nővérpult, szobaszám, ágy, 110 A sürgősségi műveleteket nevesíteni és naplózni kell. 111 EuroRec: EU EuroRec: EU pl: beteg behívó rendszer 114 EuroRec: EU EuroRec: EU Az adatok lekérdezésekor, megjelenítésekor mindig az adott időszakhoz tartozó érvényes kódokat kell megjeleníteni! Összeállította a GYEMSZI szakértői munkacsoportja 45

50 Szűkített BNO és OENO törzs definiálhatósága csoportra (pl. osztály) és orvosra, ezek C másolhatósága csoportok és orvosok között. Egyedi szakmai kódszótárak lehessen definiálni 117 és megjeleníteni a dokumentáció C készítés (szerkesztés) kapcsán. Egyedi kódszótárak esetén is biztosítani kell a verzió figyelést (Az adatok C lekérdezésekor, megjelenítésekor mindig az adott időszakhoz tartozó érvényes kódokat kell megjeleníteni!). A legsűrűbben használt laboratóriumi, diagnosztikai, konziliáris kéréseket és terápiákat C lehessen osztályhoz illetve orvoshoz rendelni amelyen előre űrlapszerűen megadhatók a kitöltendő adatok. A legsűrűbben rendelt gyógyszerek és magisztrális készítmények rendelése érdekében lehessen osztályhoz illetve orvoshoz recept makrókat és szakorvosi javaslatokat definiálni, amelyen előre megadhatók a kitöltendő adatok (kiszerelés, mennyiség, C dózis, megjegyzés, felírás jogcíme, recept típusa, diagnózis). Nyomtatás előtt lehessen az adatokon módosítani. A kitöltött illetve a kinyomtatott receptek és szakorvosi javaslatok verziózva, egyedi azonosítóval ellátva reprodukálható módon tárolódjanak el a rendszerben. A rendszer sablonokkal támogassa a gyógyszereléssel kapcsolatos adatbevitelt C strukturált. Legyen mód a napi szintű adagolást másolására és az irreguláris gyógyszerelés adatbevitelére. C-8- A rendszer tárolja és jelezze (rendszeresen frissített és auditált adatbázisból) a használt gyógyszerek mellékhatásait, kontraindikációit. A rendszernek dokumentálnia kell a gyógyszerezés elrendelését, módosítását vagy C megszüntetését illetve annak az okát, valamint az rendelő személyét és dátumát és adagolását. C-8- A leggyakrabban használt funkciókat (lehetőleg felhasználónként) lehessen csoportba szervezni. A mindennapi működéssel és finanszírozással kapcsolatos ellenőrző listák legyenek C definiálhatók a felhasználók által munkahelyenként és összesített formában (pl. nem lezárt események, nem kódolt események, duplikált adatfelvétel, stb.). Az ellátással kapcsolatos adatlapok és naplók kezelése (pl: ambuláns lap, ambuláns C napló, adatlap, stb.) A kitöltött illetve a kinyomtatott adatlapok és naplők verziózva, egyedi azonosítóval ellátva reprodukálható módon tárolódjanak el a rendszerben. C Beavatkozások közötti időfigyelés lehessen beállítani (előjegyzéseknél is). C Finanszírozási adatok egy képernyőn történő rögzítési lehetősége legyen megvalósítva. Onkológiai adatok rögzíthetősége egy képernyőn történő rögzítési lehetősége legyen C megvalósítva. A eseteket lehessen markerekkel ellátni a későbbi tudományos munkák legyűjtésének C céljára Marker kóddal ellátott esetek könnyű lekérdezési lehetősége legyen megvalósítva a C felhasználók számára. 117 Pl: szakmai kollégiumok vagy nemzetközi társaságok által kiadott kódszótárak. 118 EuroRec: EU EuroRec: EU ; EU EuroRec: EU EuroRec: EU EuroRec: EU Összeállította a GYEMSZI szakértői munkacsoportja 46

51 Megrendelésekkel kapcsolatos általános elvárások C C C C C C C Elektronikus (mind belső mind külső szolgáltatótól) szakmaspecifikus struktúrának megfelelő labor-kérés és eredmény fogadás diagnosztikai-kérés és eredmény fogadás konzílium-kérés és eredmény fogadás Az elektronikus kérőlapok űrlapként 123 szabadon definiálhatóan és szerkeszthetők (adatbeviteli képernyőn szereplő adatbeviteli mezők és nyomtatási kép) valamint verziózhatók legyenek a felhasználó által 124. A kitöltött kérőlapok legyenek nyomtathatók az adott időszaknak (időgép szerű működés elvárt) megfelelő nyomtatási elrendezéssel. A nyomtatás megjelenése a felhasználó által szabadon legyen szerkeszthető (fejléc, kép beemelés (pl. UH kép), adatelemenkénti elhelyezés definiálása, tabulálás, adatbeviteli mező üres karaktereinek levágása, pozícionálás, táblázatos megjelenítés, egyéb a rendszerben tárolt információ egyedi azonosító nyomtatás, betűtípus, betűméret, üres adatmezők elnyomása). A kitöltött illetve a kinyomtatott kérőlapok verziózva, egyedi azonosítóval ellátva reprodukálható módon tárolódjanak el a rendszerben. A rendszerbe rögzített elektronikus vizsgálatok és diagnosztikai kérések mindegyikéből automatikusan lehessen HL7 v3 verziójú munkalistát előállítani és kétirányú adatkommunikációt megvalósítani. Képi vizsgálatkérések esetén a képtároló és archiváló rendszerben tárolt (PACS) DICOM szabvány szerinti álló és mozgóképet lehessen egy direkt URL-el megcímezni és a rendszerből való kilépés nélkül egy külön ablakban megjeleníteni vagy egy ingyenes megjelenítő szoftverrel vagy az Megrendelőnél erre a célra alkalmazott speciális képmegjelenítő szoftverrel. Amennyiben a képi vizsgálatkérések közül megtekintésére kijelölt képek (álló és vagy mozgó) már archívumban vannak a HIS rendszernek alkalmasnak kell lennie az archívumból történő visszatöltés automatikus elindítására is a megtekintő jóváhagyása után Labor kommunikációval kapcsolatos alapvető elvárások A következő táblázatban összefoglaljuk a labor kommunikációval kapcsolatos alapvető elvárásokat. Az anyag mellékletében összefoglaljuk az ezen moduloktól elvárt minimálisan funkcionalitást. C C C C Az egészségügyi intézmény szakmai igényeknek, az Orvosi Laboratóriumi Vizsgálatok Szakmai Kollégiuma előírásainak és a laboratórium struktúrájának megfelelő kérőlapok legyenek kialakíthatók a rendszerben. Az egészségügyi intézmény szabadon definiálhasson kéréscsoportokat működési egységenként. 125 A kéréscsoport feladásakor ne legyen kötelező a csoport minden elemét megrendelni. Lehessen annak megrendelendő elemeit szabadon kiválasztani. Legyen mód egy darab vizsgálat feladására is. Legyen mód a kéréscsoport kiegészítésére is. A rendszer legyen felkészítve különböző típusú és rendszerű vonalkódok használatára a 123 Az űrlapokkal kapcsolatos elvárások ezen anyag részét képezik. 124 A felhasználó tudjon az adatmodellben létrehozni új kulcs érték párokat melyeket elhelyezhet az űrlapon illetve a nyomtatáson. 125 Pl: osztályonként, nővérpultonként, ambulanciánként, stb. Összeállította a GYEMSZI szakértői munkacsoportja 47

52 minta egyedi azonosításához (vonalkód nyomtatás, címke felhelyezés, vonalkód és minta összerendelés, minta érkeztetés, adatbevitel vonalkód olvasóval). C A rendszer automatikusan naplózza a kéréshez tartozó kiegészítő adatokat (kérés dátuma, OENO kód, megrendelő orvos, berögzítő személy, stb.) C Legyen mód a labor átvétel előtt a kérés törlésére. C Legyen mód a már feladott rendeléshez kapcsolódó utánrendelésre. C A kéréseket lehessen priorizálni (Normál, Sürgős) Legyen mód a kéréscsoportot plusz kérésekkel kiegészíteni a labor részéről amennyiben az elvégzett vizsgálatok eredményeként a szakma szabályai szerint C kiegészítő vizsgálatok indokoltak. A labor által kért vizsgálatok az eredeti kérés eredményeivel együtt (ne új rendelésszámon) kerüljenek vissza a kérő egészségügyi alkalmazásba. C Speciális szakmaspecifikus kérések kezelése, megjelenítése és nyomtatása (pl: protrombin lista). C A kérésekhez társíthatók legyenek a mintavételi edények. C Az osztályos vérvételi munkalistán és a labor számára készülő anyagátvételi listán kerüljön feltüntetésre a mintavételi edény típusa. C Egyes vizsgálatkérések megrendelését lehessen jogosultsághoz (pl. személyhez, végzettséghez, stb. ) kötni. Minden vizsgálatnál lehessen beállítani figyelést, amely figyelmeztetést küld akkor, ha C egy vizsgálatot egy határnap előtt újra kíván a felhasználó megrendelni. (A határnapot egészségügyi intézmény szabadon tudja definiálni). C Lehessen mátrix és laser nyomtatóval is mintavételi listát nyomtatni, amely egyben anyag átadás-átvételi kísérő listaként is funkcionál. C A kérés és a validált eredmény automatikusan töltődjön át a rendszerek között (egészségügyi intézményi rendszer - Labor). C Legyen mód vizsgálatokat előre megrendelni. C A finanszírozási adatok automatikusan kerüljenek át a labor rendszerből az egészségügyi intézményi rendszerbe. C Legyen mód a labor vizsgálatok eredményét a páciens dokumentumaiba beemelni 126. C A vizsgálatok eredményének beszúrása legyen automatizálható (pl. tevékenységhez köthető, funkcióhoz köthető, stb.) C A visszaérkezett labor leleteket lehessen akár többször is mátrix és laser nyomtatón is kinyomtatni. C Legyen mód egy páciens egyes vizsgálati elemeinek idősoros nyomtatására (esetleg grafikus megjelenítésére). C Lehessen összesítőt nyomtatni az osztály adott időszakra vonatkoztatott megrendeléseiről vizsgálatonként, beküldő orvosra és szervezetre bontva is. C Legyen mód egyes vizsgálatok elvégzését ütemezni. (pl: ha TSH csak 2 hetente kerül elvégzésre) A labor eredményekkel együtt kerüljön át a labor programból az egészségügyi C intézményi rendszerbe az adott betegnek (kor, nem) megfelelő referencia tartomány. Legyen lehetőség a kóros eredmények figyelemfelkeltő jelölésére. (pl.*) C Az egészségügyi intézményi rendszerbe átkerült labor leleten jelenjen meg a leletet validáló személy neve, beosztása. 126 Részleteket a dokumentumszerkesztésnél Összeállította a GYEMSZI szakértői munkacsoportja 48

53 C C C C C Megfelelő tagolással lehessen megjeleníteni a több frakciós vizsgálatok eredményeit. Minden vizsgálati eredménynek lehessen számszerű és szöveges eredménye is. Külső labor eredményeit manuálisan is lehessen a rendszerbe rögzíteni. Legyen mód összehasonlító és összegző listák készítésére a kért és elvégzett vizsgálatokról. A megajánlott rendszer rendelkezzen külső labor illesztéséhez kidolgozott szabványos illesztési felülettel Dokumentum kezelés (szerkesztés és nyomtatás) A következő táblázatban összefoglaljuk az egészségügyi dokumentum kezeléssel és kommunikációval kapcsolatos alapvető elvárásokat. Az anyag mellékletében (4.2.7 fejezet) összefoglaljuk az ezen modultól elvárt minimálisan funkcionalitást. Az egészségügyi informatikai rendszer tegye lehetővé, hogy bármely egészségügyi C A dokumentum szerkesztő szoftver az irodai alkalmazások piacán megszokott grafikus kezelői felülettel rendelkezzen. C A dokumentum szerkesztő ablak legyen átméretezhető annak érdekében, hogy jól áttekinthető legyen szerkesztés közben a dokumentum. C Az egészségügyi informatikai rendszer minden modulja egységes szövegszerkesztőt használjon dokumentumok szerkesztésére. C dokumentumhoz, szöveges megjegyzést lehessen fűzni. Az egészségügyi informatikai rendszerben a szakma szabályai szerint megszokott C bekezdések legyenek szabadon kialakíthatók (anamnézis, státusz, stb.) a rendszerben. Tetszés szerintiszámú új bekezdést lehessen definiálni. C A bekezdések kívánt sorrendben történő megjelenítésével szabadon definiálható legyen egy-egy szakterület lefedő dokumentumok összessége. C A dokumentum mintákat lehessen kötni intézethez, osztályhoz, részleghez, ambulanciához, orvoshoz. C A nyomtatási kép összeállítása szabadon definiálható legyen (olyan bekezdések és C űrlapok kerüljenek nyomtatásra, amit a felhasználó definiál). A nyomtatandó dokumentumot lehessen kétoldalasan nyomtatni és megadható legyen a példányszám. C-11- A megszerkesztett dokumentumok verzió kezelése legyen a rendszerben megoldva. A dokumentumok minden módosított verzióját tárolni kell. C C C C A megszerkesztett dokumentumok nyomtatási verzió kezelése legyen a rendszerben megoldva. A dokumentumok minden nyomtatott egyedi azonosítóval kell ellátni és minden verzióját tárolni kell. A dokumentum szerkesztésével kapcsolatos jogosultságok legyenek személyhez kötötten beállíthatók (minimális elvárt jogok: olvasás, új dokumentum létrehozása, módosítás, jóváhagyás, nyomtatás, törlés). A dokumentum szerkesztésével kapcsolatos események legyenek követhetők, verziózottak. Dokumentumszerkesztés közben a pácienssel kapcsolatos a rendszerben tárolt dokumentumok, képek, leletek legyenek megtekinthetők (zárójelentés, leletek, 127 EuroRec: EU EuroRec: EU Összeállította a GYEMSZI szakértői munkacsoportja 49

54 C C C szakvélemény, stb.). A megtekintés során, egyszerű módon legyen lehetőség a megtekintett szövegrészek és képek átemelésére. Legyen mód a rendszerben tárolt leletek és eredmények automatikus, de rendszerezett módon történő csoportos beemelésére 129. A leleteket az egészségügyi intézménnyel egyeztetett módon kell tudni a dokumentumokba beemelni. Legyen mód a rendszerben tárolt eredmények táblázatos módon történő megjelenítésére. Legyen mód lelettípusonként különböző leletbeemelési módot kiválasztani. A diagnosztikus munkahelyek vizsgálati eredményeit diagnosztikák szerinti C csoportosításban (időrendi sorrendben) lehessen beemelni a szerkesztett dokumentumba). C-11- Legyen mód a dokumentált gyógyszeres terápia részletes és hatóanyag szerinti leírására és a dokumentációba történő automatikus beemelésre. C A rendszerből kinyomtatandó dokumentumokban lehessen grafikus elemet 131 is elhelyezni. 132 Lehessen elhelyezni olyan rajzokat, amelyeken színezni vagy jelölni lehet a C dokumentumból történő kilépés nélkül. Ezek a rajzok kerüljenek a dokumentumhoz kötötten verzióval ellátva tárolásra. C A jogszabályok által előírt dokumentumokat és a jelenleg használt dokumentumokat lehessen létrehozni. 133 C A létrehozott elektronikus dokumentumok legyenek validálhatók. C A dokumentum szerkesztés legyen szöveges makrók definiálásával segítve. C A makrók különböző csoportjai legyenek képezhetők (intézeti, osztályos és orvosonként egyedi). C Makrókat az intézet megfelelő jogosultságú (jellemzően adminisztrátor) felhasználói maguk is tudjanak létrehozni. C A makrókat egy rövid névvel vagy más egyéb egyszerű módon lehessen a szerkesztés közben beilleszteni. C A rendszerben legyen lehetőség statikus és dinamikus űrlapok kialakítására134. Bármilyen szabványosan illesztett nyomtatón ki lehessen nyomtatni a dokumentumot. C Nyomtatáskor lehessen választani az alapértelmezett és egyéb alternatív nyomtatók között. C Nyomtatás előtt lehessen a kész dokumentumot megtekinteni és módosítani. C Nyomtatás előtt lehessen a kész dokumentumot megtekinteni (nyomtatási kép). C A megajánlott rendszer legyen felkészítve az egészségügyben használatos szokásos 135 és speciális nyomtatásra 136. C A nyomtatási funckó legyen rugalmas papírméret, nyomtatási terület beállíthatósága tekintetében pl: legyen mód nyomdai úton előre nyomtatott fejléces 129 pl. az összes kémiai labor leletet lehessen vizsgálat típusonként dátum szerint csoportosan emelkedő sorrendbe beemelni 130 EuroRec: EU A beillesztett grafikus elem felbontása meghatározza, hogy milyen felbontású és technikájú nyomtató szükséges a beillesztett elem megfelelő minőségű kinyomtatásához. 132 pl: fejlécben embléma, ultrahangos kép, rajz, stb. 133 beutalók, kérőlapok, igazolások, nyilatkozatok, stb 134 Az űrlapokkal kapcsolatos elvárások ezen anyag részét képezik. 135 leporelló, A4, A5 136 Új és régi recept,egyedi etikett, csuklópánt, karton nyomtatás, CD lemez feliratozás Összeállította a GYEMSZI szakértői munkacsoportja 50

55 C C C C C papírra nyomtatni. A dokumentumokat lehessen file-ba nyomtatni. A dokumentumokhoz beállítható legyen, hogy mikor tekintjük őket véglegesnek. A végleges dokumentumokat lehessen egy erre a célra kialakított tárházba (repositoryba) exportálni. Az exportálás szerkezetét lehessen beállítani. Az exportált repozitoriban arra jogosultsággal rendelkező személyek tudjanak keresni és nyomtatni. A repository-ban a dokumentumhoz csatolva kerüljenek exportálásra (pl: HL7 formátomban) a dokumentum keletkezéséhez kapcsolódó, valamint az ellátási adatok is Statikus és dinamikus űrlapok A statikus űrlapok és dinamikus űrlapok használatával az eddig papír alapon rögzített űrlap adatok elektronikus úton történő előállítását, kinyomtatását, mentését és az űrlapokon rögzített információk adatbázisba kerülését kívánjuk megvalósítani. Az űrlapokat önálló dokumentumokként is lehessen használni (dokumentum C típusokhoz rendelni vagy dokumentumokba beágyazni) és tárolni. Előre meghatározott módon, már adatbázisban tárolt adatok automatikusan C megjeleníthetők legyenek egy új űrlap szerkesztésének kezdetekor. C Az űrlapok egyes előre meghatározott mezőit lehessen default értékkel feltölteni. C Az űrlapok mezőihez lenyíló menüs választásban kódszótárakat lehessen rögzíteni. Az űrlapokra minden olyan adat felhelyezhető legyen, amely az egészségügyi C adatbázisban szerepel (Adat bekérés, A rendszerben tárolt eredmény megjelenítés). Az adatlap kitöltése során bevitt adatok felhasználásával előre definiált matematikai C képlet (ek) alapján számítási műveletek végződjenek el (pl. testfelszín számítás). A számított értéket tartalmazó mezőben a számításban résztvevő adatok kitöltése után C azonnal jelenjen meg a számított érték. A képernyőn el kell helyezni egy számol gombot melynek segítségével a számolást C újra el lehet végezni. Az űrlap előre definiált mezői, ha egy meghatározott értéket vesznek fel abban az C esetben automatikusan kerüljön meghívásra egy másik űrlap (pl: fertőző beteg bejelentése) Lehessen elhelyezni olyan rajzokat, amelyeken színezni vagy jelölni lehet az űrlapból C történő kilépés nélkül (pl. ápolási lapon a decubitusok helyét). Ezek a rajzok kerüljenek a dokumentumhoz kötötten verzióval ellátva tárolásra. C Az űrlapba lehessen képet beemelni. Az űrlapszerkesztés közben (kilépés nélkül) legyenek elérhetők és megjeleníthetők az intézeti PACS rendszerben tárolt álló és mozgóképek. Ez a szolgáltatás feltételezi egy C DICOM konverter vagy egy gateway szolgáltatást nyújtását, lehetővé téve ezáltal licenszdíj nélküli megtekintő használatát. Az informatikai szállító feladata a megvalósítás kezdeti fázisában a szervezeti működési struktúrában szereplő összes egység statikus és dinamikus űrlap igényét C felmérni. A felmérés során kapott eredmények alapján az informatikai szállító feladata az adatbázis bővítés elkészítése és a szükséges űrlapok kialakítása. Összeállította a GYEMSZI szakértői munkacsoportja 51

56 Recept A recept írás az egészségügyi alkalmazások sajátossága. A recept író szoftvereket auditáltatni kell a jelenleg érvényes törvények értelmében. A jelenlegi törvényi előírások ki fognak bővülni az e-recept kialakításával kapcsolatba. A recept író szoftverek újbóli auditja szükséges. C-13- A receptíró szoftver megajánlott verziója rendelkezzen a törvény által előírt szervezet auditjával. Lehessen a jogszabályi előírásoknak megfelelő receptet nyomtatni (formai és tartalmi C megfelelőség, extra vonalkód, stb.). C A szoftver által használt gyógyszertörzs frissítési technológiája és folyamata biztosítsa az OEP által közzétett gyógyszertörzzsel való tartalmi egyezőséget. C A szoftver által használt gyógyszertörzs frissítési úgy legyen megvalósítva, hogy a gyógyszertörzs frissítéséhez ne kelljen a HIS rendszerrel leállni. C Recept készítés közben egyértelműen jelezni kell a felhasználónak a képernyőn amennyiben a rendszerben lévő gyógyszertörzs lejárt. C Az Ajánlattevő feladata a mindenkor aktuális és hatályos gyógyszer adatbázis határidőre történő beimportálása a rendszerbe. C A szoftver a megszokott színek alkalmazásával segítse a helyes gyógyszerválasztást C A rendszer kezeljen minden jogcím szerinti gyógyszert (normatív, emelt indikációhoz kötött, kiemelt indikációhoz kötött, stb.). C A különböző betegség csoportokhoz tartozó referencia készítmények az előírás szerint jelölve legyenek a rendszerben C A recept készítő program tudjon kezelni magisztrális készítményeket és gyógyászati segédeszközöket is. C Lehessen az Ajánlatkérőre jellemző specifikus magisztrális készítményeket rögzíteni. A kitöltött illetve a kinyomtatott receptek szakorvosi javaslatok és azok tartalmi elemei C (név, adagolás, stb.) verziózva, egyedi azonosítóval ellátva reprodukálható, másolható módon tárolódjanak el a rendszerben. C-13- A receptírás legyen sablonokkal támogatott C-13- A receptíró sablonokat lehessen szerepkörhöz kötni C-13- A már felírt recepteket lehessen másolni C-13- A rendszer minden gyógyszer felírásnál jelezze a gyógyszer teljes árát és a páciens által fizetendő árat. C-13- Egy gyógyszer felírásánál a rendszer ellenőrizze és jelezze ki a felíró jogosultságát az adott szer felírására, a páciens jogosultságát a gyógyszer igénybevételére és az 137 EuroRec: EU EuroRec: EU EuroRec: EU EuroRec: EU EuroRec: EU EuroRec: EU EuroRec: EU Összeállította a GYEMSZI szakértői munkacsoportja 52

57 esetleges költség limiteket. C-13- A rendszer figyelmeztesse a felhasználót amennyiben a jogosultságokat, ill. a limiteket nem tudta ellenőrizni. A gyógyszer adatbázist meghatározott időközönként (jelenlegi jogszabályi előírás C szerint minimum havonta egyszer) frissíteni kell. Ha az adatbázis nincs frisstíve, akkor a felhasználó kapjon figyelmeztető jelzést erről. A rendszernek lehetővé kell tennie, hogy egy receptet szabványos kommunikáció során C elektronikus úton továbbítsanak az OEP e-recept központjába, vagy egy gyógyszer kiadhatóságát a központon keresztül elektronikusan visszavonják. C-13- A rendszernek lehetővé kell tennie, hogy egy receptre felírt gyógyszer kiadhatóságát a központon keresztül elektronikusan visszavonják. A rendszer a recept felírásakor figyelmeztesse a felhasználót a páciens előző C-13- egészségügyi rekordjaiban szereplő allergiából, intoleranciából, hatástalanságból, vagy nem kívánt reakciókból következtethető potenciális allergiás reakciókra, intoleranciára, hatástalanságra, vagy nem kívánt reakciókra. A rendszer automatikusan tegyen javaslatot a páciens-specifikus adagolásra, súly, kor, C nem, vese és májfunkciók alapján. A nem megfelelő adagolásról a rendszer figyelmeztesse a gyógyszer felíróját. C-13- A rendszer képes dokumentálni és tárolni az elektronikusan feírt vényeken történt változtatásokat illetve megszüntetéseket és azok okát Erőforrás ütemezés Az erőforrás ütemező rendszer az egészségügyi intézmény azon logisztikai eleme amelynek segítségével a szervezet működését optimalizálni lehet. Természetesen nem csak az intézet hanem a páciens érdekeit is szem előtt kell tartani az erőforrás ütemezés során. Az erőforrás ütemező fontos paramétere a törvényben is előírt web-es kétirányú kapcsolattartás. C C C Az erőforrás ütemező modul a HIS rendszerbe legyen integrálva (közös adatbázisok, kódszótárak). Legyen lehetőség az erőforrások feltérképezésére és az erőrrás ütemezéséhez szükséges adatok rögzítésére Minden olyan eszközre, vizsgálatra, konzíliumra, műtétre, diagnosztikai vizsgálatra, helységre illetve személyre lehessen kialakítani olyan házon belüli ütemező rendszert, amely lehetségessé teszi: A rendelkezésre álló kapacitások rögzítését A rendelkezésre álló erőforrás kvótázását Foglalást Foglalás törlését 152 Foglalás átütemezését 144 EuroRec: EU EuroRec: EU EuroRec: EU EuroRec: EU EuroRec: EU EuroRec: EU EuroRec: EU EuroRec: EU Foglalás törlése esetén automatikusan szabaduljon fel a lefoglalt időkeret Összeállította a GYEMSZI szakértői munkacsoportja 53

58 C C C C C C A foglalás átütemezése esetén a foglaláshoz kapcsolódó vizsgálatok és diagnosztikai kérések átütemezését Az erőforrás ütemező modulnak legyen webes kapcsolata (erőforrás kiajánlás, erőforráskérés fogadás, erőforrás kérés visszaigazolás, erőforrás kérés átütemezés). Az erőforrás ütemező rendelkezzen önálló jogosultság kezelő rendszerrel. Az erőforrás ütemező modul egy-egy erőforrásra vonatkozóan rendelkezzen több (minimum 3) kvótázási lehetőséggel. A kvótákat különböző jogosultsággal lehessen elérni. Az erőforrás ütemező modul rendelkezzen olyan outputtal, amely segítségével az adott erőforráshoz ütemezett adatok megjeleníthetők és kinyomtathatók 153. Az erőforrás ütemezőbe rögzített adatok alapján lehessen kiértesítő levelet és borítékot nyomtatni vagy t generálni. Az erőforrás ütemező modul rendelkezzen olyan képernyővel, amelynek segítségével az adott erőforrás egy-egy napjára, időszakára ütemezett betegek könnyedén 154 átütemezhetők legyenek egy másik időpontra Lekérdező modul A HIS rendszerben tárolt adatok tetszés szerinti feltétel rendszer szerinti lekérdezhetősége, elengedhetetlenül fontos az egészségügyi intézmény menedzsmentje, szakmai munkájának áttekintése, tudományos jellegű munkák adatgyűjtése érdekében. C C C C C C C C A megajánlott eszköz tegye lehetővé az Ajánlatkérő HIS adattárában szereplő információk adatbázison belül történő feldolgozását 155. Az adatok lekérdezése során ne legyen szükség az adatok mozgatására a különböző adattároló eszközök között. Legyen lehetőség a felhasználó számára időzített és ütemezett lekérdezések konfigurálására. Legyen lehetőség a lekérdezések grafikus megjelenítésére. A lekérdezés során előállt adatok szabványos adatformátumban 156 legyenek kimenthetők további feldolgozás céljából. Az Ajánlattevő alakítson ki az egészségügyi intézmény specifikus lekérdezéseit. A lekérdezést lehetővé kell tenni minden rendszerben tárolt adatra. Legyen lehetőség az időzített lekérdezési eredmények levélben történő továbbítására. 153 A megjelenítés és a nyomtatási képen megjelenő adatok legyenek felhasználó által szabadon változtathatók, paraméterezhetők. 154 A képernyő elhagyása nélkül felugró ablakok és egér segítségével lehessen az átütemezést elvégezni. 155 A hozzáférések számát az adott intézet határozza meg. A hardvereszközök méretezésénél az általános lekérdező modul teljesítményigényével is kalkulálni kell. 156 pl: txt, csv, xls Összeállította a GYEMSZI szakértői munkacsoportja 54

59 4.2.3 A betegfelvétel során elvárt minimális funkcionalitás Páciens adatkezeléssel kapcsolatos funkciók 1. Új beteg felvétel 2. Betegkapcsolatok megadása 3. Visszarendelés követése 4. Járó és fekvőbeteg adatok felvétele 5. Felvétel sztornózás 6. Páciens törzsadat bevitel 7. Paciens törzsadat lista 8. Áthelyezés 9. Távozás 10. Távozás sztornózás 11. Páciens törzsállományának a törlése 12. Más intézetbe való áthelyezés, átvétel 13. Áthelyezés sztornózás 14. Osztályosból ambulánssá minősítés 15. Ambulánsból osztályossá minősítés 16. Előfelvétel (tervezett befekvéseknél használandó funkció. A gyorsfelvétel egy fajtája) 17. Előjegyzésből történő felvétel 18. Nővérpult betegnyilvántartás 19. Mivel intézetünk újszülöttek gyógyításával is foglalkozik ezért legyen mód TAJ szám nélkül is felvételre majd az adatok pótlására. 20. Osztályos betegkeresés 21. Betegrekordok összefűzése (duplán felvett betegek adatainak összefűzése) 22. Betegek intézeten belüli mozgásának követése (felvétel, osztályos áthelyezés, költöztetés (kórterem váltás) 23. Férőhelyek megjelenítése. 24. A betegfelvételi rendszer rendelkezzen ágytérképpel. 25. Beteg felvilágosítás 26. Adatok titkosítása a páciens kérésére Előjegyzés, ellátás ütemezés 27. Előjegyzés kezelésre (szakrendelésenként és orvosonkénti bontásban) 28. Várólista kezelés 29. Betegfogadási lista kezelés Biztosítás, finanszírozás 30. Biztosítási adatok bevitele ellenőrzése 31. Jogviszony és jogosultság on-line ellenőrzési lehetőség 32. Finanszírozási adatok bevitelének lehetősége és a bevitel ellenőrzése Dokumentumszerkesztés 33. Járó és fekvőbetegekkel kapcsolatos dokumentumok nyomtatása (beleegyező Összeállította a GYEMSZI szakértői munkacsoportja 55

60 nyilatkozatok, kórlap, adatlap, E-adatlap, stb.) 34. Adatlap nyomtatás 35. Patológiai adatlap kitöltés és nyomtatása 36. Várólistával és betegfogadási listával kapcsolatos nyomtatási feladatok 37. Beteg behívással kapcsolatos feladatok 38. Speciális nyomtatványok elkészítése (nyomtatás tasakra, etikett nyomtatás, stb.) 39. Munkalisták nyomtatása. Pl: Bennfekvő betegek listája Nővérpult betegnyilvántartás Gyorsfelvételek listája Nem ellenőrzött TAJ lista, stb. 40. Ellenőrző és hibalisták nyomtatása (pl: betegek összefűzésekhez, ambuláns napló) 41. Legyen mód minden dokumentumot file-ba is nyomtatni 42. A megajánlott rendszernek rendelkeznie kell portai funkcióval. A portai funkció segítségével információt kell tudni szolgáltatni a Intézetben benn fekvő és a nemrég távozott betegekről amennyiben a páciens az információ megadását nem tiltotta meg A Járóbeteg szakellátás során elvárt minimális funkcionalitás Páciens adatkezeléssel kapcsolatos alapvető funkciók 1. Rendelésenkénti napi behívási lista kezelése (listára vétel, listáról levétel, behívás, törlés a listáról, visszatétel a listára, stb.) 2. Felvétel 3. Gyorsfelvétel 4. Leletezés 5. Továbbküldés saját és más intézetbe 6. Diagnózis bevitel 7. Beavatkozás bevitel 8. Különböző típusú recept nyomtatás lehetősége (általános, közgyógy, EU, gyógyászati segédeszköz, stb.) 9. Naprakész gyógyszer adatbázis megléte a rendszerben, kölcsönhatás figyelés 10. Megrendelés feladás (diagnosztika, vizsgálatkérés, stb.) 11. Ambuláns lap és ambuláns napló kezelés 12. On-line beutalók, konzílium és vizsgálatkérések generálása 13. On-line leletfogadás és megtekintés 14. Járóbeteg fekvőbe átminősítés Előjegyzés, ellátás ütemezés 15. Előjegyzés kezelésre (szakrendelésenként és orvosonkénti bontásban) a. Előjegyzések felvitele, módosítása, törlése b. Előjegyzés adatainak nyomtatása 16. Betegfogadási lista kezelés a. Felvétel b. Törlés c. Módosítás d. Átütemezés Összeállította a GYEMSZI szakértői munkacsoportja 56

61 e. Listák nyomtatása 17. WEB-es kommunikáció a törvény szerint Biztosítás, finanszírozás 18. Biztosítási adatok bevitele ellenőrzése 19. Jogviszony és jogosultság on-line ellenőrzési lehetőség 20. Betegfogadási és várólisták adatküldő állományának előállítása 21. Finanszírozással kapcsolatos tevékenységek a. Finanszírozási adatok bevitele b. Biztosítási adatok rögzítése és ellenőrzése c. Fekvőből visszarendelésnél határnap figyelés d. Lezáratlan esetekről hibalista e. Kikódolatlan esetekről hibalista f. TAJ ellenőrzés g. TAJ ellenőrzés hiányáról hibalista Ambuláns dokumentumok kezelése (szerkesztés és nyomtatás) 22. Ambuláns lelet készítés és nyomtatás a szakma szabályai szerinti tagolás szerint 23. Ambuláns betegforgalmi napló 24. Várólistával és betegfogadási listával kapcsolatos nyomtatási feladatok 25. Adatlap nyomtartás 26. Dokumentumok nyomtatása (beleegyező nyilatkozatok, lelet, beutaló, stb.) 27. Speciális nyomtatványok elkészítése (recept, etikett nyomtatás, stb.) 28. Munkalista nyomtatás 29. Ellenőrző és hibalisták nyomtatása (pl: ambuláns napló, előjegyzési adatok, elszámolási listák, stb.) 30. Lista megtekintés nyomtatás előtt PACS illesztés : 31. Az intézeti PACS rendszerben tárolt képek legyenek elérhetők a szakrendelői programból. 32. A PACS rendszerben tárolt képek leletbe történő illesztésére és nyomtatására legyen engedélyezett A fekvőbeteg szakellátás során elvárt minimális funkcionalitás Páciens adatkezeléssel kapcsolatos alapvető funkciók : 1. A leggyakrabban használt fekvőbeteg adminisztrációs funkciókat lehessen (felhasználó típusonként esetleg felhasználónként) csoportba szervezni. 2. Legyen mód a beteggel kapcsolatos mozgások osztályon történő rögzítésére (pl: áthelyezés). 3. A fekvőbeteg adminisztrációs rendszer kezelje az egészségügyben előforduló betegmozgásokat Összeállította a GYEMSZI szakértői munkacsoportja 57

62 felvétel, felvétel törlése, átminősítés fekvőből járóba, áthelyezés intézeten belül, áthelyezés más intézetbe, visszavétel már intézetből, elbocsátás, elbocsátás törlése, távoztatás, távozás törlése, szabadság, 4. Újszülöttek esetén legyen mód TAJ szám nélkül is felvételre majd az adatok pótlására. 5. Tetszőleges számú statikus és dinamikus űrlapot lehessen az osztályok adatbeviteli elvárásának megfelelően definiálni. 6. Sürgős esetekben biztosítani kell a gyors betegfelvételt. Ilyen esetben legyen mód TAJ szám nélkül is az ellátáshoz szükséges megrendelés elektronikus megrendelésére (labort, diagnosztika, konzílium, műtétet, stb.). 7. Személyhez köthető orvosi adatok rögzítésére legyen lehetőség (pl: rizikófaktorok, allergia, gyógyszerérzékenység, stb.) 8. Elektronikus és szükség esetén papíros labor-kérés és automatikus eredmény fogadás kerüljön megvalósításra. 9. Elektronikus és papíros konzílium-kérés és eredmény fogadás 10. Ápolási tevékenység rögzíthetősége 11. Elektronikus gyógyszerrendelés 12. Szűkített BNO és OENO törzs definiálhatósága csoportra (pl. osztály) és orvosra. 13. Beavatkozás csoportok szűkítése osztályra 14. Legyen mód az esetfinanszírozott eszközök rögzítésére 15. Legyen mód az élelmezési adatok rögzítésére 16. Napi létszám jelentés (új, áthelyezett, távozott, meghalt páciensek listája) Felvételtervezés, várólista kezelés 17. Felvételtervezés a. Tervezett felvétel rögzítése, módosítása, törlése, átütemezése b. Tervezett felvétel adatainak nyomtatása különböző szempontok szerint 18. Várólista kezelés a. Felvétel b. Törlés c. Módosítás d. Átütemezés e. Listák nyomtatása f. Web-es kommunikáció a törvény szerint Biztosítás, finanszírozás 19.Biztosítási adatok bevitele ellenőrzése 20. Finanszírozással kapcsolatos tevékenységek: a. Finanszírozási adatok bevitele b. Biztosítási adatok rögzítése és on-line ellenőrzési lehetősége c. Fekvőből visszarendelésnél határnap figyelés d. Lezáratlan esetekről hibalista e. Kikódolatlan esetekről hibalista Összeállította a GYEMSZI szakértői munkacsoportja 58

63 f. TAJ ellenőrzés g. TAJ ellenőrzés hiányáról hibalista h. Havi tetszőleges számú HBCS elő besorolás futtatásának biztosítása i. HBCS optimalizálás j. Határnap figyelés. k. Garanciális idő figyelés Fekvőbeteg dokumentumok kezelése (szerkesztés és nyomtatás) 21. Az Ajánlatkérő elvárásai szerint tudjon a rendszerbe új dokumentumokat, statikus és dinamikus űrlapokat szerkeszteni, beilleszteni, funkcióhoz csatolni. 22. A dokumentumot lehessen funkcióhoz esetleg munkaállomáshoz kapcsolni. 23. A jelenleg használt dokumentumok elkészítése az Ajánlattévő feladata (pl:kórlap, beleegyező nyilatkozatok, zárójelentés, kérőlapok, diagnosztikai kérések, konzílium kérések, vér rendelés, a visszaérkezett eredmények listái, stb.). PACS illesztés: 24. Az intézeti PACS rendszerben tárolt képek legyenek elérhetők a szakrendelői programból. 25. A PACS rendszerben tárolt képek leletbe történő illesztésére és nyomtatására legyen engedélyezet Az elektronikus kórlaptól és lázlaptól elvárt minimális funkcionalitás 1. Az elektronikus kórlap és lázlap elkészítésének kiindulója a jelenlegi meglévő papír alapú dokumentáció legyen. 2. Az elektronikus kórlap és lázlap szervesen illeszkedjen az ápolási dokumentumokhoz. 3. Az elektronikus kórlapnak és lázlapnak legyen kapcsolódása (automatikus átemelési lehetősége) az ápolási dokumentáció azon részeivel ahol az elrendelések találhatók (pl. gyógyszer rendelés, vizsgálatok elrendelése, terápia beállítása, stb.) 4. A Terápiás feladatok elrendelésével kapcsolatos adatok rögzíthetők legyenek Elrendelő neve, beosztása Az elrendelt feladat neve és kódja Gyakoriság, időpont Dózis Beadás módja Intervallum Felfüggesztés, folytatás, csere, elmaradás Indoklás Az elrendelés validálása 5. Vizsgálat és konzílium kérésekkel kapcsolatos adatok rögzíthetők legyenek Elrendelő neve, beosztása Az elrendelt kérés neve és kódja Időpont Összeállította a GYEMSZI szakértői munkacsoportja 59

64 A mintavétellel kapcsolatos információk Szállítás módja Kérés törlése, indoklás Az elrendelés validálása 6. Dokumentum típusonként illetve betegenként legyen beállítható a kötelezően kitöltendő mezők alapértelmezett értéke 7. Az Ajánlatkérő maga tudjon új elektronikus kórlapot lázlapot vagy terápiás lapot létrehozni. 8. Az Ajánlatkérő maga tudja a felmerülő változtatási igényeket az elektronikus dokumentumon elvégezni. 9. Az elektronikus kórlapnak és lázlapnak legyen kapcsolódása az élelmezési rendszerrel (pl. diéta elrendelés legyen átemelhető az élelmezési rendszerbe). 10. Az elektronikus kórlap és lázlap rendelkezzen betegre szóló gyógyszerelési és gyógyszer rendelési funkcióval (az elrendelés alapján készüljön betegre és osztályra szóló gyógyszer rendelés összesítő mely formájában úgy nézzen ki, hogy validálás után elektronikus megrendelésként is szolgálhasson a gyógyszertár felé). 11. A dokumentációk vezetésének befejezésével legyen mód elektronikus validálásra. 12. Az elektronikus kórlap modulban vezetett adatok alapján legyen mód ad az egyedi lekérdezésekre, mely segít az elvárásokkal szembeni megfelelésben Az ápolási dokumentációtól elvárt minimális funkcionalitás Az ápolási dokumentáció készítését az CLIV. Egészségügyi Törvény kötelezővé tette, része az egészségügyi dokumentációnak. Minden betegnek van ápolási dokumentációja, amit az ápolók, asszisztensek naponta többször, vagy műszakváltáshoz vezetnek, bejegyzik a beteg ápolási eseményeinek fontosabb mozzanatait. Összegzi a beteg állapotára, az ápolásra és a beteg reakciójának értékelésére vonatkozó lényeges megfigyeléseit. A szakmai profil meghatározza a dokumentáció vezetésének számát, részletességét, tartalmát. Eltérő a dokumentáció vezetése intenzív területeken, ill. hotel részlegeken. Tegye lehetővé a beteggel kapcsolatos korábbi ápolási tevékenységek hatékonyságának eredményességét, azok összevetését, a kapott információk alapján lehessen dönteni a további ellátásról. 1. Tetszőleges ápolási terv készítése betegségcsoportonként. Az elektronikus ápolási dokumentáció elkészítésének kiindulója a jelenlegi meglévő papír alapú dokumentáció legyen (az ápolási dokumentáció része: Ápolási zárójelentés, Decubitus lap, Transzfúzió követő lap, Diabetes lap, Gyógytorna lap, Folyadék lap, stb.) 2. Dokumentum típusonként illetve betegenként legyen beállítható a kötelezően kitöltendő mezők default értéke) 3. Az Ajánlatkérő maga tudjon új elektronikus ápolási lapot és ápolási tervet (ápolási diagnózis, ápolási célkitűzés, ápolási tevékenység, értékelés) létrehozni. 4. Az Ajánlatkérő maga tudja a felmerülő változtatási igényeket az elektronikus ápolási lapon elvégezni. Összeállította a GYEMSZI szakértői munkacsoportja 60

65 5. Az elektronikus ápolási dokumentációnak legyen kapcsolódása (automatikus átemelési lehetősége) az orvosi dokumentáció azon részeivel ahol az elrendelések találhatók (pl. gyógyszeres terápia elrendelése, vizsgálatok elrendelése, terápia beállítása, stb.) 6. Az elektronikus ápolási dokumentációnak legyen kapcsolódása az élelmezési rendszerrel (pl. diéta elrendelés átemelési lehetősége). 7. Az elektronikus ápolási dokumentáció rendelkezzen betegre szóló gyógyszerelési és gyógyszer rendelési funkcióval (az elrendelés alapján készüljön betegre és osztályra szóló gyógyszer rendelés összesítő mely formájában úgy nézzen ki, hogy validálás után elektronikus megrendelésként is szolgálhasson a gyógyszertár felé). 8. A dokumentáció vezetésének befejezésével legyen mód elektronikus validálásra. 9. Az elektronikus ápolási dokumentáció modulban vezetett adatok alapján legyen mód az egyedi lekérdezésekre Összeállította a GYEMSZI szakértői munkacsoportja 61

66 4.3 Intézményi működést támogató informatikai rendszerek általános és specifikus követelményei Az egészségügyi, elsősorban a fekvő- és járóbetegellátó intézményeknél a nem (csak) egészségügyi ellátás specifikus, intézményi működést támogató informatikai rendszerek bevezetésénél, az alábbi követelménylistát javasoljuk alkalmazni, amely elsősorban az adott informatikai megoldás szállítójára, annak termékének és szolgáltatásának funkcionálisan és informatikailag elvárt követelményeire vonatkozik: Intézményi működést támogató informatikai rendszerek általános követelményei (valamennyi ilyen típusú megoldásnál) D Magyar szabályozási környezetnek megfelelő működés. D Adatvédelem maximális szintű biztosítása (lásd 8.2. fejezet) D A rendszer rendelkezzen működéshez szükséges strukturált jogosultságkezeléssel. D A rendszer az intézményekkel működő más informatikai rendszerekkel kompatibilis D Központi címtárak (ActiveDirectory), alkalmazása D Egységes jogosultság kezelő központ alkalmazása, amely minden felhasználó számára felhőszerűen, redundánsan elérhető D A rendszer képes a felhasználók jogosultságával kapcsolatos ellenőrzések meghatározott időközönként való lefolytatására. D Felhasználók skálázhatósága. D Bővíthetőség, a későbbi igények rugalmas kielégítése. A rendszer / megoldás legyen integrált (kétirányú adatkommunikációra képes) az D intézménynél már megtalálható vagy egyidőben bevezetésre kerülő többi informatikai rendszerrel, alkalmazással. Az alkalmazások felhasználói interfészét az egyes alkalmazások esetében úgy kell D kialakítani, hogy azok biztosítsák az alkalmazás képernyők, oldalak elvárható sebességű, elérhetőségét az általánosan elterjedt, kereskedelmi forgalomban rendelkezésre álló szélessávú internet kapcsolatokon keresztül. D A rendszer használható felületeinek nyelve magyar legyen. D A rendszer adminisztrációs felületeinek nyelve és a szoftver dokumentációja magyar legyen. D Rendelkezésre áll a rendszerhez magyar nyelvű felhasználói dokumentáció. A rendszer valamennyi felhasználója részesüljön a megoldás szállítójától, vagy más D módon (pl. a TÁMOP projekt - lásd fejezet - keretein belül) képzésben, betanításban. D A bevezetendő alkalmazás szállítójának legyen működő referenciája az adott funkcionális területen. D A rendszer fejlesztője / szállítója biztosítson magyar nyelven elérhető terméktámogatást legalább 5 évig Intézményi működést támogató informatikai rendszerek specifikus követelményei (a releváns megoldásoknál) Összeállította a GYEMSZI szakértői munkacsoportja 62

67 Intézményi gazdálkodást támogató rendszerek követelményei: Pénzügyi-számviteli rendszerek A pénzügyi-számviteli rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő egyéb gazdasági rendszerekkel (különösen a beszerzési, készletgazdálkodási, logisztikai és a HR, bérszámfejtési megoldásokkal) integráltan: a számviteli-. ÁFA- és egyéb releváns törvények elvárásainak megfelelően folyamatosan kövesse az intézmény gazdasági- és pénzügyi eredményességét, valamint megfelelő könyvvezetést; folyamatosan aktuális állapotot mutasson az intézmény pénzügyi kötelezettségeiről és vevői követeléseiről, továbbá a rövid- és hosszabb távú likviditási tervek készítésével támogassa az intézmény pénzügyi stabilitását. segítse az eszközgazdálkodás optimalizálását, az intézmény tulajdonában lévő tárgyi eszközök értékelését; Segítse a pénzügyi-számviteli munkatársak munkáját, csökkentve a szükséges munkaerő ráfordítást; lehetővé tegye a pénzügyi és számviteli munkafolyamatok automatizálását, támogassa azok végrehajtását; fentiek révén segítse az intézmény működési hatékonyságának növekedését. D Főkönyvi analitika készítése. D Költségnemek és költséghelyek könyvelése. D Adóanalitikák és kimutatások készítése, ÁFA és egyéb adók kezelése. D Tárgyi eszközök, azok állományváltozásainak nyilvántartása. Szállítói és (amennyiben releváns intézményi, szervezeti, vállalati) vevői (ügyfél) D folyószámlák kezelése, nyilvántartása (iktatás, könyvelés, készítés). Beszámolók (pl. mérleg, eredménykimutatás) készítése negyedéves, féléves, éves D zárási lehetőségekkel. D Bankszámlakezelés. D Pénztárkezelés. D Tevékenység alapú költségelemzés, költségtervezés. D Központilag előírt költségvetési specifikációhoz való illeszkedésre való alkalmasság A pénzügyi- számviteli rendszer támogatja az államháztartás felé jelentési kötelezettséggel bíró operatív gazdálkodási folyamatait, tranzakcióit és biztosítja az D egészségügyi intézményeknél alkalmazott szakrendszerek által a pénzügyi-számviteli rendszer felé kezdeményezett pénzügyi/gazdasági tranzakciók elektronikus kezelését. A rendszer támogatja az egészségügyi szakrendszerekből továbbított adatok digitális D D aláírását. A rendszer támogatja az egészségügyi szakrendszerekből továbbított adatok naplózását és visszakereshetőségét. Beszerzési rendszerek A beszerzési rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő egyéb gazdasági rendszerekkel (különösen a készletgazdálkodási és pénzügyi-számviteli megoldásokkal) integráltan: segítse a beszerzési feladatokat ellátó munkatársak munkáját, csökkentve a szükséges munkaerő ráfordítást; lehetővé tegye a beszerzési munkafolyamatok automatizálását, támogassa azok Összeállította a GYEMSZI szakértői munkacsoportja 63

68 végrehajtását; a fentiek és a beszerzendő termékek és szolgáltatások árazásának optimalizálásával segítse az intézmény működési hatékonyságának növekedését. D Egészségügyi ellátásból érkező előrejelzések kezelése. D D D D D D Készletgazdálkodási adatok alapján a rendelési mennyiség optimalizálása. Ajánlatkérések támogatása. Beszerzési partnerek adatainak kezelése. Beszerzési partnerek termékeinek, szolgáltatásainak nyilvántartása. Beszerzési árlista kezelése (ügyfelenként, termékenként, tevékenységenként). Beszerzési kedvezmények (mennyiségi, időszaki, egyedi) kezelése. D Beszerzési partnerek szerződéseinek, kötelezettségeinek nyilvántartása. Készletgazdálkodási, logisztikai rendszerek A készletgazdálkodási-logisztikai rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő egyéb gazdasági rendszerekkel (különösen a beszerzési és pénzügyi-számviteli megoldásokkal), valamint az egészségügyi ellátást, szolgáltatást támogató megoldásokkal integráltan: segítse a készletgazdálkodási, logisztikai feladatokat ellátó munkatársak munkáját, csökkentve a szükséges munkaerő ráfordítást; lehetővé tegye készletgazdálkodási, logisztikai munkafolyamatok automatizálását, támogassa azok végrehajtását; fentiek révén segítse az intézmény működési hatékonyságának növekedését. D Anyagok, készletek mennyiségben, értékben történő nyilvántartása. D Készletgazdálkodás elemzése. D Minimális készlet, biztonsági készlet meghatározása, figyelése. D Készletszint figyelése, kezelése az egészségügyi ellátási rendszerből érkező adatok, előrejelzések alapján. D Raktárirányítás, több raktár kezelése. D Leltározás. D Selejtezés. D Visszárukezelés. D Gépjármű üzemeltetés támogatása (pl. menetlevelek kezelése). D Betegmozgatás támogatása. D Betegelhelyezés irányítása, kezelése (fekvőbeteg ellátó intézmények esetén). D Műtéti anyagfelhasználás optimalizálása (fekvőbeteg ellátó intézmények esetén). D Élelmezési, dietetikai intézményi folyamatok / feladatok támogatása (fekvőbeteg ellátó intézmények esetén). D Ebédjegy kezelés (amennyiben releváns az intézménynél) HR, bérszámfejtési rendszer A HR, bérszámfejtési (vagy munkaügyi) rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő egyéb gazdasági rendszerekkel (különösen a pénzügyi-számviteli megoldással) integráltan: segítse a HR osztály vagy a humánpolitikai feladatokat ellátó munkatárs munkáját, Összeállította a GYEMSZI szakértői munkacsoportja 64

69 csökkentve a szükséges munkaerő ráfordítást; lehetővé tegye a munkaügyi munkafolyamatok automatizálását, támogassa azok végrehajtását; fentiek révén segítse az intézmény működési hatékonyságának növekedését. D Személyzeti törzsadatok kezelése. D Képzettségek, képzések nyilvántartása és nyomon követése. D Munkaszerződések, munkaköri leírások nyilvántartása. Bérezéssel, fizetésékkel kapcsolatos nyilvántartás (alapbér, túlórapótlék, táppénz, D jutalom). D Munkaadói, cafeteria juttatások adminisztrálása. Időgazdálkodás menedzsment (ügyeletek, távollétek, helyettesítések, többletmunkák, D szabadságolások, teljesített munkaórák). Központi HR monitoring rendszer felé (amennyiben az is rendelkezik ilyen D kapcsolódási képességgel, vagyis nyitott lesz a közvetlen adatkommunikációra) interface kialakítása D-061 Beléptetési, dolgozói regisztrációs adatok kezelése. Ügyfélkapcsolati (CRM) rendszerek Az ügyfélkapcsolati (CRM) rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő egyéb gazdasági rendszerekkel (különösen a beszerzési megoldással), valamint a külső intézményi portállal (weblappal) integráltan: segítse a betegek időpontfoglalásával, az egészségügyi szolgáltatást igénybevevő szervezetekkel, vállalkozásokkal, az intézményi ügyfelekkel kapcsolatos feladatokat ellátó munkatárs munkáját, csökkentve a szükséges munkaerő ráfordítást; lehetővé tegye a külső szervezetek felé irányuló munkafolyamatok automatizálását, támogassa azok végrehajtását; javítsa az ügyfelek elégedettségét; fentiek révén segítse az intézmény működési hatékonyságának növelését. Egészségügyi szolgáltatást igénybevevő szervezetek nyilvántartása (személyek, D beosztások, szervezeti hierarchia). Ügyfélkezelés támogatása (kapcsolatfelvétel, előtörténet nem egészségügyi D vonatkozásban!). D Intézményi Call center vagy diszpécserközpont kezelése. D Intézményi Public Relations (PR) feladatok támogatása (rendezvények, meghívók). D Szállítók felé történő hibajelentések kezelése. D Reklamációkezelés Vezetői információs rendszerek (VIR) követelményei Döntéstámogató rendszerek A döntéstámogató rendszerek olyan szoftverek, szoftver-komponensek, informatikai megoldások, amelyek az intézménynél működő egyéb informatikai rendszerekhez kapcsolódással és / vagy külső adatforrások felhasználásával képesek elemezni és/vagy szimulálni egy vizsgált terület működését, úgy hogy a strukturált és kevésbé strukturált feladatok, a beépített döntési szabályok vizsgálatával, modellek kidolgozásával segítséget nyújtanak a vezetői döntéshez. Képes támogatni olyan komplex problémák megoldását, melyeket hagyományos D számítógépes megközelítéssel egyáltalán nem lehetne megoldani, vagy csak sokkal lassabban. Összeállította a GYEMSZI szakértői munkacsoportja 65

70 D A megoldás előre definiált és ad-hoc lekérdezések megtételét is lehetővé teszi. D Egyszerű lekérdezések elkészítésének, illetve testreszabásának támogatása. D Prezentációs felülettel rendelkezés. D Kimutatások felhasználóbarát, illetve vezetői igénynek megfelelő elkészítése. D A rendszer képes terv- és tényadatok összehasonlítására, elemzésére. D Vezetői döntéshozatalt megkönnyítő mutatószámok definiálása. D Modellek segítségével mennyiségi és minőségi analízis készítése. Központi egészségügyi rendszerekhez (pl. kapacitástérkép, amikor az létrejön és D működik) való kapcsolódással, más intézmények hasonló lekérdezéseinek összehasonlítása, elemzése. D Országos egészségmonitorozási és kapacitástérkép adatbázis közvetlen lekérdezési képessége (amikorra az létrejön) Kontrolling rendszerek A kontrolling rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő gazdasági rendszerekkel, valamint az egészségügyi ellátást, szolgáltatást támogató megoldásokkal integráltan: segítse a kontrolling, belső ellenőrzési feladatokat ellátó munkatársak vagy az intézmény vezetésének a munkáját, csökkentve a szükséges munkaerő ráfordítást; lehetővé tegye a releváns munkafolyamatok automatizálását, támogassa azok végrehajtását; megfelelően előkészítse a vezetői döntéshozatalt a következő időszakokra nézve; fentiek révén segítse az intézmény működési hatékonyságának növekedését. D Különböző adatbázisokból, funkcionális területekről kapott inputok feldolgozásának képessége. D A kapott beszámolók exportálása (mentése) tovább-felhasználható formátumokba (pl. xml). D Naprakész, folyamatos információk biztosítása. D Adatintegrációs, automatizált adatbetöltési funkciókkal rendelkezés. D Kimutatások felhasználóbarát, illetve vezetői igénynek megfelelő elkészítése. D A feldolgozott adatbázisok összehasonlítása (időbeli, terv-tény). D Különböző belső intézményi forrásból, funkcionális területről érkező adatok összevetése, elemzése Központi egészségügyi rendszerekhez (pl. kapacitástérkép, amikor az létrejön és D működik) való kapcsolódással, más intézmények hasonló adatainak összehasonlítása, elemzése. D Változtatási, hatékonyság növelési javaslatok definiálása a vizsgált funkcionális területre vonatkozóan Munkafolyamatokat támogató rendszerek követelményei Munkafolyamat irányító (workflow) rendszerek A munkafolyamat-irányítási (workflow) rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő gazdasági rendszerekkel, valamint az egészségügyi ellátást, szolgáltatást közvetlenül támogató megoldásokkal integráltan: végezze a munkafolyamatok automatizálását; segítse az intézményen belüli szervezeti egységek munkájának összehangolását. támogassa, hogy minden folyamat az előírt korlátokon belül, a költségek, a határidők és Összeállította a GYEMSZI szakértői munkacsoportja 66

71 egyéb paraméterek (pl. a betegellátás színvonalának emelése) betartásával valósuljon meg. segítse a vezetői áttekintést, a vezetői prioritások érvényesítését, optimalizálja a kockázatkezelést; fentiek révén közreműködjön az intézmény működési hatékonyságának növelésében. A rendszer tegye lehetővé a szervezeti folyamatok definiálását, támogatását, nyomon D követését. D Folyamatleltár, folyamattérkép, folyamatábra készítése. D Folyamatok, feladatok és erőforrások illesztése, osztályozása. Több funkcionális szervezeti egység és odatartozó alkalmazottak közötti D feladatkiosztás, feladatlista kezelése. Az egészségügyi ellátási tevékenységet érintő munkafázisok előre megadott feltételek D alapján történő szétosztása az alkalmazottak között. D Munkacsoportok, szerepkörök kialakítása. A munkafolyamatok vezérlésének beépített módon való támogatása (delegálás, D státuszkövetés). D Probléma nyomkövető rendszer (ticketing) használata. Elektronikus iratkezelési rendszerek Az elektronikus iratkezelési rendszer olyan informatikai megoldást jelent, amely segíti az intézmény működési hatékonyságának növekedését úgy, hogy alkalmas: az intézménynél keletkező, illetve oda bekerülő összes irat minden formájának nyilvántartására, homogén módon történő kezelésére; az elektronikus tartalmak tárolásával és a papír iratok digitalizálásával egy átfogó tudásbázis kialakítására. D Érkeztetés, iktatás, postázás. D Minden típusú és formájú irat azonos módon történő kezelése, nyilvántartása. D Elektronikus tárolási forma és digitalizálás biztosítása további egységes tárolással. Papír alapú dokumentumok elektronikus kezelési, tárolási lehetőségének D megteremtése. Iratok, ügyek hozzárendelése ügyfelekhez, ellátottakhoz, tranzakciókhoz, szervezeti D folyamatokhoz. Iratok és ügyek követése, keresése, elérése a meglévő integrált intézményi informatikai D rendszerből. D Az iratok teljes életciklusának követése a jogszabályoknak megfelelően. Csoportmunka rendszerek A csoportmunkát támogató rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely összehangolva és integráltan az egészségügyi ellátást, szolgáltatást közvetlenül támogató megoldásokkal, a munkafolyamat-irányítási rendszerrel (amennyiben az van a szervezetnél), valamint a belső (intranet) és külső intézményi (honlap) portálokkal: az intézményi belső munkafolyamatokat támogatja; a szervezeti felépítéséhez illeszkedő, a rendelkezésre álló adatkapcsolatokat felhasználva a lehetőségekhez képest bárhonnan elérhető; megfelelően kezeli a térbeli és az időbeli elhatárolódást jelentő kapcsolatokat; fentiek támogatása révén segíti az intézmény működési hatékonyságának növekedését. D Webes felhasználói felület támogatása. D Biztonságos távoli adatkapcsolat és levelezési lehetőség kiépítése. Összeállította a GYEMSZI szakértői munkacsoportja 67

72 D D D D D D D Webes oldalakon keresztüli kommunikáció lehetővé tétele. Webes fórumok kialakításának lehetősége. Szerepkörök kialakításának lehetősége, projektszerű munka támogatásának lehetősége. Feladatok kiosztásának lehetősége, feladatok megjelenítése naptárban, feladatok egymáshoz kapcsolása, feladatok nyomon követése. Csoportos naptárkezelés feladatokkal, mérföldkövekkel, eseményekkel. Jelenlét-érzékelés. Osztott információs bázis építésének lehetőségének megteremtése. D Valós idejű csoportmunka megteremtése elektronikus dokumentumokon. Valós idejű üzenetküldés (párbeszéd, csoportos üzenetkezelés) lehetőségének D biztosítása. D Hangátvitellel történő kommunikáció lehetővé tétele Intézményi portálok követelményei Intézményi intranet (belső portál) Az intézményi intranet (belső portál) olyan internet technológiát (tipikusan TCP/IP protokoll) használó belső információs hálózatot, illetve a szervezettel kapcsolatos, dinamikusan változtatható tartalommal ellátott lapok összességét jelenti, amelynek tartalmát csak a helyi hálózatra kapcsolt számítógépek érhetik el. Az internetes tartalmakkal ellentétben a hozzáférés csak egy zárt, intézményen belüli felhasználói kör számára adott, az intranet az információk megosztásával, egyéb szolgáltatásokkal számukra nyújt előnyt a hatékony munkavégzés és egészségügyi ellátás érdekében. D Intézményi belső kommunikáció támogatása D Webes felhasználói felület támogatása. D Dinamikus tartalommenedzsment kialakítása. A közölt információk központi, strukturált elhelyezése, felhasználóbarát felület D kialakítása. D A szervezeti felépítést tükröző publikációk támogatása. D Kategorizált tartalom elérésének lehetővé tétele. D Közös elektronikus dokumentumtár létrehozása. Minimális tartalmi elem elvárások teljesítése: telefonkönyv, címtár, eseménytár, D képgaléria, sajtófigyelés. D Dolgozók közötti belső fórum kialakítása. Intézményi külső portál (honlap) Az intézményi külső portál (honlap) olyan a világhálón keresztül elérhető, a szervezettel kapcsolatos, dinamikusan változtatható tartalommal ellátott weblapok összességét jelenti, amelyek egy közös kiinduló pontról érhetőek el, egységes struktúra részét képezik és arculatukban is illeszkednek egymáshoz. A külső intézményi portál kialakításának céljai: az egészségügyi intézmények honlapon keresztül történő közzétételi kötelezettségeinek törvényileg kötelezően előírt betartása (8.3 fejezet); az intézmény által közvetíteni kívánt értékek megjelenítése, az intézményi PR támogatása; az ügyfelek által az interneten keresztül indítható tranzakciók (pl. betegelőjegyzés) számára felület biztosítása. Összeállította a GYEMSZI szakértői munkacsoportja 68

73 D D D D D D D D D D D D Az intézmény jogszabályok által előírt (8.3 fejezet) szervezeti és személyzeti adatainak feltüntetése. Az intézmény jogszabályok által előírt (8.3 fejezet) tevékenységre, működésre vonatkozó adatainak feltüntetése. Az intézmény jogszabályok által előírt (8.3 fejezet) gazdálkodási adatainak feltüntetése. Az intézmény jogszabályok által előírt (8.3 fejezet) közbeszerzési eljárással kapcsolatos adatainak feltüntetése. Az intézmény jogszabályok által előírt (8.3 fejezet) várólistával kapcsolatos adatainak feltüntetése. Online betegelőjegyzés lehetővé tétele (amely intézménynél releváns) Dinamikus tartalommenedzsment kialakítása. Elektronikus dokumentum elérési lehetőség megteremtése. Gyakran Ismételt Kérdések (GYIK / FAQ) megjelenítése a portál felületén kérdésválasz formában. A törvényileg előírt alaptevékenységek megjelenítése mellett, azon túl egyéb intézményileg biztosított szolgáltatások részletezése. Valósuljon meg legalább egy idegen nyelven (javasoltan angolul) történő honlap megjelenítés továbbfejleszthető módon. Valósuljon meg az angolon kívül még több idegen nyelven (javasoltan németül is) történő honlap megjelenítés továbbfejleszthető módon. Összeállította a GYEMSZI szakértői munkacsoportja 69

74 4.4 Intézményközi rendszerszolgáltatások általános és specifikus követelményei Egészségügyi intézményközi információs rendszerek: olyan megfelelő szabványokkal, protokollokkal, interfészekkel és háttérrel felvértezett és létrehozott infokommunikációs rendszerek, amelyek nagyobb számú, különböző feladatkörű egészségügyi intézmény informatikai belső rendszereit egyesítik és kötik össze annak érdekében, hogy az egyes szolgáltatók egymással és a központi rendszerekkel betegadataikat, kórtörténeteiket, vizsgálati eredményeiket, időpontfoglalásaikat stb. egymással elektronikusan megoszthassák, ezáltal hatékonyabb működést és egészségügyi ellátás valósulhasson meg. A jövőben kiépítendő egészségügyi intézményközi, funkcionálisan integrált információs rendszerekkel kapcsolatosan az alábbi követelménylistát javasoljuk: Intézményközi rendszerszolgáltatások általános követelményei E Magyar szabályozási környezetnek megfelelő működés. E A kommunikáció kapcsán az adatvédelem maximális szintű biztosítása. E A rendszer rendelkezzen működéshez szükséges strukturált jogosultságkezeléssel. E A rendszer képes a felhasználók jogosultságával kapcsolatos ellenőrzések meghatározott időközönként való lefolytatására. E A rendszer skálázható, vagyis van lehetőség a felhasználók (userek) számának Összeállította a GYEMSZI szakértői munkacsoportja 70

75 E E E E E E E E E E E E E E E E E E E E E bővítésére. A rendszer bővíthető, képes későbbi igények rugalmas kielégítésére. A rendszer használható felületeinek nyelve magyar legyen. A rendszer adminisztrációs felületeinek nyelve és a szoftver dokumentációja magyar legyen. Rendelkezésre áll a rendszerhez magyar nyelvű felhasználói dokumentáció. Rendelkezésre áll már a fizikai kivitelezés előtt a teljes rendszerterv, a műszaki és működtetési dokumentáció, amelyben meghatározásra kerülnek az alapfunkciók A rendszer valamennyi felhasználója részesüljön a megoldás szállítójától, vagy más módon (pl. a TÁMOP projekt révén) képzésben, betanításban A rendszer fejlesztője / szállítója biztosítson magyar nyelven elérhető terméktámogatást legalább 5 évig. Az intézményközi rendszer integráltságot valósít meg több különböző intézmény (belső) rendszerei között (azokkal kapcsolatos specifikus követelmények: 4.1; 4.2; 4.3 és részek). A kialakítandó rendszer tegye lehetővé az intézmények integrált rendszerei, moduljai közötti kétirányú strukturált adatcserét. A tranzakciók, adatcserék, interfész műveletek, behatolási kísérletek, valamint a felhasználói és az adminisztrátori tevékenységek naplózása. A naplózott események, adatok alapján lehessen lekérdezést, illetve keresést lefolytatnia (a beteggel kapcsolatosan) az arra jogosult felhasználónak. A rendszerben tárolt, illetve továbbított adatokat csak a jogosult felhasználók láthatják. Az intézményközi információs rendszer felhasználóit központilag kell regisztrálni és nyilvántartani Felhasználók felvételének, jogosultságainak módosításának, törlésének központi kezelése Legalább 3 szintű felhasználói hierarchia megvalósítása: Egészségügyi szolgáltató Egészségügyi munkahely (pl. osztály) Felhasználó Az intézményközi rendszer tegyen eleget az Európa Unióban, illetve nemzetközileg használatos IT-biztonsági ajánlásoknak, szabványoknak. Biztonsági napló állományok tárolása két különböző fizikailag elkülönített helyen, (célszerűen más intézményekben). A rendszer képes legyen lefolytatni adatkommunikációt a központi országos egészségügyi intézmények (OEP, ÁNTSZ-OTH, OMSZ, OVSZ, GYEMSZI, EEKH) informatikai rendszereivel, a létrejövő központi egészségügyi IT rendszerekkel és a többi régiós egészségügyi intézményközi informatikai rendszerrel. A rendszerhez legyen csatlakoztatva valamennyi az adott régióban működő: Fekvőbeteg és járóbeteg ellátó intézmény Helyi mentőszolgálat A rendszerhez legyen csatlakoztatva valamennyi az adott régióban működő: Gyógyszertár Háziorvos (amennyiben nem valósul meg minden praxist elérő központi háziorvosi rendszer) Magántulajdonú egészségügyi szolgáltató Központi egészségügyi intézmények (pl. ÁNTSZ-OTH) regionális szerve Az intézményközi információs rendszer legyen képes az elektronikus aláírás és Összeállította a GYEMSZI szakértői munkacsoportja 71

76 digitális időpecsét használatára, fogadására E A rendszer használjon megfelelő és szabványos adatcsere protokollokat, megoldásokat. E A rendszer használjon megfelelő és szabványos interfész megoldásokat. Az intézményközi információs rendszerben a felhasználói felületen a következő műveletek legyenek megvalósíthatók (funkciók elérhetők): Dokumentumbevitel Dokumentumlekérdezés, lehívás Előjegyzések E Egészségügyi szolgáltatáskérés-válasz Betegrendelkezések TB adatok lekérdezése Üzenettovábbítás Jogosultságkezelés A rendszer rendelkezzen megfelelő szerver- és hardverháttérrel, backup E kapacitásokkal, a zavartalan működéshez szükséges műszaki feltételek biztosításával (pl. szünetmentes áramellátással) A rendszer valamennyi funkciójának éves rendelkezésre állása érje el a 99,9%-os E szintet A rendszer fejlesztése, üzemeltetése és minősítése a 4.5, 5. és 6. fejezetben leírtaknak E megfelelően történjen Intézményközi technológiai protokollok követelményei E Gyártó független, szabványos adatátviteli protokollok alkalmazása Megfelelő biztonsági szintű titkosítás alkalmazása az intézmények közötti E kommunikációban résztvevő végberendezések között A rendszer Internet felöli védése megfelelő képességű tűzfalakkal, proxy-kkal és E behatolásvédelmi, megoldásokkal Legalább peer-to-peer kapcsolat létrehozása a rendszerhez csatlakozott egészségügyi E intézmények között A rendszer intézményeinek internetes összeköttetése, az egyes végpontok szélessávú E internetelérése érje el legalább a kereskedelemben ajánlott átlagos sávszélességet (technológiai platformtól függetlenül). A rendszernek alkalmasnak kell lennie a legszélesebb körben használt hálózati, E kommunikációs szabványokhoz való illeszkedésre Adatkommunikációnál, adatcserénél, - továbbításnál a GYEMSZI által összeállított E Adatkommunikációs ajánlásgyűjteményben szereplő formátumok (valamelyikének) alkalmazása az MSZ szabvány az irányadó. Összeállította a GYEMSZI szakértői munkacsoportja 72

77 4.5 Üzemeltetési követelmények Szolgáltatásmenedzsment kérdések Jelen fejezet az anyag céljainak megfelelő mélységben és szemléletben foglalkozik a Szolgáltatásmenedzsment stratégián kívüli területeivel a folyamatok és követelmények szemszögéből. Nem, vagy csak felületesen érinti a szerepek, funkciók területét Szolgáltatás tervezés Szolgáltatás katalógus menedzsment F Létre kell hozni az informatikai rendszer szolgáltatási katalógusát A szolgáltatás katalógusnak részletesen tartalmaznia kell azokat a folyamatokat, F melyeket a rendszernek szolgáltatni kell. F A szolgáltatási katalógusban jelezni kell a folyamatok kapcsolatrendszerét. F A szolgáltatás katalógust a változáskezelés irányítása alatt karban kell tartani Szolgáltatás szint menedzsment A szolgáltatás szint menedzsment célja, hogy a szolgáltatás katalógusban rögzített szolgáltatásokat az elvárásoknak megfelelő színvonalon szolgáltassa. A szolgáltatási szinteket, és az elvárásokat megfelelő szintű dokumentumban kell rögzíteni. A dokumentum alapkövetelményei azonosak belső szolgáltatás, illetve külső fél szolgáltatása esetén. A szolgáltatás szint megállapodás (Service Level Agreement - SLA) a szolgáltatás megrendelője és a szolgáltató között jön létre mérhető módon meghatározva a szolgáltatás céljait, feladatait, mérési módszerét, kapcsolati pontjait, felelősségi köreit, nemteljesülés esetén a vállalt szankcióikat, az ellenőrzés és a visszajelzés lehetőségeit. Az egészségügyi intézményrendszerben elterjedt az a gyakorlat, hogy a tevékenységeit támogató szoftver licenc használati/bevezetési megállapodás mellett támogatási megállapodásokat is kötnek. Ezek a szerződések több évre meghatározhatják a rendszer megbízhatóságát, minőségét, rugalmasságát, így döntő befolyással bírnak annak elfogadottságára és az intézmény alaptevékenységére. Ezen tevékenység támogatására is SLA megállapodást kell kötni Szolgáltatás szint megállapodás A szolgáltatás szint megállapodáshoz minden esetben szolgáltatás katalógust kell F csatolni. A szolgáltatás katalógusnak részletesen tartalmaznia kell azokat a szoftver F folyamatokat, melyeket a rendszernek a megállapodás szerint annak érvényessége idején szolgáltatni kell. A szolgáltatási szint megállapodásnak tartalmaznia kell a szolgáltatási szint F biztosításához szükséges elvárt üzemeltetési szintet. Amennyiben az üzemeltetés kiszervezett, üzemeltetési szint megállapodást kell kötni, F amely feltételrendszere megfelel a szolgáltatási szint megállapodás által elvártaknak. Az elvárt üzemeltetési szint tartalmazza az architekturára vonatkozó elvárásokat, F együttes üzemeltetésre, tápellátásra, általános üzemeltetési tevékenységekre vonatkozó feltételeket. Az szolgáltatási szint megállapodás során mérhető paramétereket kell megadni, F amelyek pontos mérési módszerét a megállapodásban rögzíteni kell. Dokumetálni kell a kötelezettségek betartásához kapcsolódó garanciákat, és a F mulasztási következményeket. Összeállította a GYEMSZI szakértői munkacsoportja 73

78 Az egészségügyben használatos rendszereknél leggyakrabban monitorozandó objektumok F F F F F F Meg kell határozni a Hardver (szerverek, nyomtatók,munkaállomások stb.) SLA jellemzőit o Rendelkezésre állás adott időegységre vonatkozó százalék o Processzor idő időtartam o Processzor terheltség százalék o Válaszidő időtartam o Memória kihasználtság százalék o Egy időben működő munkaállomások száma db o Szabad tárkapacitás kapacitás egység Meg kell határozni a hálózat SLA jellemzőit o Külön SLA-t kell megállapítani LAN, WAN hálózatokra, külső kapcsolatokra, internetre o Rendelkezésre állás - adott időegységre vonatkozó százalék o Sávszélesség irányonként(letöltés, feltöltés), névleges és minimális - adatmennyiség/időegység o Válaszidő meghatározott méretű és számú csomag átviteli ideje egyeztetett mérési metódus szerint időtartam maximális vagy átlagos o Csomagvesztés meghatározott méretű és számú csomag átvitele során elveszett csomagok aránya db vagy százalék Meg kell határozni a szoftver alkalmazások SLA jellemzőit o Rendelkezésre állás szoftver esetében a rendelkezésre állást a rendelkezésre állás menedzsmentben taglaltak alapján kell osztályozni adott időegységre vonatkozó százalék o Működő licencek száma (licenc szerződéstől függően, de az egy időben maximálisan működő licencek alapján) db o Válaszidők válaszidőket kell meghatározni alapvető folyamatokhoz pl. adatbevitel, szótárakban keresés, adatbázisban keresés, nyomtatás stb. időtartam o A válaszidők mérésére pontos eljárásrendet kell meghatározni, amely tartalmazza a mérés tárgyát, környezetét, gyakoriságát, kiértékelési módját. Meg kell határozni a szoftver követés SLA jellemzőit o Közhiteles adatbázisok követési ideje közzétételt követően időtartam o Közhiteles szabályalgoritmusok követési ideje - közzétételt követően időtartam o Jogszabályok követési ideje - közzétételt követően időtartam o Jogszabályok követési ideje visszamenőleges hatály esetén - időtartam Meg kell határozni a támogatás SLA jellemzőit o Támogatási időszak napi, heti időszakok o Telefonos elérhetőség vonalak száma o Telefonos elérhetőségi idő időtartam o -en történő elérhetőségi idő igazolt olvasás időtartam o Válaszidő időtartam Meg kell határozni a hibakezelés SLA jellemzőit o Esemény besorolási szabályok szintek o Hiba bejelentési időszak napi, heti időszakok o Telefonos elérhetőség vonalak száma Összeállította a GYEMSZI szakértői munkacsoportja 74

79 o Telefonos elérhetőségi idő időtartam o -en történő elérhetőségi idő igazolt olvasás időtartam o Válaszidő időtartam o Helyreállítási idő bejelentéstől a helyreállításig hibaszintenként időtartam o Hiba javítás állapotáról értesítési gyakoriság hibaszintenként időtartam A szolgáltatásszint menedzsment felelősségi körei Miután az SLA szerződés eredményeként két fél megállapodása jön létre, a feleknek pontosan meg kell fogalmazni a szolgáltatás nyújtásában történő együttműködés elhatárolásait, feladatait, felelősségeit. F Pontosan el kell különíteni a felek faladatait Pontosan meg kell határozni a kapcsolattartó személyeket és azok jogosultságait, F faladatait F Meg kell határozni a döntéshozói kört F Meg kell határozni a kapcsolattartási szinteket és módokat Szolgáltatásszint mérés és felülvizsgálat F Az elfogadott szolgáltatás szint mutatókhoz elfogadott mérési módszert és eljárást kell rögzíteni F F F F Rögzíteni kell a mérési gyakoriságot, kontrollt Mutatónként meg kell határozni a figyelmeztetési, riasztási szinteket A változáskezeléssel folyamatosan együttműködve a rendszerrel szembeni elvárások változásaihoz igazodva az elvárt szolgáltatás szinteket felül kell vizsgálni rendszeres előre meghatározott időszakonként. Az elvárt szolgáltatásszint változást a változáskezelés folyamatainak megfelelően kell a rendszeren átvezetni SLA küszöbérték átlépésének kiértékelési szabályai és következményei F F F F F F F Biztosítani kell a szolgáltatásszint mutatók figyelmeztetési szint elérési értékeihez tartozó eljárásrendet Biztosítani kell a szolgáltatásszint mutatók megsértési értékeihez tartozó eljárásrendet Szolgáltatásszint sértésnél biztosítani kell az esemény és hibamenedzsment szerinti eljárásrend alapján a rendszer megfelelő szintű működését Meg kell határozni a szolgáltatásszint megsértése esetén alkalmazandó jogkövetkezményeket Szolgáltatásszint megsértésének időszakára szolgáltatási díj nem kérhető (amennyiben a szolgáltatásszint sértés a szolgáltató hibájából történt) Szolgáltatásszint megsértésének időszakára kötbért kell megállapítani Szolgáltatásszint megsértése esetén a kötbéren kívül kártérítés is kiköthető Összeállította a GYEMSZI szakértői munkacsoportja 75

80 Kapacitás menedzsment A kapacitás menedzsment célja, hogy a rendszer kapacitásainak, erőforrásainak pontos nyilvántartására, monitorozására alapozva tervezni lehessen az erőforrás igényeket és optimalizálni lehessen az erőforrásokat F A rendszernyilvántartásokat oly módon kell megalkotni, hogy az egyes kapacitásértékek lekérdezhetőek legyenek F A rendszer kapacitásait oly módon kell megszervezni, hogy az elfogadott SLA szintek teljesíthetők legyenek F A rendszer kapacitás igényeit, kihasználtságát monitorozni kell F A monitorozás során figyelembe kell venni az erőforrásigény időbeli változásait F Az adatokat elemezni kell F Az elemzések alapján dönteni kell esetleges változáskérelem vagy áthangolás kérdéskörben F A változáskezelés döntési folyamataiban a kapacitásmenedzsment adatait figyelembe kell venni F A rendelkezésre állás növelésére, az érzékeny alkalmazások biztonságára létrehozott tartalék kapacitásokat még átmeneti időre sem szabad más célra igénybe venni Rendelkezésre állás és a szolgáltatások folytonosságának biztosítása A rendelkezésre állás az informatikai rendszer azon állapota, mely során annak minden szolgáltatása, funkciója működőképes és elérhető. A rendelkezésre állás menedzsment célja, hogy a rendelkezésre állás az üzemidő minél nagyobb százalékában megvalósuljon. A rendelkezésre állás kérdésével alapvetően két szinten, a rendszer tervezése és az üzemeltetése során kell foglalkozni. Ezek során a biztosítandó feltételek: o Rendelkezésre állás o Megbízhatóság o Biztonság o Ellenálló képesség o Javíthatóság o Szervizelhetőség A biztonsági kérdésekkel külön fejezet foglalkozik. A rendelkezésre állást csökkentő/megszüntető időszak mindig az esemény létrejötte és a helyreállítás közötti időszak. Az időszak a következő eseménysort tartalmazza o esemény létrejötte o esemény/következmények észlelése o esemény információjának dedikált helyre történő beérkezése o esemény regisztrációja o esemény okának, hatásainak megállapítása o javítás o hatások megszűntetése/helyreállítás o felhasználók kiértesítése o dokumentálás A rendelkezés állás csökkenése a rendszer szolgáltatásainak csökkenését jelenti. Ezek F pontos és mindenki számára elfogadott meghatározásához a rendszer elvárt szolgáltatásait pontosan definiálni kell (pl. SLA, szolgáltatás katalógus). A rendelkezésre állás csökkenését a szolgáltatás csökkenésének függvényében F kategorizálni kell. Összeállította a GYEMSZI szakértői munkacsoportja 76

81 A rendszer tervezésénél, a szolgáltatási szint megállapodásánál a rendelkezésre állási százalékot meg kell tervezni. A tervezés során figyelembe kell venni, hogy az elvárt F szint emelése egy határ fölött a rendszer árának drasztikus emelkedésével jár a szükséges technológiák minőségi váltása miatt. Ezért a tervezés során alkalmazni kell a risk menedzsment elemeit, és az ár érték arányt optimalizálni kell. A rendelkezésre állási százalékot mindig egy adott időszakra (év, vagy hónap, vagy F nap, stb.) vonatkoztatva kell megállapítani 158. Figyelembe kell venni elsősorban az SLA megállapodásokkor, hogy például 99,9%/hó max. 43 perc kiesést jelent havonta 99,9/év max. 8,76 nap kiesést jelent évente, ha egyéb kitétel nem szerepel. Szerverek: F Brand, kiforrott típus választása 159 F Redundáns táp (hot swap), processzor, HDD (hot swap) F Szerverhez tervezett processzor F Hardveres RAID és hardveres RAID vezérlő F Skálázhatóságot és rendelkezésre állást növelő tényezők a virtuális szerver, storage megoldások F A rendszerszoftverek folyamatos frissítése 160 F Három év helyszíni garancia F Élettartamra biztosított alkatrészellátás F Saját távfelügyeleti menedzsment rendszer F A menedzsment során mérhetőnek kell lenni az alapvető működési értékeknek: hőmérsékleti, HDD állapoti stb. tényezők F A működési indikátorok szélsőséges értékénél riasztani kell 161. Személyi számítógépek: F Az eszköz kiválasztásánál megbízhatóságot növelő tényező a megfelelő brand 162 a kiforrott típus választása. F Rendelkezésre állást növelő tényező a felhasználáshoz optimalizált típus alkalmazása 163. LAN: F F F F F Aktív eszköz kiválasztásánál megbízhatóságot növelő tényező a megfelelő brand 164, a kiforrott típus választása. Az otthoni felhasználásra szánt eszközök alkalmatlanok az egészségügyben alkalmazott rendszerek kiszolgálására. Aktív eszközök központi menedzselhetősége Az aktív eszközök megfelelő menedzselése, és a forgalmak és a portok folyamatos monitorozása A hálózat passzív elemei egy gyártótól származó garantált minőségűek legyenek Kábelezés esetén az alkalmazásoknak és a környezetnek megfelelő kábelrendszer 165 és kiépítés alkalmazása. 158 Legelfogadottabb a rendelkezésre állás százalékát a számlázási időszakhoz kötni. Ideális eset ha a számla mellékletét képezi az adott időszakra vonatkozó rendelkezésre állás százaléka 159 Ezt legjobban az eszközökhöz igénybe vehető szerviz szolgáltatások, rendelkezésre állás, alkatrész ellátottság és a garanciális feltételek alapján lehet lemérni 160 Pl: firmware frissítések, eszköz meghajtó szoftverek 161 Csak a gyári, szoftveres megoldás elfogadható 162 Ezt legjobban az eszközökhöz igénybe vehető szerviz szolgáltatások, rendelkezésre állás, alkatrész ellátottság és a garanciális feltételek alapján lehet lemérni. Eszköz és operációs rendszer frissítések, BIOS frissítés, távmenedzselhetőség, stb. 163 Pl. az otthoni (home) használatra szánt típusok mellőzése, vékony kliens alkalmazásánk számbavétele 164 Ezen a piacon elérhető az élettartam garancia az eszközökre valamint sok beépített extra szolgáltatás (hálózatfigyelés, vírusvédelem,stb.) Összeállította a GYEMSZI szakértői munkacsoportja 77

82 F Földelé s és villámvédelem 166 F WIFI esetén a megfelelő lefedettség és titkosítás biztosítása F A hálózat pontos dokumentáltsága WAN: F A hálózati előírás értékei feleljenek meg az alkalmazások eredője igényeinek. F A méretezés vegye figyelembe az inhomogén igénybevételi szintet, a biztonsági zónákat. F A hálózat sávszélességi értékeinek előírása mindkét irányban. F A hálózat válaszidejének előírása F A hálózat megengedett csomagvesztési értékeinek előírása F Folyamatos monitorozási lehetőség az aktív eszközökre vonatkozóan F Tartalék megoldás biztosítása eltérő technológiával és eltérő útvonallal F Automatikus váltás a tartalék megoldás felé. Szoftverek: F Megbízhatósági tényező az elterjedt, brand 167 megoldások alkalmazása F Biztosítani kell a megfelelő szoftvertámogatást F Operációs rendszerek, adatbázis kezelők esetén hibatűrő megoldások alkalmazása F Több szoftver együttes alkalmazása esetén együttműködő képesség vizsgálata F Nem dobozos szoftverek esetén szabványos fejlesztői módszertan és dokumentáció előírása F Garanciák előírása F Rendszeres szoftverfrissítés és támogatási szolgáltatás megrendelése F A szoftverek licencszerű használata F A szoftverek erőforrásigényeinek betartása/előírása Környezet: F Az igények szerint méretezett többirányú betáplálás biztosítása automatikus átkapcsolással F A rendelkezésre állási terv szerinti szünetmentes megoldás biztosítása F A szünetmentes tápellátás monitorozása F A szünetmentes tápellátás rendszeres időszakonkénti tesztelése F Szerverek leállításának szünetmentesről történő vezérlése F Áramingadozási, villám védelem F Földelés 168 F Az eszközök előírt üzemhőmérsékletének biztosítása Helyreállíthatóság: F Biztonsági másolatok készítése F Biztonsági mentések készítése F Biztonsági mentések készítésének rendszerelőírása F Biztonsági mentések, másolatok tárolási rendje F Archiválási rendszer alkalmazása F Kritikus alkalmazások esetén duplikát megoldás alkalmazása 165 A hálózat megfeleőségét mérési jegyzőkönyvvel kell dokumentálni (teljes link mérés+mérési jegyzőkönyves pach kábelek és lengőkábelek) 166 A földelés és villámvédelem jóságát rendszeres időközönként méréssel ellenőrizni kell 167 Jogtiszta, licenszelt és fejlesztett, verziózott 168 A földelés és villámvédelem jóságát rendszeres időközönként méréssel ellenőrizni kell Összeállította a GYEMSZI szakértői munkacsoportja 78

83 Informatikai biztonság menedzsment Az egészségügyben alkalmazott rendszerek, illetve az egészségügyi szervezetek tekintetében az információ biztonságnak kiemelt jelentősége van Kockázatelemzés F F F F F F F F F F F F F F F F F F Kockázatelemzési módszertant kell választani A választott módszertannak illeszkednie kell az elvárt működési követelményekhez A választott módszertannak biztosítania kell, hogy az eredmények reprodukálhatók legyenek Azonosítani kell a kockázatkezelés területeit, környezetét, céljait, a kockázatértékelés szempontjait Azonosítani kell a kockázatokat fenyegetettség irányból Azonosítani kell a fenyegetett pontokat Azonosítani kell a sebezhető pontokat Azonosítani kell az esetleges magvalósult fenyegetettségek következményeit A választott módszertannak megfelelően az azonosított elemeket szintekbe kell sorolni Meg kell becsülni a kockázatok megvalósulásának valószínűségét Szintekbe kell sorolni és súlyozni a kockázatokat Dönteni kell az egyes kockázatok javításáról a kockázatarányosság figyelembevételével A kockázatjavítási döntés esetén pontos tervet kell készíteni, mely magába foglalja a szükséges tevékenységeket és a várt hatások elemzését. Kockázatjavítás végrehajtása után meg kell határozni a maradvány kockázatokat. Dönteni kell az egyes kockázatok elfogadásáról a kockázatarányosság figyelembe vételével A kockázatokat kezelni kell. Az elfogadott kockázatokhoz kell igazítani a szolgáltatástervezés további tevékenységeit, a szolgáltatás bevezetést és üzemeltetést. A kockázatelemzés folyamatait új fenyegetettség megjelenése esetén ismételni kell A kockázatelemzés folyamatait háromévente ismételni kell Biztonsági szabályzat F F F F F F A szervezet vezetésének iránymutatást kell adnia az információbiztonság követelményeivel kapcsolatosan. Ennek lényege olyan szabályzat létrehozása, mely valamennyi alkalmazottra és partnerre vonatkozik Megfogalmazásának feltétele a tartalmi követelmények mellett a közérthetőség Gondoskodni kell a megismertetéséről A biztonsági szabályzatnak minden érintett részére elérhetőnek kell lennie Rendszeres időközönként aktualizálni kell Meg kell határozni a felülvizsgálat felelősét, továbbá a szükséges felülvizsgálatok gyakoriságát, és esetleges eseményhez kötöttségét. (pl. jelentős biztonsági esemény, jelentős szervezeti, technológiai változás stb.) Az informatikai biztonság szervezeten belüli menedzsmentje F A vezetésnek elkötelezett magatartást kell tanúsítania. F Fel kell állítani azt a szervezeti kört, amely felelős a biztonsági szerepek kiosztásáért, a biztonsági szabályzat karbantartásáért. E körön belül kell elemezni az esetlegesen Összeállította a GYEMSZI szakértői munkacsoportja 79

84 F F F F F bekövetkezett biztonsági eseményeket. Létre kell hozni az adatvédelmi felelős funkciót, és a jogszabályoknak megfelelő felelősségi és jogosultsági körökkel ellátni. Felelősségi körök definiálása. Tisztázni kell a vagyontárgyak és folyamatok felelőseit. Tisztázni kell, új eszköz, folyamat bevezetésekor, megszűnésekor a felelősségi kör karbantartás rendjét. Meg kell határozni, hogy a felelősségi kör milyen jogokkal, kötelességekkel, eljárásrenddel jár. Megfelelő funkciókkal és jogokkal felruházott képviselőket kell delegálni. Ezeket központi dokumentumban és munkajogi megállapodásban is rögzíteni kell. Titoktartási nyilatkozatok, megállapodások folyamatos karbantartása Külső ügyfelekkel összefüggő kockázatok megállapítása és kezelése eszközátadás, adatkapcsolat, egyéb szerződések során. Elsősorban meg kell állapítani a hozzáférés indokát, célját ésmódját. Ez alapján kell tisztázni és szabályozni a fizikai és logikai (pl. adatokhoz) hozzáférési jogokat. Tisztázandó, hogy a külső fél alkalmaz-e további alvállalkozókat, azok jogosultsági szintjeit. A harmadik féllel kötött szerződés biztonságpolitikai fejezetének tartalmaznia kell a szervezet biztonsági szabályzatának mindazon elemeit, melyeket érint, továbbá a harmadik fél hozzáférési módjait, az együttműködés, az ellenőrzés szabályait, a felelősségi köröket a változáskezelési, hibaelhárítási szabályokat. Erőforrás kihelyezés biztonsági feltételei nagyrészt megegyeznek az előző ponttal, azzal a megjegyzéssel, hogy pontosan el kell határolni a két szervezet felelősségét, feladatait. Erőforrás kihelyezés esetén figyelembe kell venni, hogy a biztonságpolitikai események körülményei sokszor összetettek, így a pontos elhatárolások tervezésére kiemelt jelentőségű Informatikai vagyon kezelése F F F F F A vagyonleltárt oly módon kell felvenni, hogy az alkalmas legyen az egyértelmű azonosításra, és az egyes vagyontárgyak szervezeten belüli mozgásának követésére. Az informatikai vagyon leltárát az általános leltári előírások mellett olyan részletezettséggel kell vezetni, hogy folyamatosan figyelemmel lehessen kísérni az eszközök garanciális mutatóit, avultsági szintjét, meghibásodási,szervizelési és javítási eseményeit. Az informatikai vagyon ily módon történő kezelése segítséget nyújt a kockázat elemzésben, a beruházások tervezésében. A szoftverek leltárát oly módon kell vezetni, hogy a kiadás és a visszavételezés mellett a szerzői jogoknak megfelelően a licenc előírásoknak megfelelő használat igazolható legyen. Az informatikai vagyon azonosítása nem minden esetben felel meg a számviteli leltári vagyon fogalmaival. Vagyontárgynak kell tekinteni minden szerzői jog által védett, vagy szellemi értéket képviselő anyagot is, mint rendszerdokumentációt, kezelési kézikönyvet, oktatási anyagot stb. Az informatikai vagyon része az információ is. Az információ nyilvántartásához annak azonosítása, osztályozása, csoportba sorolása szükséges. A csoportképzés alapja lehet az információ típusa, védettségi szintje, a rá vonatkozó elévülési, tárolási előírások (pl. egészségügyi adatok külön szabályai). Az információ osztályozásához hozzá kell kapcsolni a csoportra vonatkozó vagyonkezelési előírásokat a tárolás, másolás, mozgatás, továbbítás, megsemmisítés vonatkozásában. Külön rendelkezni kell a hosszú őrzési idejű adatcsoportok esetleges technológiaváltást követő migrálási megoldásairól. Ide kell érteni az adatkezelő szoftverek váltásának következményeit és a tárolási eljárások váltásának feltételeit. Összeállította a GYEMSZI szakértői munkacsoportja 80

85 F Vagyontárgyak tulajdonjoga. Az egészségügyben gyakran előforduló idegen eszközök (alapítványi, próba stb.) elkülönített nyilvántartása. Az azokon található adatvagyon védelme az esetleges visszaadáskor A személyzet biztonsága A szakirodalom szerint az információ biztonságára a legnagyobb veszélyt a személyzet jelenti. Az egészségügyben általában központi rendszereket használ nagyszámú személyzet, ami az adatbiztonságra kiemelt kockázatot jelent. F Biztonsággal összefüggő feladat és felelősségi körök kialakítása Az alkalmazottak vizsgálata a felvételnél. Ellenőrizni kell, hogy a hozzáértés valódi. Szükség esetén ellenőrizni kell a megbízhatóságot. Kiképzetlen új személyzet esetén ki F kell dolgozni a betanítás rendjét és felelősségi körét. Folyamatosan kapcsolatot kell tartani a személyzettel. Hirtelen élethelyzet változások, romlások biztonsági problémákat okozhatnak. Az alkalmazottak és közreműködők alkalmazási szerződésben vállalt felelőssége és kötelezettségeinek megfogalmazása, titoktartási nyilatkozat. Az alkalmazási szerződésben kell rögzíteni a biztonsági felelősségeket (többek között pl. a privát mail F lehetőségét/tiltását), titoktartási előírásokat. A titoktartásra vonatkozó előírások a szerződésben akár a foglalkoztatás utáni időszakra is vonatkozhatnak. Célszerű szerződésbe foglalni az előírt követelmények megszegésének munkajogi következményeit. F A kötelezettségek betartatása F A biztonságot megsértők megfelelő szintű számonkérése F Alkalmazás/szerződés megszüntetése esetén meg kell határozni a felelősségi körök további sorsát F Alkalmazás/szerződés megszüntetése esetén vissza kell szolgáltatni a kezelésben lévő vagyontárgyakat beleértve az adatvagyont is. Alkalmazás/szerződés megszüntetése esetén meg kell szüntetni a hozzáférési jogokat. F Ideértve az összes használt rendszer, a levelezés, és bármilyen hozzáférés jogát. Az előírásból következően alkalmazás/szerződés megszüntetése csak az adott terület információ biztonságával megbízott felelős ellenjegyzésével történhet. A biztonsággal összefüggő eljárások, feladatok oktatása. A szervezet érintett tagjait folyamatosan képezni, továbbképezni szükséges. A képzésnek ki kell térni a betartandó szabályokra, eljárásokra. A képzés fontos része az esetleges biztonsági F eseményekre történő reagálás begyakorlása. Az ellátási intézményekben például a központi betegadminisztrációs rendszer esetleges leállása nem befolyásolhatja alapvetően a betegellátást. Minden érintettnek tudnia kell a megfelelő szabályzatok és képzés alapján a tennivalóit ilyen esetben is. Ugyanígy tudnia kell az esemény megszűnését követő tennivalókat is. Meg kell szervezni a biztonsági események jelentésének eljárásrendjét. Nem engedhető meg, hogy egyes esetleg helyben alacsonyabb fokozatúnak ítélt esemény ne F kerüljön továbbításra, mert az egyrészről lehetetlenné teszi a válaszlépések kidolgozását másrészről esetlegesen további eseményeket idézhet elő, ami már az alapvető működést, esetleg a betegellátást veszélyezteti Fizikai és környezeti biztonság F Területek védelme Azokon a területeken, ahol információt, vagy érintett eszközöket tartanak, biztonsági Összeállította a GYEMSZI szakértői munkacsoportja 81

86 F F F F F F F F F F F F elhatárolókat, határzónákat kell alkalmazni. Belépés védelem a csak a személyzet által használt területeken. Lehetőség szerint a beléptetési védelmet portaszolgálattal, örző-védő szolgálattal kell kiegészíteni. Ebben az esetben a feladatköröket rögzíteni kell. Kamerás védelem alkalmazása esetén be kell tartani az arra vonatkozó külön jogszabályokat. (pl. személyiségi jogok és adattárolással kapcsolatos előírások) Külső és környezeti veszéllyel szembeni védelem (tűz, árvíz, földrengés, robbanás villámlás, egyéb katasztrófák) A kiemelt biztonsági területeken (pl. szerverszoba) végzett munkavégzés szabályainak kidolgozása Berendezések védelme A berendezéseket úgy kell elhelyezni, hogy csökkenjen a jogosulatlan hozzáférés lehetősége. Nem helyezhető el úgy például egészségügyi adatokat feldolgozó eszköz, hogy arra a személyzeten kívül más ráláthasson, vagy ahhoz őrzés hiányában más hozzáférjen. Tartalék berendezéseket, mentett adatokat tartalmazó hordozókat úgy kell elhelyezni, hogy a megfelelő védelme mellett az alap berendezéstől/adattárolótól olyan távolságra legyenek, hogy minimalizálják annak lehetőségét, hogy bármilyen külső hatás mindkettőt együttesen érjen. A berendezések védelme az áramkimaradástól. A kockázatelemzés során tisztázni kell, hogy melyek elemeket, milyen szinten kell védeni ahhoz, hogy a folyamatos működés az elvárt szinten tartható legyen. A védelem a többutas tápellátástól a generátoros tartalék ellátásig terjedhet. A tartalék áramforrások állapotát kidolgozott terv és felelősségi kör mellett rendszeresen tesztelni kell. Kábelbiztonság. Az energiaátviteli és az adathálózatot védeni kell a károsodástól, illetve lehallgatástól. Amennyiben például a LAN hálózatok csomópontjai és aktív elemei a közforgalomtól nem elzárt területen helyezkednek el, gondoskodni kell megfelelő fizikai védelmükről. A hálózatot védeni kell az esetleges sérülésektől is egyrészt a megfelelően biztonságos kábelutak kialakításával, másrészt a megfelelő dokumentálással. Elő kell írni, hogy a szervezeten belüli egyéb karbantartásokat ezekkel a dokumentumokkal mindig egyeztetni kell. A berendezések biztonsága jelentős mértékben függ a karbantartástól. A gyári előírásokat be kell tartani. A karbantartásokat tervezni és naplózni kell. Berendezések biztonsága telephelyen kívül. Ide értendő a mobil eszközök biztonsága. A telephelyen kívüli munkavégzés kiemelt biztonsági kockázatot jelent mind az eszközök fizikai biztonsága, mind az adatok biztonsága szempontjából. Szabályozni kell ezen eszközök használatát, és biztosítani, hogy az adatok kiemelten a személyi és egészségügyi adatok illetéktelen kézbe ne kerülhessenek. Az adatkezeléssel kapcsolatos tevékenységeket naplózni szükséges. Külön szabályozni kell az otthoni munkavégzés esetében az adatbiztonságot, betörésbiztonságot. Szabályozni kell a karbantartásra házon kívülre kerülő berendezésekre vonatkozó előírásokat. Nem engedélyezhető, hogy ilyen berendezések visszaállítható módon adatot tartalmazzanak. kiemelten védendők a személyi, egészségügyi adatok. Ezek elsősorban az alapellátás egygépes rendszereire jelentenek veszélyt 169 Berendezések áthelyezése, selejtezése. Ennek során mindig figyelemmel kell lenni a tárolt adatokra. Az érvényes adatvédelmi jogszabályok szerint gondoskodni kell azok 169 A hibaelhárítási szerződéskötések kapcsán ragaszkodjunk a helyszíni hibaelhárításhoz. Összeállította a GYEMSZI szakértői munkacsoportja 82

87 F archiválásáról, az eszközről visszaállíthatatlan módon történő törléséről. Vagyontárgyak mozgatása. A vagyontárgyakat csak az adott terület információ biztonságával megbízott felelős ellenjegyzésével lehet áthelyezni, telephelyről kivinni A kommunikáció és az üzemeltetés biztonsága Üzemeltetési eljárások és felelősségi körök F F F F Az üzemeltetési eljárásokat karbantartott dokumentumba kell foglalni, és a felhasználóknak hozzáférhetővé tenni. Az eszközök és rendszerek változásait szabályozni kell. Rögzíteni kell a változtatásra jogosultak körét, a változtatási eljárásokat, az eljárásokat megelőző tervezési folyamatot, az esetleges helyreállítási eljárásrendet, a változtatást követő tesztelési, dokumentálási feladatrendszert. Az üzemeltetési feladatköröket és felelősségi területeket szét kell választani. A szétválasztás során biztosítani kell, hogy az ellenőrző szerepkőr mindig elkülönüljön a felhasználói szerepkőrtől. Ezzel az esetleges visszaélések a független ellenőrzések révén csökkenthetők. A fejlesztés, tesztelés, üzemeltetés eszközeit külön kell választani. Meg kell akadályozni, hogy az üzemeltetés biztonságát a fejlesztés, tesztelés esetleges szélsőséges következményei befolyásolják. Továbbá élesen el kell különíteni az üzemeltetési jogosultságokat és adathozzáférést a fejlesztési és tesztelési jogosultságoktól Harmadik fél szolgáltatásnyújtásának irányítása Az egészségügyi szolgáltatók esetében az alkalmazott központi rendszerek szállítóival gyakorlat a kapcsolódó (pl. support) szolgáltatási megállapodás. A szolgáltatás azonban nem kerülhet ki a megrendelő irányítása, kontrollja alól. Semmilyen körülmények között nem engedélyezhető, hogy a szállított rendszerekben akár a helyszínen, akár távolról kontroll nélküli tevékenységet folytassanak. Biztosítani kell a harmadik fél szolgáltatásnyújtásában a biztonsági előírások F betartását. F Biztosítani kell a szolgáltatási szintek betartását. F A harmadik fél által végzett szolgáltatásokat folyamatosan monitorozni kell. A harmadik fél által végzett szolgáltatások esetében a változáskezelésre, az ahhoz F kapcsolódó felelősségi körökre és szabályokra külön megállapodást kell kötni, és azt folyamatosan betartatni Rendszertervezés és elfogadás F F Az üzemeltetés során folyamatosan hangsúlyt kell helyezni a kapacitásmenedzsmentre. Azaz folyamatosan monitorozni kell az erőforrások kapacitás igényét, illetve kapacitás leterheltségét. A monitoring lehetőséget ad a jövőbeli kapacitásigények, erőforrásigények meghatározására, tervezésére. Rendszerszintű változtatásokra átvételi eljárást kell kidolgozni Rosszindulatú szoftverek elleni védelem F F F Központi eszközök védelme. A központi eszközök védelme során biztosítani kell a támadások dokumentálását Személyi eszközök védelme Mobil eszközök védelme Összeállította a GYEMSZI szakértői munkacsoportja 83

88 F Biztosítani kell a védelem naprakészségét Biztonsági mentés F F F Az információkról és szoftverekről biztonsági másolatot kell készíteni. Az egészségügy sajátos adatvédelmi szabályozásának megfelelően az adatokat oly módon kell menteni, hogy azok eredeti formájukban visszaállíthatók legyenek teljesítve az adatok megőrzésének feltételeit is. Az egészségügy sajátos adatvédelmi szabályozásának megfelelően az adatokat rendszeres időközönként oly módon is kell menteni, hogy azok eredeti szoftverkörnyezete is mentésre kerüljön Hálózat biztonsága F F A hálózati szolgáltatásokra SLA-t kell megállapítani, amelyet folyamatosan be kell tartani 170 /tartatni. A hálózati szolgáltatások biztonságát folyamatosan ellenőrizni kell Adathordozók biztonsága F A mobil adathordozók kezelésre eljárásrendet kell kidolgozni. Az egészségügyi adatokat kezelő rendszereket védeni kell az illetéktelen mobil F hordozóktól 171, illetve bármilyen más adatkinyerési eljárástól. Az adathordozók selejtezését oly módon kell elvégezni, hogy a rajtuk lévő adatok F visszaállítása ne legyen lehetséges. A dokumentációkat az adatokhoz hasonlóan védeni kell a jogosulatlan hozzáféréstől. F Azok egyrészt szerzői jogi védelem alatt állhatnak, másrészt illetékteleneknek információt szolgáltathatnak a rendszer felépítéséről csökkentve ezáltal a biztonságot Információcsere Az egészségügyi rendszerek közötti információcsere már jelenleg is igen nagy szerepet kap mind a központi rendszerek (pl. OEP) felé, mind egymás között (pl. háziorvos-szakellátás, szakellátáslabor közreműködő, szakellátó-szakellátó). Nyilvánvaló törekvés, hogy ezek a kapcsolatok tovább fejlődjenek. Az információcsere biztonsága azonban követelmény. Az információcserében résztvevő valamennyi eszközre, szoftverre ki kell dolgozni a szakmai eljárásokat és biztonsági intézkedéseket. A szabványos eljárásokat kell F preferálni, amelyek biztosítják az információ védelmét. Nem engedhetők meg olyan kapcsolatok, melyek során bármelyik fél a szükségesnél magasabb szinten hozzáférhet a másik rendszeréhez, adataihoz. F A külső féllel történő információcserét megállapodásban kell rögzíteni. Amennyiben az információcsere adathordozón valósul meg, azt védeni kell a F megrongálástól, visszaélésektől. Minimális védelem az adatok titkosítása. További védelem lehet pl. az adathordozó jelszóvédelme. Az elektronikus üzenetekben ( ) történő adatcsere szintén veszélyeztetett. F Amennyiben védett adatok továbbítására kerül sor, azokat külön védeni kell pl. elektronikus aláírással, titkosítással Elektronikus szolgáltatások F Az online tranzakciókat védeni kell lehallgatástól, esetleges jogosulatlan módosítástól, 170 A hálózati szolgáltatások megfelelőségét, teljesülést mérési jegyzőkönyvekkel kell dokumentálni. 171 Pl: USB portok tiltása Összeállította a GYEMSZI szakértői munkacsoportja 84

89 F F téves helyre kézbesítéstől. Az egészségügyi rendszereket 172 védeni kell a rendszert az esetleges rosszindulatú behatolástól. Ez minden esetben úgy történhet, hogy külső kapcsolatok sohasem jöhessenek létre közvetlen kapcsolódás útján. Azok csak külső védelmi vonalakon történjenek. Meg kell védeni az intézmények által közzétett információkat (pl. web oldalon) a jogosulatlan módosítástól Monitoring F F F F F F A felhasználói tevékenységről, kizárásokról, biztonsági eseményekről logot kell vezetni. Külön kiemelendő, hogy a medikai adminisztrációs rendszerekben naplózni kell minden adatmódosítást és adatolvasást is. Ezáltal ellenőrizhetővé téve az esetleges belső jogellenes tevékenységet. Eljárásokat kell kidolgozni a rendszerek használatának figyelésére. Az eltéréseket folyamatosan követni kell, és esetlegesen be kell avatkozni. A naplók védelmét és mentését meg kell szervezni. A naplók őrzési ideje arányos kell hogy legyen a bennük tárolt adatok aktualitásával és a vonatkozó jogi előírásokkal. Például adat jogellenes kiszivárogtatása esetén bizonyítékként szolgál a jogi eljárásban. Naplózni kell a rendszeradminisztrátori tevékenységeket, a rendszerhibákat, az arra adott válaszokat az esetleges anomáliák kiszűrése érdekében A szervezeten belül működő minden rendszer órajelét szinkronizálni kell. Az egyes rendszerek együttműködését az eltérő órajelek veszélyeztetik. Az egészségügyi adminisztrációs rendszereknél az évváltás szinkronizálása kiemelt fontosságú A hozzáférés ellenőrzése F A hozzáférést szabályzat szinten kell kezelni. F A felhasználók hozzáférés megadását és megvonását regisztrálni kell Szolgáltatás bevezetés Szolgáltatási eszköz és konfiguráció menedzsment Az informatikai komponenseket fel kell mérni és nyilván kell tartani verziószámmal, F komponensekkel, kapcsolatokkal A nyilvántartást úgy kell megoldani, hogy az információval szolgáljon a leltár, az F üzemeltetés, a változáskezelés számára. F A nyilvántartásba követni kell az eszköz állapotát F Menedzsment rendszernek támogatni kell a központi vezérlést, változáskezelést A nyilvántartások monitorozásával információval kell szolgálni a változáskezelés felé F a tervezhető felújítások, cserék tekintetében Változáskezelés Az informatikai rendszerekkel szemben változtatási igények merülhetnek fel szervezeti változások, tevékenységi változások, probléma megoldások, új technológiák, bővülő igények, hardver 173 és szoftver bővítések vagy csere 174 esetén, új folyamatok belépése, folyamatok módosulása stb. miatt. A változáskezelés célja, hogy a változtatások végrehajtásának sikerességét biztosítsa a káros hatások kizárása, vagy minimalizálása mellett. 172 Kórházi rendszerek, háziorvosi rendszerek, stb. 173 Pl: HDD bővítés, stb. 174 Pl: adatbázis kezelő váltás, kommunikációs könyvtás változtatás, stb. Összeállította a GYEMSZI szakértői munkacsoportja 85

90 F F F F F F F F F F F F F F F F F F Intézményen belüli változtatási folyamatok Egységes változáskezelési rendszert kell működtetni A változáskérelmeket egységesíteni kell és meg kell fogalmazni a kérelmezők jogosultsági rendszerét Ki kell nevezni a változtatási kérelmek elsődleges szűrése jogosult személyzetet Biztosítani kell a változtatások és annak hatásainak felmérését, a rendszerbe integrálhatóság vizsgálatát A változtatások kategorizálása erőforrás alapján A változtatások kategorizálása hatásuk alapján A változtatások prioritásának meghatározása A változtatás jóváhagyása, ütemezése a változtatást csak az arra kinevezettek hagyhatják jóvá, és csak az ő megrendelésük alapján kezdődhet a létrehozásuk. Ők a felelősek a megfelelő ütemezésről, mely biztosítja a rendszer optimális működését. A változtatást pontosan meg kell tervezni, és létrehozása csak a terv szerint történhet. A változtatást dokumentálni kell. A változtatások tesztelése a változtatásokat tesztelni csak az éles rendszerrel azonos beállításokkal rendelkező tesztrendszeren lehet. A tesztelés során a funkcionális folyamatteszt mellett tesztelni kell a megbízhatóságot, a biztonságot és a teljesítményigényt is. A változtatások végrehajtásának előkészítése során elvégzendő az oktatás, kezelési anyagok kiadása A változtatások biztonságának előkészítése során gondoskodni kell a mentésekről. A változtatások végrehajtását csak az arra kinevezettek engedélyezhetik, az csak az engedély birtokában hajtható végre. Sürgős változtatási kérelem esetében sem lehet eltekinteni a jóváhagyástól, a minimális teszttől, a mentéstől, a felhasználói értesítéstől, a végrehajtás engedélyezésétől. A dokumentálás, részletes tesztelés, hatáselemzés utólag elvégezendő A változtatások hatásait elemezni kell. Külső szolgáltatóhoz kapcsolódó változtatási folyamatok Abban az esetben, amennyiben a változtatást az intézmény kezdeményezi külső szolgáltató rendszerén, a létrehozás kivételével minden folyamatot be kell tartani Abban az esetben, amennyiben a változtatást külső szolgáltató kezdeményezi rendszerkövetés vagy javítás miatt, a jóváhagyás, tesztelés, végrehajtás előkészítés, mentés, végrehajtás, elemzés az előírás Kiadás és üzembe állítás A kiadáskezelés célja a szolgáltatás tervezés során a változáskezelés eredményeként beszerzett, kialakított folyamatok, szoftverek, hardverek bevezetése, üzembe állítása. A szoftver kiadás lehet különbségi, amely csak a legutóbbi kiadás óta változott elemeket tartalmazza, és lehet teljes kiadás, mely során a szoftver/folyamat minden elemét együtt állítjuk üzembe. Teljes vagy jelentős kiadásnál alkalmazandó Projektmenedzsment (lásd a 1.1 fejezet) Konfigurálás F Hardver kiadások esetén meg kell tervezni az egyes elemek összeállítási módjait. F Hardver kiadások esetén tesztelni kell, hogy a tervezett konfigurációk megfelelnek-e az alkalmazások és a felhasználók által támasztott követelményeknek. F A rendszert a felhasználás igényei szerint paraméterezni, konfigurálni kell. F A paraméterezés teljes kiadások esetén a szállító feladata Összeállította a GYEMSZI szakértői munkacsoportja 86

91 F F F A paraméterezés része a rendszer szótárak létrehozása, panelek létrehozása, a rendszerből kinyerhető dokumentumok paraméterezése is. Szoftver kiadások esetén tesztelni kell a rendelkezésre álló hardver környezetben a szoftver működőképességét. Visszatérési eljárást kell tervezni, mely lehetővé teszi az esetleges sikertelen bevezetés után a korábbi helyzetbe történő visszatérést Kiadás elfogadása F A kiadás elfogadása csak sikeres teszt után történhet. Fejlesztői környezetből közvetlenül éles környezetbe kiadás nem vihető. F A tesztelésre az éles környezettel megegyező tesztkörnyezetet kell létrehozni. F A tesztelést a bevezetők és a felhasználók együttesen végzik. F Az összes funkciót tesztelni kell F Az integrációs kapcsolatokat tesztelni kell F A migrációt tesztelni kell F A biztonságot tesztelni kell F A terhelési teszteket a várható éles terhelésnek megfelelő értékek mellett kell végezni. F A tesztek során pontonként rögzíteni kell az eredményességet, eltérést, sikertelenséget F Hibás teszteredmény esetén az adott témakörre vonatkozó teljes tesztet eredménytelennek kell nyilvánítani. F Korábbi tesztek területeit érintő beavatkozás esetén a megelőző teszteket ismételni kell Telepítés tervezése F Ki kell dolgozni a telepítés fázisait F Meg kell határozni a telepítés felelőseit, feladataikat F Meg kell tervezni a migrálási eljárásrendet F Szükség esetén biztosítani kell a telepítés során a zavartalan munkavégzést/betegellátást F Biztosítani kell a telepítéshez szükséges infrastruktúrát parkolás, eszköztárolás, helyszíni támogatás feltételei F Biztosítani kell az oktatás tárgyi, helyiség és személyi feltételeit F Az oktatás beosztásáról, menetéről, tartalmáról tervet kell készíteni Oktatás F Az oktatások során minden kiadásban érintett felhasználót oktatni kell. F Az oktatást úgy kell szervezni, hogy az oktatás és az éles üzem között 2 hétnél hosszabb idő nem telhet el. F Az oktatások max. 12 fős csoportban végezhetők. F Az oktatások során minden hallgató részére külön gépet kell biztosítani F Az oktatások során minden hallgató részére oktatási anyagot kell biztosítani. F Az oktatás során minden olyan tevékenységet oktatni kell, amit az adott hallgató munkája során végezni fog. F Az oktatás időtartamának arányosnak kell lennie az oktatott anyag terjedelmével, és az oktatottat alkalmassá kell tennie a működtetésre. F Külön menedzseroktatást kell tartani a rendszert közvetlenül nem használó vezetők részére. F Olyan kulcsfelhasználókat is oktatni kell, akik a rendszert átfogóan ismerik, és Összeállította a GYEMSZI szakértői munkacsoportja 87

92 F F alkalmasak későbbi új felhasználók oktatására. Az oktatást számonkéréssel kell zárni. Teljes kiadás vagy nagyon jelentős különbségi kiadás esetén az éles indulást követően utólagos oktatást, utólagos konzultációt kell biztosítani Telepítés F Telepítés során a visszatérési eljárás előírásainak megfelelően biztosítani kell a korábbi állapot konzerválását F Az elfogadásnak megfelelő konfigurációk és szoftver telepíthető. F Az adatok migrálása az elfogadott migrálási eljárásnak megfelelő ellenőrzött forrás és eljárási algoritmus mellett történik. F Biztosítani kell, hogy a kiadott rendszer életbe léptetése minden területen egységesen a szükséges átmigrált éles adatokkal történjen. F A létrejövő éles rendszert a teszt rendszertől el kell különíteni, és biztosítani kell, hogy a két rendszert a továbbiakban ne lehessen együtt használni Ismeret menedzsment Az ismeretmenedzsment célja, hogy minden szereplő az adott területen és pillanatban elegendő információval, tudással, készséggel rendelkezzen. F Biztosítani kell az adott terület használatához szükséges oktatást F Biztosítani kell, hogy a használat során naprakész segédanyagok, Help a felhasználó rendelkezésére álljanak F Biztosítani kell a személyes támogatás rendszerét F A szereplő felkészültségét monitorozni kell F Biztosítani kell az ismerethiányok megszüntetését F Biztosítani kell az ismeretek felfrissítését F Biztosítani kell a változásokból adódó ismeretek elsajátítását Szolgáltatás validálás és tesztelés F A szolgáltatás bevezetés csak záró tesztek után zárható le F A záró tesztek során az éles rendszeren követni kell az éles üzem hibamenetes F működését A záró tesztek során vizsgálni kell, hogy a létrejött rendszer milyen szinten felel meg a tervezés során lefektetett elképzeléseknek Szolgáltatás üzemeltetés Eseménymenedzsment Az esemény egy olyan állapotváltozás, amely jelentőséggel bír az IT infrastruktúra vagy egy szolgáltatás biztosítása szempontjából. Egy esemény jelezheti azt, hogy valami nem működik megfelelően. Így egy esemény egy incidens kialakulásához vezethet. Esemény jelezhet előre normál, rutinszerű tevékenységet is. Az eseménymenedzsment célja a rendelkezésre állás és teljesítmény monitorozás számára az információ biztosítása. F F F F Az eseményeket csoportba kell sorolni úgy, mint informális események a normális működést dokumentáló, szokatlan események az általánostól eltérő, de nem incidens jellegű, incidensek a normálistól eltérő esemény Az eseményeket a rendszer teljes életciklusán keresztül kezelni kell Az események megjelenése eltérő típusú lehet, melyeket megfelelő interfészek segítségével kell az eseménymenedzsment részére feldolgozhatóvá tenni. Központi hardverek eseményeinek mérései: Szerver meghibásodási jelzések, hőmérsékleti jelzések, táblatér jelzések, tápellátási jelzések, újraindítások. Összeállította a GYEMSZI szakértői munkacsoportja 88

93 F Operációs rendszerek eseményeinek mérései: Meghibásodási jelzések, frissítések jelzései F Védelmi rendszerek eseményeinek mérései: Támadások jelzései, behatolási kísérletek jelzései, frissítések jelzései F Alkalmazói rendszerek eseményeinek mérései: Írás, módosítás, olvasás esetén: ki, mikor, mit. Hibák jelzései, frissítések jelzései F Rendszerek kapcsolatainak, mérései: Adatküldés, adatfogadás honnan hova, mikor, mit. Hibák jelzései. F Külső kommunikáció, mail rendszerek mérései: ki, mikor, mit, honnan hová. Hibák jelzései. Az eseményeket pl. naplókban úgy kell tárolni, hogy a tárolási idő megfeleljen a F vonatkozó jogszabályoknak. Például az egészségügyi adminisztrációs rendszer hozzáférés naplóit az egészségügyi adatvédelmi törvény szerint. F Az eseményeket úgy kell tárolni, hogy bármilyen elemzésre visszamenőleg is alkalmasak legyenek. Pl. jogosulatlan hozzáférés kimutatása bizonyító erejű módon. F Meg kell határozni az események feldolgozásának algoritmusát, és a kimeneti szinteket. F Kimenetek lehetnek: esemény rekord, incidens rekord, probléma rekord, automatikus válasz, riasztás Incidens menedzsment Az incidens egy olyan esemény, amely nem része a szolgáltatás normális működésének és annak megszakadását vagy minőségének romlását okozhatja. Az incidens hátterében lévő ok a probléma. Az incidenskezelés célja, hogy a szolgáltatás normális állapota a lehető leggyorsabban visszaállításra kerüljön úgy, hogy csökkentse ezáltal az incidens az egészségügyi szolgáltató működésére gyakorolt hatását. F Definiálni kell az adott rendszerre az incidens fogalmát. A nem saját fejlesztésű rendszerek/rendszerelemek esetén szerződés műszaki F mellékletében részletesen elő kell írni, hogy az adott rendszer mely funkcionalitással, milyen válaszidőkkel történő működése jelenti a rendszer normális működését, amelytől bármilyen eltérés incidensként azonosítandó. F Meg kell határozni, és mind a rendszerszállítókkal, mind a felhasználókkal el kell fogadtatni az incidensek besorolási rendszerét. Az incidensek besorolási rendszerének kialakításakor figyelembe kell venni az incidens hatását a rendszerre, az incidens kiterjedtségét, az érintett rendszerek F prioritását, az incidens hatását az SLA-ra. Például egészségügyi intézményeknél egy HIS rendszert alapszolgáltatásaiban érintő incidens prioritása és besorolása más, mint a gazdasági rendszert hasonló módon érintő incidens. F Az egyes incidens csoportokhoz hibaelhárítási időtartamokat kell előírni. F A hibaelhárítási időtartamoknak a következő részletezettségűnek kell lenni: észlelés, bejelentés, kezdet, befejezés, helyreállítás F A hibaelhárítási szakaszokhoz meg kell határozni a felelősöket és eljárásrendet. F Az incidens menedzsment részére bemeneti interfészt kell biztosítani az eseménymenedzsment felől. Az incidens menedzsmentnek kimeneti interfészt kell biztosítani a F problémamenedzsment, a konfiguráció menedzsment, a kapacitás menedzsment, a rendelkezésre állás menedzsment, a szolgáltatás szint menedzsment felé. F A nyilvántartást úgy kell megszervezni, hogy a kimenet (készre jelentés, megkerülés, stb.) szerint az incidens lezárást követő utóélete követhető legyen. Összeállította a GYEMSZI szakértői munkacsoportja 89

94 Ügyfélszolgálat F gépes hálózat felett ügyfélszolgálatot kell létrehozni. F Szoftver szállítóval szemben a működő ügyfélszolgálatot elő kell írni. Az ügyfélszolgálaton olyan hibajegykezelést kell alkalmazni, mely lehetővé teszi a F hiba megoldásának eseménykövetését, személyi követését, időpont követését, a szükséges statisztikák lekérését. F Szoftverszállító felé elő kell írni, hogy biztosítson olyan felületet, melyen az eseménykövetés megvalósítható. F Az ügyfélszolgálatot úgy kell felépíteni, hogy optimálisan kiszolgálja az adott feladatokat és az adott szervezetet. F Több telephelyes szervezet esetében amennyiben az egyes telephelyek elérik az ügyfélszolgálat alsó határát több szintű ügyfélszolgálatot kell létrehozni. F Meg kell határozni, hogy az egyes ügyfélszolgálati szintekhez milyen megoldási szintek tartoznak F Meg kell határozni az egyes ügyfélszolgálati szintek feladatait, kapcsolatait, felelősségét. Meg kell szervezni a szervezeten belüli értesítési rendet, mely tartalmazza az incidens F bejelentési rendet, a besorolás szerinti értesítési rendet, az állapot visszajelzések rendjét. F Meg kell határozni a külső/szállítói ügyfélszolgálatok felé történő kapcsolattartási rendet. F Külső/szállítói ügyfélszolgálat megléte esetén pontosan el kell különíteni a külső-belső felelősségi és tevékenységi köröket. F Kimenet lehet készre, megkerülés, problémajelentés, szolgáltatási szint jelentés Probléma menedzsment A problémamenedzsment célja, hogy az incidensek kiváltó okait megtalálja, illetve minimálisra csökkentse. F A hibajegy kezelő rendszernek alkalmasnak kell lennie, hogy az incidenst a problémakezelés igényeinek megfelelő pontossággal írja le F Biztosítani kell a lehetőséget a vélhetően azonos problémához köthető incidensek szűrésére, statisztikájára, behatárolására F Az incidenseket kategorizálni kell előfordulási gyakoriságuk, hatásuk szerint F A problémamegoldást a kategóriákhoz kapcsolódó prioritási sorrendben kell kezelni. F A probléma megoldására felelős személyt kell kijelölni, aki a problémát a hibajegy kezelő rendszer információi alapján és az előírt prioritási sorrendben kezelheti. F Amennyiben a problémamegoldás eredménye a rendszerben változást hoz létre, F alkalmazása során a változáskezelésnek megfelelően kell eljárni. Az problémamegoldás eredményéről, állapotáról az ügyfélszolgálat részére folyamatos információt kell szolgáltatni Kérésteljesítés menedzsment A kérésteljesítés menedzsment lehetőséget biztosít a rendszer szolgáltatásai keretén belüli olyan kérések szabályozott elbírálására és teljesítésére, melyek teljesítése a kérő jogosultsági szintjén kívül esik. (Pl. jogosultságok beállítása, funkciók hozzárendelése stb.) F F F F A kéréseket egységesített formába és nyilvántartásba kell szervezni Ki kell alakítani a kérések elbírálásának eljárásrendjét Ki kell jelölni az elbíráló, végrehajtó szereplőket Meg kell határozni a végrehajtási sorrendet alkotó prioritási rendet, és a hozzá tartozó Összeállította a GYEMSZI szakértői munkacsoportja 90

95 határidőket F A teljesített kérésekről meg kell szervezni az értesítési rendet Hozzáférés menedzsment A jogosult felhasználók számára biztosítja a szolgáltatás felhasználásának jogát, működését, amit a jogosulatlanoknak számára megtagad. F Személyazonosság megállapítása név + egyéb azonosító pl.: születési dátum, törzsszám, orvoskód stb. F Személyazonosság ellenőrzése minimum kettős azonosítással pl.: felhasználó név +jelszó, felhasználó név+biometrikus azonosító, chip kártya+jelszó stb. F Jelszó alkalmazása esetén az csak megfelelő biztonsági szintű lehet (eltérő betűméretek és számok egy jelszón belül) F A jelszó a felhasználó által megváltoztatható meghatározott időszakonként kötelező módon F A jelszavak nem tárolhatók visszafejthetően. A felhasználók részére szerepeket kell meghatározni. A szerepek lehetnek egyediek, csoportba sorolhatók, kiterjesztettek. Egy egészségügyi szolgáltatónál például jellemző F szerepcsoportok: orvos, ápoló/asszisztens, betegirányító, hr-es, pénzügyi, könyvelő, rendszergazda. Jellemző egyedi szerepek orvosvezető, gazdasági vezető, adatvédelmi felelős. F Lehetőséget kell adni, hogy egy személyhez több szerep is kapcsolható legyen F Vizsgálni kell az esetleges szerepkonfliktust, azaz ha egy személy több szerepe egymásnak ellentmondó F A szerepekhez jogosultságokat kell rendelni F A jogosultságoknak ki kell szolgálni a szerephez kapcsolódó minden tevékenységet a teljes/minden rendszerben. F A jogosultságoknak meg kell felelnie a szervezet belső szabályainak. Például a rendszergazda nem férhet hozzá védett adatokhoz. F A jogosultságoknak meg kell felelni az érvényes jogszabályoknak. Egészségügyi szolgáltatók esetében kiemelt az egészségügyi adatok kezelésre vonatkozó jogszabály. F A felhasználókat és jogosultságaikat egy nyilvántartási rendszerben/adatbázisban kell tárolni. F A felhasználók jogosultsági életciklusának idősorosan követhetőnek és megőrzöttnek kell lennie. F Tárolni kell a jogosultságot engedélyező és a kiadó azonosítóit. F A jogosultság igénylés lehet egyedi pl. az adott dolgozó további feladatot kap, és vezető igényel hozzá jogosultságot F A jogosultság igénylés lehet automatikus pl. új orvos belépése esetén a hr értesítése alapján orvos csoportba kerül. F A rendszert monitorozni kell, hogy az egyes jogosultságok folyamatosan megfelelnek a szerepköröknek. Meg kell határozni a jogosultsági életciklus felelőseit: igénylés, igény ellenőrzés, F jóváhagyás, beállítás, monitorozás, megvonás igénylés, megvonás jóváhagyás, megvonás beállítás. F Biztosítani kell a szerep megszűnése esetén a kapcsolódó összes jogosultság megszüntetését Folyamatos szolgáltatásfejlesztés A folyamatos szolgáltatás fejlesztés célja, hogy a rendszer szolgáltatásai minél jobban illeszkedjenek a változó felhasználói, műszaki környezeti követelményekhez. Összeállította a GYEMSZI szakértői munkacsoportja 91

96 F Ki kell dolgozni a mérési indikátor rendszert F Az indikátorokat monitorozni kell F A mérési eredményeket analizálva az illeszkedés mértékét elemezni kell F Az elemzés eredményeit felhasználva ajánlatot kell tenni a szolgáltatás tervezés felé a további fejlesztésekre Üzemeltetési szerződésmenedzsment F A szerződéseknek illeszkednie kell az egységes üzemeltetési rendszerbe F Üzemeltetési feladatok kiszervezése során figyelembe kell venni az érvényes jogi rendelkezéseket (pl. adatfeldolgozást szabályai) F Üzemeltetési feladatok kiszervezése során figyelembe kell venni a kockázatelemzés eredményeit F Üzemeltetési feladatokat csak úgy lehet kiszervezni, hogy a szolgáltatás folyamatossága biztosítva legyen esetleges soron kívüli szerződésbontás esetén is A szerződéseknek rendelkezni kell az alapvető tartalmi követelményekkel (felek, F időszak, tárgy, teljesítési feltételek, ellenszolgáltatás, késedelmes- hibás teljesítés definíció és következmény, dátum, aláírás) F A szerződésben szolgáltatási szint megállapodást kell kötni F Rögzíteni kell a rendelkezésre állás és a szolgáltatás folytonosságának tényezőit, követelményeit F Az üzemeltetési tevékenységnek meg kell felelnie a biztonságmenedzsment előírásainak F Az üzemeltetési tevékenységben résztvevőknek vállalniuk kell a biztonságmenedzsment előírásainak betartását F Tisztázni kell az esemény és incidens menedzsment felelősségi köreinek elhatárolásait Tisztázni kell az esemény és incidens menedzsment körébe eső eseményeket, azok F kezelésének, megoldásának felelőseit, határidejét, következményeinek viselőjét, annak mértékét F Meg kell határozni az ügyfélszolgálattal szembeni elvárásokat F Meg kell határozni az együttműködési kereteket, eljárásrendet a kérésteljesítés területein és a probléma menedzsment kérdéskörében F Tisztázni kell a hozzáférés feltételeit, eljárásrendjét Összeállította a GYEMSZI szakértői munkacsoportja 92

97 Pályázati és megvalósítási követelmények 5 A fejlesztési pályázat és a megvalósítási projekt követelményei, minősítése Ebben a fejezetben azokat a követelményeket foglaltuk össze, amelyek egy pályázat sikeres elkészítéséhez, illetve a fejlesztés eredményes megvalósításhoz szükségesek. A tervezett vagy célba vett fejlesztés sikeressége döntő mértékben függ a befogadó (kedvezményezett) intézmény felkészültségétől. Ez számos részterület megfelelő előkészítettségétől is függ. Nemcsak a szorosan vett informatikai felkészültséget kell számba venni, hanem legalább olyan fontos az intézmény egyéb területeken (menedzsment, kulcsszakemberek, projektmenedzsment szakemberek, erőforrások stb.) való felkészültsége is. Igyekeztünk a követelmények szempontjait úgy összeállítani, hogy azok legalább utalás szintjén tartalmazzák mindazon elemeket, amelyek megléte és teljesülése fontos kihatással lehet mind a pályázás, mind a fejlesztés (projektmegvalósítás) sikerére. A gyakorlat azt mutatja, hogy az intézmények gyakran nem fektetnek kellő hangsúlyt arra, hogy a saját erőforrásaik (és itt nem csak a pénzügyiket értjük) elengedőek-e egy pályázat és az azt követő projekt végig vitelére. A fejezet első része az intézmény felkészültségének sarokpontjait tekinti át. Itt arra hívjuk fel a figyelmet, hogy a tervezett fejlesztés sikere már onnantól befolyásolható pozitív irányban, amikor ennek az intézményen belüli helyét pontosan meghatározzák. A fejlesztés helye alatt nem elsődlegesen a földrajzi elhelyezkedést értjük (bár gyakran az is nagyon lényeges ), hanem olyan területeket, mint többek között alternatívaelemzés prioritások meghatározása a jelenlegi helyzet pontos felmérése megvalósíthatósági vizsgálatok pénzügyi-gazdasági elemzések fenntarthatósági elemzések környezeti elemzések a fejlesztés leírása és pontos definiálása az intézmény menedzsmentje és felhasználói számára is a megfelelő szakemberek (informatikai, gazdasági, szakterületi stb.) rendelkezésre állása az intézmény informatikai kultúrája Szeretnénk ebben a részben még rávilágítani az ún. Megvalósíthatósági tanulmány fontosságára, szükségességére. Ezen tanulmány alatt sokan sokféle tartalmat és szempontok elemzését értik, a fejezet szempontrendszerében ezeket kibontva szerepeltetjük. A megvalósíthatósági tanulmány elkészítésének célja, hogy megfelelő információt nyújtson a döntéshozók számára ahhoz, hogy azok megalapozott döntést tudjanak hozni a finanszírozásra és a megvalósítandó projekt elfogadásáról, módosításáról, illetve elvetéséről. Összeállította a GYEMSZI szakértői munkacsoportja 93

98 Pályázati és megvalósítási követelmények A megvalósíthatósági tanulmány feladata a végrehajtandó fejlesztés megalapozottságának és életképességének vizsgálata. A tanulmány elkészítésének eredménye a javasolt projekt relevanciájának, megvalósíthatóságának és fenntarthatóságának értékelése. A második részben a fejlesztést megvalósító beszállító felkészültségére vonatkozóan fogalmaztunk meg követelményeket. A nagyobb fejlesztések legtöbbször szigorú közbeszerzési szabályok keretei között zajlanak, de nem árt már előre felkészülnie az intézménynek, hogy milyen szempontok szerint minősítsen, illetve válasszon beszállítót. Noha az ár döntő lehet, de a különböző ajánlatok megfelelőségének (azaz az intézmény céljaihoz és prioritásaihoz való minél nagyobb fokú illeszkedésnek) elbírálása legalább ilyen lényeges. Számos esetben az ajánlattevők ajánlanak valamit, aztán majd utólag, plusz pénzért hozzáfejlesztik az intézmény igényeihez. Többek között ezt a beszállítói gyakorlatot megelőzendő állítottuk össze a követelményrendszerünk ezen pontjait. A teljesség igénye nélkül a legfontosabb ilyen szempontok: a beszállító szakembereinek (menedzsment, kiemelt szakértők, fejlesztők stb.) felkészültsége a beszállító, mint szervezet felkészültsége (szerepkörök, kompetenciák) a beszállító tervezett (és rendelkezésre álló) erőforrásai a fejlesztés időütemezése az ajánlathoz való illeszkedés kérdései a javasolt megoldás részletezettsége (funkcionális, technológiai, pénzügyi stb.) a javasolt megoldás érthetősége (különböző szintű, az intézmény különböző felhasználói rétegének szóló ismertetés) A harmadik részben a tervezett fejlesztés teljes folyamatának szempontrendszerét adjuk meg.a teljesség alatt azt értjük, hogy az előkészítés (tervezés) o A folyamatok, a szervezet és a működés átvilágítása; o Szervezeti, működési koncepció és folyamatmodell kialakítása; o Üzleti folyamatok kialakítása, átalakítása, szabályozása, bevezetése; o Komplex vállalati folyamatmenedzsment-rendszer tervezése,bevezetése; o Kialakított/átalakított folyamatok auditja; o Informatikai rendszer bevezetéséhez kapcsolódó folyamatkialakítás és szabályozás. a kialakítandó - különös tekintettel a szoftverfejlesztésről szóló - szerződés (illetve több, egymáshoz kapcsolódó esetben a szerződésháló) a projektindítás (projektalapítás) a megvalósítás az előállított termék (a fejlesztett rendszer) megfelelősége és a megvalósítást követő időszak (garancia) kérdéseivel is foglalkozunk. A fejlesztés előkészítése kapcsán külön hangsúlyozzuk a BPM és BPR (busines process modelling és reengineering) szükségességét. Ezeknek az elmaradása okozza az informatikai fejlesztések bukásának talán legnagyobb részét. Egy informatikai fejlesztés előkészítéséhez jó Összeállította a GYEMSZI szakértői munkacsoportja 94

99 Pályázati és megvalósítási követelmények alapot ad az intézmény folyamatainak, működésének feltérképezése, legtöbbször valamilyen célszoftverrel történő informatikailag feldolgozható, bementként használható - grafikus megjelenítése, modellezése (BPM). A folyamatok felmérése döntheti el azt a kérdést, hogy részben vagy teljesen újra kell-e gondolni az intézmény fejlesztéssel kapcsolatos működését, azaz teljes mérnöki újratervezés (BPR) vagy csak a jelenlegi folyamatok elemzésén alapuló részleges és fokozatos javítás (Business Process Improvement - BPI) szükséges. A kedvezőtlen feltételekkel megkötött szerződések kiszolgáltatott helyzetbe hozhatják az intézményeket a szerződéses partnerekkel szemben. Ez egyrészt a vállalkozók monopolhelyzetbe kerülésével gazdasági hátrányt okozhat az intézményeknek. Másrészt akadályozhatja a szervezetek technológia váltását, vagy birtokba kerülését a saját rendszereik vonatkozásában. Ezen helyzetek elkerülése érdekében a fejezet későbbi részében részletezettszempontok beépítése szükséges a szoftvervásárlással és a rendszerfejlesztéssel kapcsolatos szerződésekbe. A szerződésekbe épített elvárásoknak összhangban kell lennie a szerzői jogról szóló törvény szerződéskötéskor érvényes 175 állapotával. 5.1 Az intézmény felkészültségének követelményei A fejlesztés elhelyezése az intézmény működésében G G G G G G G G G G G A fejlesztést megelőzően készült Megvalósíthatósági tanulmány. A fejlesztési specifikáció rendszerelemzési és tervezési módszertan szerint készült Megtörtént azoknak a szükségleteknek a vizsgálata, amelyre a fejlesztési projekt reagál, a fejlesztést megelőzően készült követelmény elemzés. Az intézmény/kedvezményezett elkészítet(t)ette a fejlesztés lehetséges alternatíváit (pl. minimális, közepes, maximális verzió) A fejlesztési alternatívák összehasonlító elemzése elkészült, a tervezett alkalmazások és az informatikai felhasználásukban rejlő lehetőségek felderítése megtörtént Rendszerszervezési alternatívák felállításra kerültek. A fejlesztési projekt megvalósításának elemzése megtörtént (a megvalósítás költséghatékony módon kerül kialakításra; a tevékenységekhez kapcsolódó kockázatokat feltárták, menedzselésük biztosított) A fejlesztés kapcsán meghatározásra kerültek a prioritások (szakmai, intézményi, informatikai stb.) Az egyes fejlesztési alternatívákat megalapozó/megerősítő tanulmányok/állásfoglalások rendelkezésre állnak (szakmai, menedzsment, informatikai stb. Hierarchikus rendszer kerül megvalósításra, benne ellenőrzési, döntési, módosítási pontokkal, hogy a fejlesztés a tervezett időre megvalósuljon. Előzetes pénzügyi elemzés készült (költségvetés megalapozottságának és realitásának évi LXXVI. törvény a szerzői jogról Összeállította a GYEMSZI szakértői munkacsoportja 95

100 Pályázati és megvalósítási követelmények G G G G G G G G G G G G G G G G G G G vizsgálata, a projekt pénzügyi érzékenység vizsgálata, pénzügyi-gazdasági megtérülés kiszámítása stb.) A fejlesztés környezeti hatásvizsgálata megtörtént. A fejlesztés társadalmi-gazdasági hatásainak felmérésére megtörtént. A fejlesztési specifikáció tartalmaz összefoglaló, vezetői oldalt A fejlesztési specifikáció tartalmazza a jelenlegi helyzet pontos leírását. A fejlesztési specifikáció tartalmazza az elérendő célok pontos megjelölését, meghatározását (követelmény specifikáció) A fejlesztési specifikáció a felhasználók igényeit kielégítő rendszert ír le, számukra grafikus ábrákkal érhetővé, áttekinthetővé válik a fejlesztési tevékenység eredménye. A követelmény központúság lehetővé teszi a felhasználó bevonását a projekt tevékenységébe. A fejlesztési specifikáció tartalmazza a fejlesztés bemutatását több lépésen keresztül (pl. egyre szűkülő, részletesebb ismertetéssel, helikopter nézettől az egyre eszköz közelibb nézetekig alrendszerekre, funkciókra, folyamatokra bontás fokozatos építkezés). A fejlesztés logikai elemei (mi fog történni az új rendszerben - a rendszer működésének belső logikája) és a fizikai elemei (hogyan, milyen eszközökkel) jól elkülönülnek a fejlesztési specifikációban Készült logikai rendszerspecifikáció. A rendszer által kezelendő információknak ismert a szerkezete (logikai adatszerkezet), és ez megfelelő a későbbi modellezéshez. Készült magas szintű adatfolyam leírás/ábra. Pontosan előírtak a tesztelési és átvételi követelmények, azaz a beszállító előre tudja, hogy a kiírt specifikációt megvalósító fejlesztés milyen eljárásrenddel és tartalommal lesz ellenőrizve és átvéve A dokumentumokra vonatkozó előírások a teljességet biztosítják, így a fejlesztési dokumentációból kiderülnek az intézmény szándékai. A fejlesztés végleges koncepciója, részletes leírása és technikai specifikációja az alternatívák összehasonlítása/elemzése után összeállításra került és ezt a menedzsment jóváhagyta. A fejlesztést megelőzően készült Fenntarthatósági tanulmány. A kiíró/kedvezményezett rendelkezik átgondolt kommunikációs tervvel a fejlesztés és annak eredményei ismertetésével a saját felhasználói, illetve külső partnerek felé. Az intézmény saját képességeinek felmérése megtörtént (elegendő szakmai kompetencia, fejlesztési projektmenedzsment tapasztalat, kellő számú a projektre dedikált szakember megléte és rendelkezésre állása, milyen területen kell külső szakértelmet igénybe venni stb.). A belső erőforrás felmérés alapján a tervezett fejlesztés szerkezete (egyetlen megoldásszállító részben külső projektmenedzsmenttel vs. több, egymástól független szállító erős belső koordinációval, belső projektmenedzsmenttel) kialakításra került. A fejlesztés kedvezményezett oldali irányításához szükséges vezető szakemberek (belső menedzsment, IT oldali projektvezető stb.) kiválasztásra kerültek, és felmentést Összeállította a GYEMSZI szakértői munkacsoportja 96

101 Pályázati és megvalósítási követelmények G G G G kaptak a fejlesztés idejére egyéb tevékenységeik végzése alól. A fejlesztés kedvezményezett oldali irányításához szükséges kulcsszakemberek (kulcsfelhasználók, a fejlesztésben kiemelt területek képviselői stb.) kiválasztásra kerültek, és felmentést vagy könnyítést kaptak a fejlesztés idejére egyéb tevékenységeik végzése alól. A fejlesztésben részt vevő (kulcs)szakemberek száma elegendő. Az intézmény rendelkezik azokkal a forrásokkal és képességekkel, amelyek a fejlesztést megelőző, illetve a fejlesztéssel együtt járó szervezeti átalakításokhoz kellenek (további elsősorban IT szakemberek felvétele, projektmenedzserek stb.) Az intézmény/kedvezményezett szakemberei hatékony segítségre képesek a fejlesztés/fizikai rendszertervezés szakaszában is Intézményi követelmények a fejlesztés előkészítésére G A fejlesztés kedvezményezettje rendelkezik informatikailag képzett felhasználókkal. G Az informatikai eszközök használata megtalálható az intézmény fejlesztésben érintett egységeinél. G Az intézményi menedzsment elkötelezett az IKT megoldások mellett, az új fejlesztések előnyeit, kedvező hatásait ismeri. G A fejlesztés koncepciója, főbb elemei ismertek, a kiírónál/kedvezményezettnél előkészített a befogadása emberi tényezők tekintetében. G A felső vezetés információs igényei pontosan meghatározottak, és ezeket a fejlesztendő rendszer ki fogja szolgálni. G Az információ-menedzselés szerkezete pontosan megtervezett, ismert. G Az intézmény orvosai (szakemberei) használnak IKT megoldásokat más orvossal (egymás között) való elektronikus információcserére G Az intézmény elérhető elektronikus úton a betegek, páciensek, ügyfelek számára (elektronikus ügyintézés) G Az intézmény rendelkezik rendszeresen frissített honlappal (egészségügyi szolgáltatás lista, ki-kicsoda, elérhetőségek, intézményi profil, külső kapcsolatok lehetősége) G Az intézmény rendelkezik intranettel, ami naprakész információkat ad a saját felhasználóknak (intézményi belső információkkal, menedzsment információkkal) G A beszállító üzleti szereplők és az egészségügyi szolgáltató/intézmény kapcsolatrendszere alapvetően IKT megoldásokon alapul G A projektet végrehajtó intézmény szervezeti, pénzügyi és humán erőforrás-oldali felkészültségének felmérése megtörtént. G Az intézmény fejlesztésben érintett dolgozói képesek a fejlesztési igényeiket informatika közeli szemléletmódban megfogalmazni. G Az intézményi folyamatok informatikai támogatottsága pontosan ismert, felmért és követhető. G Az informatikai fejlesztést megelőzően történt szervezetfejlesztési felmérés. G A szervezetfejlesztési lépések informatikailag is megalapozottak, tervezettek. G A fejlesztések, alkalmazások támogatják az alapvető orvosi/egészségügyi Összeállította a GYEMSZI szakértői munkacsoportja 97

102 Pályázati és megvalósítási követelmények G G G G G G G G G G tevékenységeket. A tervezett fejlesztés ismert és elfogadott a felhasználói/orvosi körökben. A kórházi/intézményi informatika intézeti és osztályos szinten is felelős koordinátor kinevezése mellett van kialakítva és működtetve. A bevezetendő informatikai rendszerek követése, támogatása biztosított. Kellő számú és rendelkezésre állású informatikai rendszergazda segíti a felhasználók munkáját. Az intézmény rendelkezik magasan képzett, mind az orvosi szakmában, mind az informatikában elfogadott IT vezetővel. Az intézmény rendelkezik megfelelő számú és megfelelően képzett szakértői munkatárssal (informatikai kulcsfelhasználók) Az informatikai rendszerek felhasználóbarát módon segítik a felhasználók tevékenységét. A felhasználók részesültek, illetve részesülnek célirányos, megfelelő informatikai (tovább)képzésekben. Az információs rendszer adataihoz való hozzáférések kérdései tisztázottak, szabályozottak. Az IKT megoldások támogatják a felhasználók kutatási tevékenységeit (adatbányászati lehetőségek, speciális IT munkahely) 5.2 A beszállító felkészültségének és ajánlatának követelményei Beszállítói követelmények G G G G G G G A beszállító menedzsmentjének (vezető tisztségviselői) képzettsége (a szakmai CV-k alapján) és az eddigi projektvezetési tapasztalatai biztosítékot jelentenek a fejlesztés beszállító oldali sikeréhez. A beszállító teljesítésébe bevonni kívánt szakemberei (szervezetei), illetőleg vezetői képzettsége és összetétele megfelelő. A beszállító minőség ellenőrzésbe bevonni kívánt szakemberei (szervezetei), illetőleg vezetői képzettsége és összetétele megfelelő. A beszállító szervezeti és személyi szerepkörei, kompetenciái világosak, azok kapcsolódása a meglevő szervezethez tisztázott. A beszállító megfelel a fejlesztésbe bevonni kívánt szakemberei képzettségére (67..) vonatkozó közbeszerzési előírásoknak, és benyújtotta az ott előírt igazolásokat, dokumentumokat. A beszállító megfelel a közbeszerzési törvényben a gazdasági, illetőleg szakmai tevékenységével kapcsolatban (60..) előírtaknak, azaz rá a kizáró okok egyike sem áll fenn A beszállító megfelel a közbeszerzési törvényben a személyi feltételek és a kamarai/szervezeti tagságra vonatkozó (61..) előírtaknak (beleértve a közbeszerzés értékének 10 %-át meghaladó mértékben igénybe venni kívánt alvállalkozót vagy a szerződés teljesítéséhez erőforrást nyújtó szervezetet), azaz rá a kizáró okok egyike sem áll fenn Összeállította a GYEMSZI szakértői munkacsoportja 98

103 Pályázati és megvalósítási követelmények G G G G G G G G G G G G A beszállító megfelel a közbeszerzési törvényben a szakmai kötelezettségszegést vagy szakmai etikai szabályokba ütköző cselekedetre, illetve adatszolgáltatásra (62..) előírtaknak (beleértve a közbeszerzés értékének 10 %-át meghaladó mértékben igénybe venni kívánt alvállalkozót vagy a szerződés teljesítéséhez erőforrást nyújtó szervezetet), azaz rá a kizáró okok egyike sem áll fenn A beszállító benyújtotta a közbeszerzési törvényben előírt igazolásokat és írásbeli nyilatkozatokat (63..), azaz rá a kizáró okok egyike sem áll fenn A beszállító megfelel a pénzügyi és gazdasági alkalmasságára (66..) vonatkozó közbeszerzési előírásoknak, és benyújtotta az ott előírt igazolásokat, dokumentumokat. A beszállító megfelel a műszaki-technikai alkalmasságára, felszereltségére a fejlesztésbe bevonni kívánt szakemberei képzettségére (67..) vonatkozó közbeszerzési előírásoknak, és benyújtotta az ott előírt igazolásokat, dokumentumokat. A beszállító referenciái (a fejlesztés nagyságrendjével összhangban legalább az előző 1-3 évre visszamenőleg) megfelelőek. A beszállító által a minőség biztosítása érdekében tett intézkedések megfelelők. A beszállító rendelkezik elismert (bármely nemzeti rendszerben akkreditált) tanúsító szervezettől származó tanúsítvánnyal (pl. a szállítandó termék(ek)re, szolgáltatásokra stb.) A beszállító termelési képességei, illetőleg vizsgálati és kutatási eszközei megfelelők. A beszállító által a megvalósításra szánt idő, és annak felosztása (munkaszakaszok, mérföldkövek, részteljesítések, leszállítandó termékek stb.), időütemezése megfelelő. A beszállító által a megvalósítás időütemezésében a belső, logikai kapcsolatok egyértelműek, indokoltak. A beszállító által a megvalósításba bevonandó erőforrások rendelkezésre állása megfelelő, összhangban van az időütemezéssel. A beszállító által a megvalósítással kapcsolatos lehetséges kockázatok bemutatottak, a kockázatkezelés módja megfelelő Az ajánlott megoldás illeszkedése a kiíráshoz G G G G G G Az ajánlat a kiírásban megfogalmazott formai követelményeknek megfelel (példányszámok, kötetek, fűzöttség, lezárás, oldalszámozások, tartalomjegyzék, aláírások, módosítások, igazolások, azonosító stb.) Az ajánlat megfelel a bevonni kívánt alvállalkozókra vonatkozó előírásoknak (10% fölöttiek, elérhetőségek, a közreműködés aránya és része a megvalósításban). Az ajánlat tartalmazza az ajánlattevő fő tevékenységeinek, szervezetének rövid bemutatását. Az ajánlat tartalmazza az ajánlattevő informatikai piaci helyzetének rövid bemutatását, a szolgáltatás portfolióját és az ügyfélkörét. Az ajánlat tartalmazza annak bemutatását, hogy a fejlesztés megvalósítása hogyan illeszkedik az ajánlattevő képességeihez, eddigi tevékenységeihez, szállítási/szolgáltatási portfóliójához. Az ajánlat kellően alátámasztja, hogy az ajánlattevő gazdasági-pénzügyi helyzete stabil, különös tekintettel a kiírásban megjelölt fizetési módozatokra, feltételekre, határidőkre (pl. utólag fizetés, fizetési határidők, teljesítési szakaszok, a teljesítés ellenértékhez jutás periodicitása stb.) Összeállította a GYEMSZI szakértői munkacsoportja 99

104 Pályázati és megvalósítási követelmények G G G G G G G G G G G G G G G G G G Az ajánlat tartalmazza az ajánlott megoldás magas szintű üzleti koncepcióját. A magas szintű üzleti koncepció tartalmazza a szállítandó eszközök, berendezések megfelelőségének bemutatását a kiírásban foglaltakhoz képest. A magas szintű üzleti koncepció tartalmazza a szállítandó eszközök, berendezések megfelelőségének bemutatását a kiírásban foglaltakhoz. A magas szintű üzleti koncepció tartalmazza a nyújtani kívánt szolgáltatás magas szintű meghatározását, illeszkedését a kiíráshoz, annak fő elemeihez (részletezés, modularitás, súlyponti részek stb.) A magas szintű üzleti koncepció tartalmazza, hogy a szállítandó eszközök, berendezések hogyan támogatják a fejlesztendő rendszer funkcionalitását, illeszkedését a fejlesztendő részekhez, (al)rendszer(ek)hez, kapcsolódását más funkcionális részekhez. A magas szintű üzleti koncepció tartalmazza, hogy a fejlesztendő rendszer hogyan illeszkedik a kiírónál/kedvezményezettnél már meglévő rendszerhez, vagy egyes önálló elemeihez. A magas szintű üzleti koncepció tartalmazza, hogy a szállítandó eszközök, berendezések, a fejlesztendő rendszer és a kialakítandó szolgáltatásai hogyan teljesítik a kiíró/kedvezményezett fő célkitűzéseit. A magas szintű üzleti koncepció tartalmazza, hogy a szállítandó eszközök, berendezések, a fejlesztendő rendszer és a kialakítandó szolgáltatásai hogyan segítik elő a kiíró/kedvezményezett szervezeti/emberi erőforrás fejlődését, korszerűsödését. Az ajánlat tartalmazza az ajánlott megoldás részletes leírását. Az ajánlat tartalmazza a fejlesztendő rendszer - beleértve annak szolgáltatásait is - részletezett, fontosabb üzleti funkcionalitásait. Az ajánlat tartalmazza, hogy a fejlesztendő rendszer - beleértve annak szolgáltatásait is - milyen módon teljesíti a pályázati kiírásban meghatározott minimum felhasználói követelményeket. Az ajánlat tartalmazza a fejlesztendő rendszer - beleértve annak szolgáltatásait is - részletezett, műszaki alapjait (gépek, eszközök, rendszerösszetevők, hálózatok stb.) A műszaki leírás megfelelő részletességgel mutatja be a hardver architektúra rendszerét és elemeit, ezek elhelyezkedését. A műszaki leírás megfelelő részletességgel mutatja be a hardver architektúrán belül a legfontosabb erőforrások (szerverek, központi eszközök) kialakítását, teljesítményét, paramétereit. A műszaki leírás megfelelő részletességgel mutatja be a hardver architektúrán belül a felhasználói (kliens) gépeket, eszközöket, ezek teljesítményét, paramétereit. A műszaki leírás megfelelő részletességgel mutatja be a felhasználói (kliens) oldali követelményeket. A műszaki leírás megfelelő részletességgel mutatja be a hardver architektúra elemei működéséhez szükséges környezet (áramellátás, terhelési adatok, hőmérséklet, biztonság stb.) jellemzőit. A műszaki leírás megfelelő részletességgel mutatja be, hogy a hardver architektúra milyen módon felel meg a telepítendő/fejlesztendő szoftver architektúrának. Összeállította a GYEMSZI szakértői munkacsoportja 100

105 Pályázati és megvalósítási követelmények G G G G G G G G G G A műszaki leírás megfelelő részletességgel mutatja be a szoftver architektúrán belül a legfontosabb részeket (al- vagy/és szakrendszerek, modulok, front- és back-office, a fejlesztendő adatbázisok), ezek kapcsolódásait, közös működését. A műszaki leírás megfelelő részletességgel mutatja be a szoftver architektúrán belül a legfontosabb részeket teljesítményét, főbb jellemzőit, és hogy ezek hogyan felelnek meg a felhasználói igényeknek, nagyságrendnek. A műszaki leírás megfelelő részletességgel mutatja a dobozos termékeket és a fejlesztendő szoftvereket, illetve gazdaságossági megfontolásokkal - alá is támasztja, hogy mikor melyiket választaná a fejlesztő/szállító. A műszaki leírás megfelelő részletességgel mutatja az adatkezelés rendszerét (archiválás, adat-elérhetőség, adatmentés, adatbiztonság, adatvédelem stb.) A műszaki leírás megfelelő részletességgel mutatja be a szükséges üzemeltetési környezetet, annak folyamatait, szolgáltatásait. A műszaki leírás megfelelő részletességgel mutatja be a telepítendő/fejlesztendő szoftverekre a licencelést. Az ajánlat tartalmaz pénzügyi tervet (beruházási és költségterv, bevételek (ha tervezettek), saját, illetve bevonandó pénzügyi források ismertetése, az ajánlott pénzügyi feltételek illeszkedése a kiíráshoz) Az ajánlat részletesen bemutatja a tesztelés folyamatát, dokumentálását. Az ajánlat tartalmaz migrálási, adatáttöltési tervet, és a régi rendszerről amennyiben ilyen létezik az újra való átállás tervét (tesztrendszer működtetése, párhuzamos működtetés, éles üzem, határidők stb.). Az ajánlat kitér a változáskezelés folyamatára. Összeállította a GYEMSZI szakértői munkacsoportja 101

106 Pályázati és megvalósítási követelmények 5.3 A fejlesztés előkészítésének, megvalósításának és eredményének, követésének követelményei A fejlesztés előkészítésének tervezési feladatai és módszerei G G G G G G G G G G G G G G G G G G G G A problémaelemzés megtörtént (az intézmény főbb problémáinak azonosítása, ezek közötti ok-okozati összefüggések meghatározása, logikai hierarchia, probléma-fa elkészítése). A célok meghatározása megtörtént (eszközök és célok rendszere, cél-fa elkészítése) A stratégiaelemzés megtörtént (beavatkozások, megoldási lehetőségek, módszerek megvalósíthatósága) Készült logikai keretmátrix. Definiálásra kerültek a fejlesztés átfogó céljai (stratégiai szintű célok, amelyekhez a projekt hatásai hosszú távon hozzájárulnak). A fejlesztés célja ki lett tűzve (eredményszinten jelentkező - a fejlesztés megvalósításával közvetlenül elérendő - konkrét cél). A fejlesztés eredményei (a fejlesztés keretében végrehajtott tevékenységek termékei - outputok) meghatározásra kerültek. Az eredmények elérése érdekében végzendő tevékenységek meghatározása megtörtént. Az előfeltételek, feltételezések és kockázatok elemzése megtörtént (kockázatkezelési terv). Előre definiálásra kerültek azok a folyamatok, amelyeket a fejlesztés érint. Megtörtént a fejlesztés részfolyamatokra bontása, a részfeladatokhoz tartozó elvégzendő tevékenységek meghatározása, a közöttük levő összefüggések megtervezése. A javítandó (BPI) vagy átalakítandó folyamatok (BPR) valamilyen folyamat modellezési szoftverrel megjelenítettek, úgy, hogy azokat a későbbi informatikai fejlesztés bemeneti oldalon használni tudja (BPM). A (rész)folyamatok felhasználói és a felhasználás helyei pontosan ismertek, feltérképezettek A (rész)folyamatok során kezelt adatok (adatcsoportok, adatelemek) számossága és összefüggései pontosan meghatározottak. A folyamatfejlesztési tevékenységeknek illeszkednek a szervezeti stratégiához, azaz ez a gyakorlatban a stratégia megvalósítását támogatja. A tevékenységekhez tartozó erőforrás és időbecslések elkészültek. A feladatok kivitelezőinek (kompetenciák és felelősségek mátrixa) meghatározása megtörtént. o A mérföldkövek meghatározásra kerültek. o A kritikus út meghatározásra került. G5-019 Készült kommunikációs terv. Összeállította a GYEMSZI szakértői munkacsoportja 102

107 Pályázati és megvalósítási követelmények G G G G G G G G Fenntarthatóság elemezés készült (SWOT - Strengths, Weaknesses, Opportunities and Threats Erősségek, gyengeségek, lehetőségek és veszélyek, vagy SEPT - Social, Economic, Political and Technological Társadalmi, gazdasági, politikai és műszaki analízis) Objektíven ellenőrizhető mutatók (indikátorok) kerültek meghatározásra. Az átfogó célok mérésére definiáltak a hatásindikátorok. A konkrét cél mérésére definiáltak az eredmény indikátorok. A fejlesztés eredményének mérésére definiáltak az output indikátorok. A definiált indikátorok minőségileg alkalmasak (SMART kritériumrendszer - Specific, Measurable, Available, Relevant és Timebound) a számszerű mérésre. A mutatók mérésére megfelelő ellenőrzési, információgyűjtési eszközrendszer került kialakításra. Készült a befektetés amennyiben ilyen van - megtérülését alátámasztó pénzügyi elemzés (business case) A Projekt Alapító Dokumentum követelményei G G G G G G G G G G G G G G G G G Készült projektalapító dokumentum PAD (a rendszertől elvárt funkciók rögzítése, az adatokra vonatkozó követelmények meghatározása, a minőség mérését számszerűsítő adatok indikátorok, mutatók - meghatározása) A PAD tartalmazza a fejlesztés főbb adatait, besorolását, célját, helyszínét. A PAD bemutatja a fejlesztés időtartamát, ütemezését, logikai hálóját. A PAD tartalmazza a fejlesztés költségtervét (költségvetését), tervezett beszerzéseit. A PAD kellő részletességgel ismerteti a fejlesztés szereplőit és szervezetét. Bemutatásra kerül a PAD-ban a különböző szereplők (érdekeltek, szponzorok, felhasználók stb.) követelményei és elvárásai, üzleti igényei. A PAD meghatározza a Projekt Irányító Bizottságot, összetétele és működésrendje alkalmassá teszi a fejlesztés irányítására. A projektigazgató személye (szakmai és emberi képességek) megfelelő. A projektmenedzser(ek) személye (szakmai és emberi képességek) megfelelő(ek). A fejlesztés minőségbiztosítása kialakításra került. A fejlesztés egyes területeit felügyelő, irányító egységek (munkacsoportok, bizottságok) kialakításra kerültek (pl. pénzügyi, kommunikációs, informatikai, oktatási, szakmai stb.) A fejlesztést támogató projekt titkárság felállításra került. Az iratok kezelése, megőrzése szabályozott. Meghatározásra került a fejlesztés környezete : kapcsolódás más programokhoz, projektekhez; a tevékenységek függőségei. Kialakításra kerültek a beszállító részéről is a projektszervezet elemei. A PAD számba veszi a kezdeti kockázatokat, feltételezéseket és ismert korlátozó tényezőket A PAD-ban részletesen szabályozott a fejlesztés pénzügyi eljárásrendje. Összeállította a GYEMSZI szakértői munkacsoportja 103

108 Pályázati és megvalósítási követelmények G G G G G G G G A PAD-ban szerepelnek a fejlesztés pénzügyi megvalósításának és ellenőrzésének emberi erőforrásai. A PAD részletesen szabályozza a fejlesztés pénzügyi megvalósítását (források biztosítása, kötelezettség vállalás, szerződéskötés megrendelés, szerződésmenedzsment, számlakifizetés rendje A PAD-ban szabályozásra került a jelentési rend (heti, havi, előrehaladási, záró stb.). A PAD-ban szabályozásra került a beszerzett eszközök tulajdonjoga, nyilvántartásba vétele, leltározása, átruházása. A PAD tartalmazza a fejlesztés leírását. A PAD tartalmazza az alkalmazás szint ismertetését. A PAD tartalmazza a megosztott, közös erőforrások és szolgáltatások szint ismertetését. A PAD tartalmazza az infrastruktúra közmű (IT és kommunikációs) ismertetését A fejlesztéssel kapcsolatos szerződés(háló) kialakításának követelményei G G G G G G G G G G G G G A beszállítói szerződés összhangban van a megvalósítás ütemezésével, szakaszaival, belső összefüggéseivel. A beszállítói szerződés egyértelműen definiálja a teljesítés határidejét, annak módosítására vonatkozó eljárásrendet. Egyértelműen definiált a szerződés tárgya. A beszállítói szerződés egyértelműen rögzíti a szerződéses árat (nettó és áfa tartalom). A beszállítói szerződés egyértelműen szabályozza a teljesítésigazolás módját (benyújtandó termékek, bizonylatok, alaki és tartalmi ellenőrzés, aláírók személye stb.). A beszállítói szerződés egyértelműen szabályozza a minőség és a mennyiség megvizsgálásának módját, a minőségi és a mennyiségi kifogásolás rendjét (pl. szabványra, műszaki feltételre, más előírásra, mindkét fél által ismert szokványra vagy mintaszabályzatra utalással, mintával vagy részletes leírással, minőségi feltételek későbbi definiálása esetén követendő eljárásrendet) A szerződéstől való elállás részletesen szabályozott a szerződésben (a felek valamelyike elállása esetén a kártérítés alapja, módja, fajtája pl. átalány, mértéke; a szerződéskötés előtti helyzet visszaállítása) Amennyiben részteljesítés megengedett, úgy a végszámla benyújtása előtt teljes körű teljesítési-, pénzügyi ellenőrzést ír elő a szerződés. A beszállítói szerződés egyértelműen szabályozza a kifizetés módját (határidő, késedelmi kamat). A beszállítói szerződés egyértelműen szabályozza, hogy a vállalási ár mit tartalmaz. A beszállítói szerződés egyértelműen szabályozza, hogy a beszállító jogosult-e, és ha igen, milyen feltételekkel többletmunkája/többletkiadása ellenértékéhez jutni. A beszállítói szerződés egyértelműen szabályozza, hogy a beszállító jogosult-e, és ha igen, milyen feltételekkel árat emelni (infláció, előre nem látott körülmények, vis major stb.) A beszállítói szerződés egyértelműen szabályozza, hogy az intézmény részéről ki a Összeállította a GYEMSZI szakértői munkacsoportja 104

109 Pályázati és megvalósítási követelmények G G G G G G G G G G G G szakmai kapcsolattartó, aki jogosult a beszállító felé szakmai kérdésekben döntést hozni. A beszállítói szerződés egyértelműen szabályozza, hogy az intézmény részéről ki a felelős vezető kapcsolattartó, aki jogosult a beszállító felé szerződéses kérdésekben döntést hozni. A beszállítói szerződés egyértelműen szabályozza az eredménytermék (szállítandó eszközök, fejlesztendő alkalmazások, szolgáltatások) tartalmát, paramétereit. A beszállítói szerződés egyértelműen szabályozza, hogy a szerződő felek milyen módon és formában végez(het)nek egyeztetés(eke)t az eredménytermék előállítása érdekében. A beszállítói szerződés egyértelműen szabályozza az eljárásrendet, ha a beszállító pénzügyi/működési nehézségekbe ütközik (felszámolás, csőd, végelszámolás). A beszállítói szerződés egyértelműen szabályozza a szerződés teljesítéséhez szükséges anyagok (iratok, segédletek, szabályzók, alapanyagok stb.) átadását-átvételét (jegyzőkönyvezés, elektronikus vagy nyomtatott forma, határidők, az átadott anyagok módosító hatásai stb.) A beszállítói szerződés egyértelműen szabályozza a garanciális időt és a garanciális feltételeket. A beszállítói szerződés egyértelműen szabályozza a garanciális időn belüli meghibásodások esetén követendő eljárást (hibajelentés módja, részletessége, hibajavítási idő, cserekészülék stb.) és a garanciális feltételeket. A beszállítói szerződés egyértelműen szabályozza a szavatossági időn belüli meghibásodások esetén követendő eljárást. A beszállítói szerződés egyértelműen szabályozza a szavatossági feltételeket. A beszállítói szerződés egyértelműen megnevezi a felek képviselőit (cégszerű, menedzsment, technikai kérdésekben stb.) és elérhetőségeiket. A beszállítói szerződés egyértelműen szabályozza, hogy a jogszabályi változások esetén milyen kötelezettségei vannak a beszállítónak. A beszállítói szerződés (pl. mellékleteiben) tartalmazza azokat a jogszabályokat, amelyekre a szerződő feleknek tekintettel kell lenni Szoftverszerződésekkel kapcsolatos elvárások G G G Hosszú távú bérlet esetén gazdaságossági számítást kell végezni a licence vásárlás és a bérleti konstrukció közötti döntés alátámasztása érdekében. A szerződéseknek minden esetben rendelkezniük kell a szerzői, illetve felhasználási jogokról. Egyedi célra történő szoftverfejlesztésre illetve továbbfejlesztésre vonatkozó szerződések esetén - összhangban a szerződéskötéskor érvényes szerzői jogi törvénnyel az alábbiak szerződésben történő rögzítése elvárt: o A szoftver a vállalkozó (beszállító) és alvállalkozói, illetve a további beszállítók - szerzői jogi védelem alatt álló - alkotása, amelynek szerzői jogai a vállalkozót és alvállalkozóit, illetve a beszállítókat illetik évi LXXVI. törvény a szerzői jogról Összeállította a GYEMSZI szakértői munkacsoportja 105

110 Pályázati és megvalósítási követelmények G G G G G G G G G o Amennyiben a szerződéskötéskor a szerzői jogok is átruházásra kerülnek azt a jogszabály által előírt módon írásban rögzíteni kell. o A beszállítónak szavatosságot kell vállalnia azért, hogy az általa fejlesztett és szállított szoftveren és a hozzá kapcsolódó dokumentáción nem áll fenn harmadik személyeknek olyan szerzői vagyoni/felhasználási joga, amely a megrendelő szerződésszerinti felhasználását korlátozná vagy akadályozná177. o A beszállítónak az általa kifejlesztett szoftver részekre és a dokumentációra, a szoftver megfelelő hardver- és szoftverkörnyezetben történő telepítésére, futtatására, tárolására és archiválására területileg, időben és felhasználó számban korlátlan, határozatlan idejű, kizárólagos felhasználási jogot kell adnia a megrendelő részére. Ezen jog alapján az intézmény a beszállító egyedi engedélye nélkül jogosultságot szerez a szoftver átdolgozására, feldolgozására, egyéb módosításra, illetőleg arra, hogy ezen feladatok elvégzésére harmadik személlyel szerződést kössön. o A beszállító köteles a szoftver kifejlesztett mindenkori aktuális verziójának az általa az intézmény részére készített forráskódját, továbbá ennek módosításához és auditálásához szükséges minden információt, dokumentációt átadni. A forráskód a megrendelő tulajdonába kerül. Az intézmény a szoftver módosításaihoz a dokumentációt és a forráskódot jogosult korlátozás nélkül felhasználni, így a továbbfejlesztése tárgyában indított beszerzési eljárás során ezekbe a lehetséges vállalkozóknak a szükséges mértékben betekintést engedhet, illetőleg a megrendelőnek, illetve a nyertes ajánlattevőnek átadhatja a továbbhasznosítás lehetőségével. o Amennyiben a beszállító a szoftver elkészítéséhez más személyt is igénybe vesz, köteles a közreműködő természetes és jogi személyekkel olyan tartalmú szerződéseket kötni, hogy a felhasználási jogot megrendelő a megrendelő és beszállító közötti szerződésekben írt feltételekkel megszerezhesse. o Amennyiben a szoftverfejlesztés kapcsán support szolgáltatás (is) kerül megrendelésre, szükséges részletesen meghatározni a szolgáltatás tartalmát és a szolgáltatási szinteket (pl. kiszállás, napidíj, távoli elérés lehetősége, rendelkezésre állás, hibajavításra vonatkozó határidők stb.) o Amennyiben új szoftver kerül kifejlesztése egy licencelt eszközzel, vagy a szoftver továbbfejlesztésére kerül sor, a licencek jogtisztaságát illetve használati jogát is szükséges a szerződésben rögzíteni. o A szoftverhez kapcsolódó adatbázisban szereplő adatvagyon az intézmény tulajdona. Az adatbázishoz való hozzáférést, további feldolgozást, elemzést, értékelést a beszállító a szerződés keretében maradéktalanul biztosítani köteles. o A szerződésekben szükséges az adatmentés, adat tárolás, archiválás részletes szabályozása A fejlesztés megvalósítása követésének követelményei G A mérföldkövek (az időütemezés szerinti) időbeli megvalósításának követése biztosított-e (tűrés, módosítások, csúszások, a csúszások oka és hatása) 177 Harmadik személy ilyen korlátozó vagy akadályozó igénnyel való fellépése esetén a vállalkozó kötelessége közvetlenül fellépni a megrendelő jogos érdekei védelmében. Összeállította a GYEMSZI szakértői munkacsoportja 106

111 Pályázati és megvalósítási követelmények G G G G G G G G G G A kockázatok (célok, költségek, határidők, erőforrások, minőség, támogatottság stb.) folyamatos kezelése biztosított. A megfelelő ellenőrzési struktúra és hierarchia (ellenőrzési felelősségek, alá- és fölérendeltségek) kialakításra került és működtetik, az ellenőrzések adminisztrációja biztosított. Az előzetesen definiált (rész)termékek és -szolgáltatások átvétele (ellenőrzése) megtörtént és megfelelően jegyzőkönyvezett, dokumentált. A szakasz (mérföldkő, résztevékenység) zárása és ellenőrzése megtörtént, és ez megfelelően jegyzőkönyvezett, dokumentált. Munkamegbeszélések rendszeresen és tervezetten kerülnek megtartásra (szakmai előrehaladás és erőforrás felhasználás felmérése, munkabeszámolók, tájékoztató jelentések készítése a projektvezetőség számára). A fejlesztés során a különböző nyilvántartások vezetése tervezett (vezetői, szakmai, minőségi). Vezetői nyilvántartás (a fejlesztés irányításával kapcsolatos összes termék) rendelkezésre áll és aktualizált. Szakmai nyilvántartás (az összes szakmai termék) rendelkezésre áll és aktualizált. Minőségi nyilvántartás (minőségi szemlék jegyzőkönyvei, váratlan szakmai események) rendelkezésre áll és aktualizált. A fejlesztés termékeinek minőségbiztosítási rendszere működik és megfelelően dokumentált A fejlesztés eredményének követelményei G G G G G G G G G G G A fejlesztés eredményeképpen létrejött rendszer döntő mértékben (főbb részek és funkcionalitások, eszközök és hálózat) megegyezik a kiírásban definiálttal. A fejlesztés eredményeképpen létrejött rendszerben a kiírástól eltérő elemek a fejlesztés során működtetett változáskezelő rendszerrel alátámasztottak. A fejlesztés eredményeképpen létrejött rendszer tesztelése az előzetesen egyeztetett tesztelési terv alapján történt, és annak megfelelt. A fejlesztett rendszer átvétele az előzetesen jóváhagyott átvételi terv alapján történt, és annak megfelelt. A fejlesztett rendszer átvétele az előzetesen jóváhagyott átvételi terv alapján történt, és annak megfelelt. A fejlesztett rendszerrel kapcsolatos oktatások lezajlottak, és ezek az előzetesen jóváhagyott oktatási terv alapján történtek, annak megfeleltek. A beszállító átadta a fejlesztett rendszer legutolsó változatának forráskódját. A beszállító átadta a fejlesztett rendszer leírását, dokumentációját. A beszállító átadta a fejlesztett rendszer felhasználói kézikönyvét. A beszállító amennyiben ez a kiírásban szerepelt működtet Help Desket, támogató ügyfélszolgálatot. Az átadott rendszer garanciális időszakára vonatkozóan hibakövetési rendszer működik. Összeállította a GYEMSZI szakértői munkacsoportja 107

112 Pályázati és megvalósítási követelmények G A garanciális időszak alatt a felmerült hibák javítása biztosított. Összeállította a GYEMSZI szakértői munkacsoportja 108

113 Pályázati és megvalósítási követelmények 6 A követelmények alapján folytatott minősítés módszertana, folyamata és szervezete 6.1 A minősítés célkitűzése, alanyai Az alapvető elvárás az, hogy az ágazatban olyan információs rendszer-együttes épüljön ki, amely az alapfeladatának (a gyógyító-megelőző-rehabilitáló tevékenység támogatása) informatikai eszközökkel való kiszolgálásán túl: szabványos (korlátozottan csereszabatos), biztonságos, együttműködésre képes elemekből álljon, amelyek technológiai megoldásukban felülről nyitott (fejleszthető) megoldásokat tartalmazzanak, az alkalmazók számára arányos fenntartási és üzemeltetési költségeket generáljanak, kezelésüket az alkalmazó intézmény átlagos felhasználói felkészültség mellett el lehet sajátítani. A minősítő eljárás tehát a fenti kívánalmaknak csak úgy képes megfelelni, ha azoknak egyértelmű, világos követelmények felelnek meg. A minősítő eljárás információs rendszert, fejlesztési projekteket és szervezetet minősít. Ezeket egyszóval a minősítés alanyainak nevezzük. Feladatunk a korábbiakban megfogalmazott kritériumrendszer alkalmazásának módszerének kidolgozása, amely alkalmazás a minősítendő alanyok (az egészségügyi információs rendszerek, az információs rendszerfejlesztési projektek, valamint a fejlesztést végző egészségügyi intézmények) minőségének, alkalmasságának és megfelelőségének vizsgálati eljárását határozza meg. A minősítendő alanyok folyamatosan változnak. Ezért a minősítési eljárás az adott pillanatban vizsgálja a megfelelősséget. Nemcsak az alanyok változhatnak az időben, hanem a minősítés szempontrendszere, a követelmények is. Tehát időről-időre ki kell adni az újabb jegyzéket, illetve a változás-jegyzéket, valamint az alanyok minősítését is a szükséges időközönként meg kell újítani. Mi is várunk el a minősítéstől? Mi legyen az eljárás kimeneti pontja? Milyen eredménytermék álljon elő az eljárás végén? Végezetül: milyen hatása legyen a minősítésnek az alanyokra, az alkalmazó intézményre vonatkozóan, és az informatikai környezet alakításáért felelős kormányzati szervekre vonatkozóan? Vegyük egyenként a fentieket az alanyok szerint: 6.2 Információs rendszerek Elvárás a minősítő eljárással szemben Az információs rendszer megfelelésének vizsgálata: a korábbi fejezetekben meghatározott rendszerkövetelmények egyértelmű mérési eljárás szerinti ellenőrzésével, az ellenőrzés alapján a minősítési dokumentáció reprodukálható előállítását, valamint Összeállította a GYEMSZI szakértői munkacsoportja 109

114 Pályázati és megvalósítási követelmények a megfelelőség vagy meg nem felelősség kinyilvánítását, meg nem felelés esetén a hiányok egyértelmű megjelölését, javaslattételt a pótlásukra Az eljárás kimeneti pontja Egy működő rendszer esetében a kimeneti pont a rendszer általános és szakma-specifikus követelményei szerinti vizsgálatának teljes körű befejezése és dokumentálása. A kimeneti pont időben korlátozott, és egyetlen eredménytermékkel jár A minősítés eredményterméke A minősítési eljárás eredményterméke az a dokumentum, amely a vizsgálat(ok) részletes eredményét tartalmazza a következők szerint: a vizsgálat időpontja, a vizsgált alany rövid leírása, a vizsgálat célja, a vizsgált kötelező követelmények táblázatos felsorolása, eredménye (megjegyzéssel), a vizsgált, és meglévő ajánlott követelmények táblázatos felsorolása, eredménye (megjegyzéssel), a vizsgálat értékelése, javaslattétel a hiányosságok pótlására. A minősítés eredménye megfelelő ha: A releváns kötelező rendszerkövetelmények legalább 90%-át teljesíti a rendszer, valamint a fennmaradó nem teljesített rendszerkövetelményeknek való későbbi megfelelést a minősítő reális és teljesíthető elvárásnak minősíti. A hiánypótlásra a rendszer üzemeltetője a rendszert fejlesztő cég kötelezettségvállalásával nyilatkozik. A nem teljesített kötelező rendszerkövetelményeket teljesített ajánlott követelményekkel nem lehet helyettesíteni! Amennyiben a minősítés eredménye nem megfelelő, az eredménytermék a vizsgált rendszert működtető intézménynek véleményeltérésével az ágazati döntőfórum elé kerül, amely grémium dönt a kérdésben. A döntőfórum döntése mind a minősítő intézményre, mind pedig a minősítettre kötelező. Az eredménytermék az ágazati informatikáért felelős szervnek is megküldésre kerül A minősítés eredményének hatása a vizsgált objektumra, intézményre és ágazati szervekre A rendszert működtető és a rendszert fejlesztő intézmények hitelesített dokumentumot kapnak a pozitív minősítésről, amelyet publikálhatnak, az intézmények jó hírének terjesztéséhez felhasználhatnak. A nem megfelelő minősítési végeredmény esetén az eredmény alapján a minősítő által meghatározott a döntőfórum döntésével kiegészített hiánypótlások elvégzésére a meghatározott ideig a rendszer fenntartója kötelezhető, amelyet a meghatározott idő eltelte után köteles jelenteni az ágazati informatikáért felelős szervnek. A megkövetelt tevékenységek nem teljesítéséért a kötelezett intézmény egyszemélyi felelős vezetője felel. Ekkor az információs rendszer működése felfüggeszthető. Szankciók a nem megfelelő rendszer alkalmazása esetén: o fegyelmi felelősségre vonás o juttatás megvonás o pénzbüntetés o elbocsátás Összeállította a GYEMSZI szakértői munkacsoportja 110

115 Pályázati és megvalósítási követelmények 6.3 Információs rendszerfejlesztési projektek Elvárás a minősítő eljárással szemben A fejlesztés jó minőségben való végrehajtása azzal, hogy a fejlesztési projekt dokumentációjának minőségbiztosítása révén biztosítja: a fejlesztési koncepció illeszkedését az ágazati és kormányzati törekvésekhez a fejlesztési projektet végrehajtó egészségügyi intézmény szakmai célmeghatározásának és fejlesztési koncepciójának konzisztenciáját a fejlesztendő információs rendszer későbbi megfelelőségét a pályázati dokumentáció előzőeket alátámasztó tartalmát a pályázatok elbírálásának megfelelőségét, ezen keresztül a fejlesztő külső szállító megfelelőségét, fejlesztési képességét a fejlesztett rendszer fenntarthatóságát az üzemeltetés megfelelőségét Az eljárás kimeneti pontja A jövőbeli információs rendszerek esetében a kimeneti pont időben elhúzódó, a jövőbeli fejlesztés kiinduló dokumentumainak rendszerkoncepciójának, rendszertervének, fejlesztési pályázati anyagainak, valamint a fejlesztési folyamatának felszerelése a vonatkozó követelményekkel, és folyamatos minőségbiztosítása azok betartásának ellenőrzésével. A kimeneti pont ebben az esetben bonyolultabb, hiszen egy fejlesztési folyamat egészére vonatkozik, módszertanában is sokrétű A minősítés eredményterméke A minősítési eljárás eredményterméke az a dokumentum, amely a vizsgálat(ok) részletes eredményét tartalmazza a következők szerint: a vizsgálat időpontja, a vizsgált projekt rövid leírása, a vizsgálat célja, a kötelező követelmények felsorolása, a vizsgált dokumentumban való előfordulásának referenciája, megfelelősége (megjegyzéssel), a meglévő ajánlott követelmények felsorolása, előfordulásuk referenciája (megjegyzéssel), a vizsgálat értékelése, javaslattétel a hiányosságok pótlására. A minősítés eredménye megfelelő ha: A minősítő eljárás minden a dokumentáció vonatkozásában releváns kötelező követelmény meglétét igazolja, és a releváns ajánlott követelmények legalább 40%-át tartalmazza a dokumentáció. A dokumentáció csak 100%-os megfelelés esetén tekinthető felhasználhatónak! Amennyiben a minősítés eredménye nem megfelelő, az eredménytermék a vizsgált projektet vezető/dokumentumot előállító intézmény véleményeltérésével az ágazati döntőfórum elé kerül, amely grémium dönt a kérdésben. A döntőfórum döntése mind a minősítő intézményre, mind pedig a minősítettre kötelező. Az eredménytermék az ágazati informatikáért felelős szervnek is megküldésre kerül A minősítés eredményének hatása a vizsgált objektumra, intézményre és ágazati szervekre Összeállította a GYEMSZI szakértői munkacsoportja 111

116 Pályázati és megvalósítási követelmények Az információs rendszerfejlesztő egészségügyi szervezet a fejlesztést felügyelő kormányzati szerv (pl. NFÜ) felé mint a projekt minőségbiztosításának eredményét felhasználhatja, és azt a kormányzati szerv köteles figyelembe venni. A nem megfelelő minősítési végeredmény esetén az eredmény alapján a minősítő által meghatározott a döntőfórum döntésével kiegészített tevékenységek és hiánypótlások elvégzésére a meghatározott ideig a fejlesztési projekt szervezete kötelezhető, amelyet a meghatározott idő eltelte után köteles jelenteni az ágazati informatikáért felelős szervnek. A megkövetelt tevékenységek nem teljesítéséért a kötelezett intézmény egyszemélyi felelős vezetője felel. Ekkor a fejlesztési projekt megállítható. Szankciók a nem megfelelő rendszer alkalmazása esetén: o fegyelmi felelősségre vonás o juttatás megvonás o pénzbüntetés o elbocsátás 6.4 Információs rendszerfejlesztési projektet vezető egészségügyi intézmény Elvárás a minősítő eljárással szemben Az intézményi feladatok informatikai támogatását biztosító rendszer fejlesztéséhez tartozó felkészültség biztosítása, amely a következőket ellenőrzi: az intézményi szakmai és szervezeti előkészítés megfelelőségét a projekttel összefüggő szervezetfejlesztést a fenntarthatóság intézményi garanciáit az üzemeltetés megfelelő szervezeti vagy szerződéses kialakítását Az eljárás kimeneti pontja Egy szervezet minősítése a fejlesztési projekt (i) előkészítése, (ii) a szükséges szervezet fejlesztése, (iii) a lebonyolítása és a (iv) fejlesztett rendszer üzemeltetése szempontjából történik. A kimeneti pont a két előző objektum esetén leírtak ötvözete: hiszen valamennyi (iiv) fázis egy-egy dokumentumot eredményez, viszont a fejlesztési projekt egy-egy meghatározott stádiumában kerül végrehajtásra, vagyis a folyamatszerűség is megjelenik benne A minősítés eredményterméke A minősítési eljárás eredményterméke az a dokumentum, amely a vizsgálat(ok) részletes eredményét tartalmazza a következők szerint: a vizsgálat időpontja, a vizsgált alany rövid leírása, a vizsgálat célja, a vizsgált kötelező követelmények táblázatos felsorolása, eredménye (megjegyzéssel), a vizsgált, és meglévő ajánlott követelmények táblázatos felsorolása, eredménye (megjegyzéssel), a vizsgálat értékelése, javaslattétel a hiányosságok pótlására. A minősítés eredménye megfelelő ha: A minősítés eredményterméke(i) által megfogalmazott szervezetfejlesztések végrehajtásra kerültek. A végrehajtást vállaló nyilatkozat nem elegendő a megfelelőséghez! Összeállította a GYEMSZI szakértői munkacsoportja 112

117 Pályázati és megvalósítási követelmények Amennyiben a minősítés eredménye nem megfelelő, az eredménytermék a vizsgált intézmény véleményeltérésével az ágazati döntőfórum elé kerül, amely grémium dönt a kérdésben. A döntőfórum döntése mind a minősítő intézményre, mind pedig a minősítettre kötelező. Az eredménytermék az ágazati informatikáért felelős szervnek is megküldésre kerül A minősítés eredményének hatása a vizsgált objektumra, intézményre és ágazati szervekre Az eredménytermék az intézmény által végrehajtandó szervezetfejlesztések indokaként, és a későbbi ellenőrzéseknél is felhasználható, amelyetket az ellenőrző szerv köteles figyelembe venni. A nem megfelelő minősítési végeredmény esetén az eredmény alapján a minősítő által meghatározott a döntőfórum döntésével kiegészített tevékenységek és hiánypótlások elvégzésére a szervezet kötelezhető, hogy meghatározott ideig azt elvégezze - amelyről köteles jelenteni az ágazati informatikáért felelős szervnek. A megkövetelt tevékenységek nem teljesítéséért a kötelezett intézmény egyszemélyi felelős vezetője felel. Ekkor az intézmény számára saját költségén szervezetfejlesztési tanácsadó rendelhető ki ágazati döntési felhatalmazással. Szankciók a nem megfelelő rendszer alkalmazása esetén: o fegyelmi felelősségre vonás o juttatás megvonás o pénzbüntetés o elbocsátás 6.5 A minősítő eljárás módszertana A minősítő eljárás során alkalmazott módszer Az információs rendszerek infrastruktúrájának minősítésekor annak mérete alapvetően befolyásolja a vele szemben elvárt kritériumok sorát. Ezért szükséges a minősítés eljárásának meghatározása előtt ezt a méretbeli-komplexitásbeli elkülönítést besorolást megtenni, hogy felállíthassunk egy működőképes minősítési rendszert. Az egészségügyi információs infrastruktúra besorolását annak függvényében adjuk meg, hogy egy időben hány munkahelyet szolgálnak ki. Ezt a besorolást azért tartjuk fontosnak, mert más és más követelményeknek kell megfelelnie egy két munkahelyes háziorvosi praxisrendszernek, egy 10-egynéhány munkahelyes praxisközösséget kiszolgáló, vagy kis rendelőintézetben működő információs rendszernek, és más szintű követelményeknek kell megfelelnie egy százas nagyságrendű kórházi rendszernek, vagy egy országos hálózatba szervezett rendszernek. Általában megállapítható, hogy a rendszerek biztonsági, rendelkezésre állási, szolgáltatási komplexitási fokozatai is követik a fenti méretbeli kategóriákat. Így a következő minősítési kategóriákat állítunk fel: kevesebb, mint 3 munkahelyes rendszerek személyes rendszerek = A típus 3 néhány 10 munkahelyes csoport rendszerek = B típus néhány száz, földrajzilag közeli elhelyezésű munkahelyeket kiszolgáló nagyvállalati méretű rendszerek = C típus Összeállította a GYEMSZI szakértői munkacsoportja 113

118 Pályázati és megvalósítási követelmények földrajzilag országos kiterjedésű több száz munkahelyet kiszolgáló országos rendszerek = D típus Weben keresztül több százas (ezres) nagyságrendű felhasználót kiszolgáló felhőszolgáltató rendszerek = E típus A rendszerkritériumok táblázatában ezért öt oszlopot rendelünk minden egyes követelmény sorába. Az oszlopokba három jel kerülhet: K-Kötelező kritérium; A-Ajánlott kritérium; N - nem alkalmazandó kritérium. Így a korábban megfogalmazott kritérium-táblázat a következőképpen egészül ki: Ssz. A A A A A Követelmény A megfelelő fejlesztési technológia kiválasztásával időtálló 178, fenntartható rendszereket kell fejleszteni. Robosztus architektúra: Az alkalmazások architektúráját úgy kell megtervezni és megvalósítani, hogy az képes legyen a megcélzott (ágazati vagy intézeti) számú felhasználó biztonságos és gyors kiszolgálására. (Az elvárt gyorsaság megítélésénél az adott funkciók specifikációjánál megadott érték az irányadó). A megfelelőséget számítással kell alátámasztani és teszteléssel ellenőrizni. Architektúra: a megvalósításra kerülő alkalmazás kettő (kliensszerver), vagy több rétegű (multitiered) architektúrára 179 épüljön. Méretezhetőség: Az alkalmazások architektúrájának (hardver és szoftver) biztosítania kell az intézmény vagy régióhoz tartozó teljes intézményrendszernek, mint felhasználó számhoz szükséges méretre való felbővítés lehetőségét. A megfelelőséget számítással kell alátámasztani. Hibatűrő, redundáns kialakítás: Mind egyedi eszköz telepítése esetén, mind szolgáltató központoknál olyan mértékben Szállító Típus /intézm ény A B C D E K K K K K A K K K K N N A K K A A K K K N A K K N Megjegy zés 178 Az időtállóságnál figyelembe kell venni a évi XLVII. Törvény ben foglalt adatmegőrzési időtartamokat. Nyilatkozat és megvalósítási leírás szükséges az időtállóság megvalósításáról. 179 Pl. three tier architektúra kliensl, alkalmazás szerver (application server), adatbázis szerver (database server) Összeállította a GYEMSZI szakértői munkacsoportja 114

119 Pályázati és megvalósítási követelmények Ssz. A A A Követelmény szükséges hibatűrő, redundáns infrastruktúrát kialakítani, amely összhangban áll a vállalt szolgáltatási szint (kiemelten a rendelkezésre állás) paraméterekkel. A megfelelőséget számítással kell alátámasztani. Ki kell alakítani a feladatátvételi topológiát 180. Meg kell határozni, hogy mely eszközök szolgálnak egymás tartalékaiként, illetve az egyes tagok milyen szerepet (aktív kiszolgálói, tartalék) játszanak. A hardveres redundancia mellett az alkalmazás-szoftveres redundáns megvalósítása a rendelkezésre állás érdekében indokolt. A hálózati szempontból redundáns kapcsolatot kell biztosítani a kliensekkel. Szállító Típus /intézm ény A B C D E N N K K K A A K K K N N A K K és így tovább. A minősítés során a teljes követelmény-struktúrából egyszerűen leválogatható az a részhalmaz, amelyet a vonatkozó rendszer (A, B, C,...besorolások szerint) minősítésekor alkalmazni kell. A fenti struktúrájú táblázatot a minősítő állítja elő a jelen követelményrendszer alapján Információs infrastruktúra minősítése A minősítés során a fenti módszerrel felállított táblázat szűrése után már a ténylegesen alkalmazandó kritériumokat tartalmazó táblázat lesz a sorvezető. Egy háziorvosi csoportpraxis számára felállított információs rendszer minősítési táblázatat az előzőek alapján a következőképpen alakul: a táblázat első két oszlopa a követelményeket meghatározó 4. és 5. fejezet táblázataiból áll. A harmadik oszlop a minősítésben érintett intézményt jelöli ki, a negyedik a típus (A E), valamint Megjegyzés rovat az utolsó oszlop. A Típus oszlopban kell meghatározni, hogy a követelmény-elem kötelező )K), vagy ajánlott (A). Megjegy zés 180 Pl: feladatátvételi pár topológia, forró tartalék, feladatátvételi gyűrű, stb. Összeállította a GYEMSZI szakértői munkacsoportja 115

120 Pályázati és megvalósítási követelmények Ssz. A A A A A Követelmény A megfelelő fejlesztési technológia kiválasztásával időtálló, fenntartható rendszereket kell fejleszteni. Robosztus architektúra: Az alkalmazások architektúráját úgy kell megtervezni és megvalósítani, hogy az képes legyen a megcélzott (ágazati vagy intézeti) számú felhasználó biztonságos és gyors kiszolgálására. (Az elvárt gyorsaság megítélésénél az adott funkciók specifikációjánál megadott érték az irányadó). A megfelelőséget számítással kell alátámasztani és teszteléssel ellenőrizni. Méretezhetőség: Az alkalmazások architektúrájának (hardver és szoftver) biztosítania kell az intézmény vagy régióhoz tartozó teljes intézményrendszernek, mint felhasználó számhoz szükséges méretre való felbővítés lehetőségét. A megfelelőséget számítással kell alátámasztani. Hibatűrő, redundáns kialakítás: Mind egyedi eszköz telepítése esetén, mind szolgáltató központoknál olyan mértékben szükséges hibatűrő, redundáns infrastruktúrát kialakítani, amely összhangban áll a vállalt szolgáltatási szint (kiemelten a rendelkezésre állás) paraméterekkel. A megfelelőséget számítással kell alátámasztani. A hardveres redundancia mellett az alkalmazás-szoftveres redundáns megvalósítása a rendelkezésre állás érdekében indokolt. Szállító/intéz mény I Sz Sz Sz Sz Típus B K K A A A Megjegyzés A táblázatot a minősítő intézet állítja elő és tölti ki a minősítési eljárás során. A táblázatban szereplő teljesített/összes kötelező követelmények hányadosa adja a minősítés eredményét: Összeállította a GYEMSZI szakértői munkacsoportja 116

121 Pályázati és megvalósítási követelmények Az információs rendszer megfelelő, ha az, vagyis a kötelező követelmények legalább 90%-át teljesíteni kell. Amennyiben az információs rendszer 3 évnél régebbi fejlesztés, akkor az elfogadható arány 70%, de a nem teljesített 20%-ot két éven belül pótolni kell Egészségügyi információs rendszerek szolgáltatásainak minősítése Az előző pontban az infrastruktúrális elemek 181 minősítését tárgyaltuk. A működő információs rendszerek az infrastruktúrán túl szolgáltatásokat nyújtanak a felhasználóiknak. Ezeknek a szolgáltatásoknak szoros kapcsolatuk van az alkalmazói logikával, vagyis az egészségügyi folyamatokkal. Jelen dolgozat nem tér ki a legapróbb részletekig ezen folyamatoknak való megfelelésre, hiszen a kérdést jobbára jogszabályok határozzák meg (pl.: adattartalmak, jelentési gyakoriság stb.). Az egészségügyi információs rendszerek szolgáltatás-szintű besorolását az alkalmazó intézmény szakmai besorolása adja meg. Ilyen az alapellátás, azon belül a különféle ellátási szakmák, vagy a szakellátás, az ágazati irányító státusz stb Információs rendszerfejlesztési projekt minősítése Az információs rendszerfejlesztési projekt minősítése két ágon zajlik: alaki minősítés: a projekt belső szerkezetének szervezetének minősítése (lásd részletesebben a 6. fejezetet) tartalmi minősítés: a projekt célját, követelményeit tartalmazó dokumentáció minősítése Tartalmi minősítés a projekt kezdő dokumentumától (koncepció) a megvalósítást követő üzemeltetési dokumentációig terjedően vizsgálja a dokumentumok illeszkedését a tematikus fejezetek (3-6 fejezetek) által megfogalmazott követelményekhez, vagyis, biztosítja az elkészült információs rendszer megfelelőségét. A minősítés módszertana a dokumentum létrehozója által kitöltött ellenőrző lista ellenőrzése, a dokumentum összefogó, általános véleményezése. A minősítés eredményterméke az a hibalista, vagy vélemény, amely az ellenőrzésből következik. Tekintsük át a vonatkozó dokumentáció fajtákat a minősítés módszere szempontjából: 1. Rendszer koncepció A rendszer koncepció a megvalósítandó szolgáltatások nagyvonalú terve, amely szolgáltatások segítségével a projekt gazda valamely feladatának-feladatainak elvégzését kívánja támogatni. 1/a. A rendszerkoncepció illeszkedjen a központi fejlesztési programokhoz, a Semmelweis Terv szakmia taralmaihoz. Az illeszkedés ellenőrző listája 182 : Sorszám Követelmény Előfordulás helye (referencia) Teljesül (Igen/nem) 181 Infrastruktúra alatt értünk minden olyan elemét az információs rendszernek, amely nem a felhasználói használathoz tartozik, vagyis a telepített hardvereken kívül ide tartozónak tekintjük az autentikációt authorizációt, a biztonsági elemeket és a mentés helyreállítás elemeit. 182 Az ellenőrző listát a minősítő szervezet állítja elő az NFÜ ajánlásainak megfelelően. Az előfordulás helye rovatot a A projekt gazda tölti ki. Összeállította a GYEMSZI szakértői munkacsoportja 117

122 Pályázati és megvalósítási követelmények 1. Az ellenőrző lista jelen dokumentumban szereplő változata nem tekinthető végleges, állandó tartalmúnak, hiszen a központi fejlesztési programok folyamatosan terebélyesednek. Ezért az ellenőrző lista aktuális állapota a minősítő intézet (lásd 121. oldal) honlapjáról letölthető lesz. Sorszám Támogatandó feladat Előfordulás helye a feladatmeghatározó okiratban(referencia) szerepel (Igen/nem) 1. X. feladat k. okirat előfordulási helye 1/b. A rendszerkoncepció illeszkedjen a projektgazda feladataihoz. A minősítés a hatályos intézményi alapító okiratban és egyéb alapfeladatot meghatározó dokumentumban ellenőrzi a projektgazda által meghatározott támogatott feladatok meglétét. Ez a következő ellenőrző lista 183 alapján történik: A rendszerkoncepció által megcélzott információs rendszer arányosságának ellenőrzése. 1/c. A minősítő azt ellenőrzi, hogy a tervezett információs rendszer bevezetése arányos szakismereti képzési megterhelést jelent a projektgazda szervezetének. Ennek mérésére 2. Megvalósíthatósági tanulmány(ok), Logikai rendszerterv előzetes és végleges tanulmányok Az előzetes- és végleges megvalósíthatósági tanulmányok, rendszertervek vizsgálatát a fenntarthatóság és a hatáselemzés szempontjából kell elvégezni. A fenntarthatóság durva mérőszáma a projektgazda informatikai költségvetésének növekedése, valamint ennek az intézményi költségvetéshez való viszonya. A tanulmányok a következő ellenőrzési lista alapján kerülnek minősítésre: Sorszám Követelmény Megkövetelt érték Megfelel (Igen/nem) 3. Pályáztatási dokumentáció A pályázati dokumentáció minősítése a tematikus (3-6) fejezetekben kidolgozott követelmények azon hányadára történik, amelynél a Kötelező és a Pályázatnál releváns értékei K; P. Kötelező Sorszám Követelmény 185 /ajánlott Pályázatnál releváns Mért érték Teljesül (Igen/nem) 1. K P 183 Az ellenőrző listát a projektgazda állítja elő és tölti ki, a minősítő intézet az utolsó oszlopot tölti ki. 184 Az NFÜ által meghatározott követelmény 185 A mindenkori (köz)beszerzési eljárás határozza meg. Összeállította a GYEMSZI szakértői munkacsoportja 118

123 Pályázati és megvalósítási követelmények A pályázati dokumentáció (technikai specifikációja) akkor megfelelő, ha az összes ilyen követelmény teljesítve van. 5. Értékelés dokumentációja Az értékelés dokumentációját a pályázati dokumentáció alapján, az ott megkövetelt követelmények ajánló által vállalt megfelelését kell vizsgálni. A teljes egyezőség az elfogadott Szervezet minősítése az információs rendszer fejlesztési projekt szempontjából A szervezetet azoknak a képességeknek a megléte szempontjából minősítjük, amelyek szükségesek a projekt életciklusán keresztül. Az életciklust 4 részre oszthatjuk: Projekt előkészítése Projekt végrehajtása A projekt során megvalósuló információs rendszer fenntarthatósága A projekt során megvalósuló információs rendszer üzemeltetésének megfelelősége A megfelelőség mérésére az 5. fejezet által meghatározott követelmények alapján történik. A megfelelőséget a minősítő által meghatározott követelmény jegyzék alapján mérik. 6.6 A rendszerminősítés folyamata, a minősítések publikálása Információs rendszer minősítésének folyamata A minősítendő információs rendszer besorolása (A E) A besorolásnak megfelelő minősítő táblázat előállítása (lőlap) A minősítő táblázat elküldése a minősítendő információs rendszer felelősének A kitöltve visszaérkezett minősítő táblázat alapján helyszíni ellenőrzés o tételes v. o szúrópróba szerint Az ellenőrzés során észlelt eltérések értékelése o megfelelő o nem megfelelő o ideiglenesen éé.hh.nn-ig üzemeltethető A minősítési jegyzőkönyv előállítása A minősítés eredményének feltöltése a minősítési információs rendszerbe A minősített felügyeleti szervének értesítése a minősítésről. Összeállította a GYEMSZI szakértői munkacsoportja 119

124 Pályázati és megvalósítási követelmények Fejlesztési projekt minősítésének folyamata Előkészítés A fejlesztési projekt besorolása (A x) A besorolásnak megfelelő dokumentumok listájának előállítása A meghatározott dokumentumok bekérése a minősített projekt gazdájától A besorolásnak megfelelő minősítő táblázat előállítása (lőlap) A minősítő táblázat elküldése a minősítendő projekt gazdájának A kitöltve visszaérkezett minősítő táblázat alapján ellenőrzés o tételes v. o szúrópróba szerint Az ellenőrzés során észlelt eltérések értékelése o megfelelő o nem folytatható o ideiglenesen éé.hh.nn-ig folytatható A minősítési jegyzőkönyv előállítása A minősítés során észlelt hiányosságok pótlása, annak elősegítése A minősítés eredményének feltöltése a minősítési információs rendszerbe A minősített projekt felügyeleti (EU-s, kormányzati, magán) szervének értesítése a minősítésről. Végrehajtás (forrás biztosított) A minősítő táblázat elküldése a minősítendő projekt gazdájának A besorolásnak megfelelő dokumentumok listájának előállítása o Egyszeri dokumentumok o időszakos dokumentumok A meghatározott dokumentumok egyszeri v. időszakos bekérése a minősített projekt gazdájától A besorolásnak megfelelő minősítő táblázat előállítása (lőlap) A kitöltve visszaérkezett minősítő táblázat alapján ellenőrzés Összeállította a GYEMSZI szakértői munkacsoportja 120

125 Pályázati és megvalósítási követelmények o tételes v. o szúrópróba szerint Az ellenőrzés során észlelt eltérések értékelése o megfelelő o nem folytatható o ideiglenesen éé.hh.nn-ig folytatható A minősítési jegyzőkönyv előállítása A minősítés során észlelt hiányosságok pótlása, annak elősegítése A minősítés eredményének feltöltése a minősítési információs rendszerbe Eredmény termék a szállított/fejlesztett rendszer A minősítendő információs rendszer besorolása (A E) A besorolásnak megfelelő minősítő táblázat előállítása (lőlap) A minősítő táblázat elküldése a projekt gazdának A kitöltve visszaérkezett minősítő táblázat alapján helyszíni ellenőrzés o tételes v. o szúrópróba szerint Az ellenőrzés során észlelt eltérések értékelése o megfelelő o megfelelő, ha a felsorolt hiányok pótlása megtörtént o nem megfelelő A minősítési jegyzőkönyv előállítása A minősítés eredményének feltöltése a minősítési információs rendszerbe A minősített felügyeleti szervének értesítése a minősítésről Szervezet minősítésének folyamata 6.7 A rendszerminősítés szervezete/intézménye A rendszerminősítés az egészségügyi ágazatban nem rendelkezik hagyományokkal. Ugyan az Országos Egészségbiztosítási Pénztár azokat a rendszereket minősíteni akarta, amelyekkel Összeállította a GYEMSZI szakértői munkacsoportja 121

126 Pályázati és megvalósítási követelmények elektronikus jelentési kapcsolatban áll, azonban ennek a minősítési környezete az elektronikus kapcsolódásra való alkalmasságon nem mutatott túl, és nem is valósult meg. A jelen dokumentum túl a rendszerkövetelmények összegyűjtésén egy megvalósítható minősítési rendszer elképzelését is tartalmaznia kell, amely alapjául szolgál a minősítés intézményi környezetének kialakításához, valamint az eljárást alátámasztó jogi környezet megteremtéséhez. A rendszerminősítés csakis egy erre a célra kialakított szervezeten keresztül történhet. A nemzetközi gyakorlat szerint az auditálás (nem a rendszerminősítés, annál komolyabb folyamat) mindig független szervezetek privilégiuma. Ez biztosítja a platform- és piacfüggetlenséget. A mi esetünkben ágazati minősítésről van szó, amelyet az egészségügyi kormányzat abból a célból végez, hogy biztosítsa az informatikai, információs rendszerbeli fejlesztések leghatékonyabb módját, egyben érvényesítve azokat az elvárásokat, amelyeket az ágazat szervezője és irányítója az ágazati egész szempontjából szükségesnek tart. Erre azért is szükség van, mert az egészségügyi ellátás átszervezése központi akaratból történik. Ezért a minősítés intézményét első menetben a Megrendelő GYEMSZI hatókörébe tervezzük, amely gyakorlati tapasztalatokat halmoz fel a kezdeti minősítési periódusban, ami alapján kialakítható az a független audit szervezet, amely függetlenül az ágazati törekvések irányától, csakis informatikai szempontból vizsgálja majd a rendszereket A minősítő szervezet/intézmény jogállása A minősítő tevékenységet három periódusra bonthatjuk: 1. A minősítés szempontrendszerének és folyamatának tesztelése kezdeti periódus ; 2. A minősítés rendszerének jobbítása a felgyűlt tapasztalatok alapján, összehasonlító minősítések folytatása szankciók és következmények nélkül; 3. Rendszerszerű, tervszerű és folyamatos minősítési tevékenység folytatása. A fenti periódusok értelemszerűen a végrehajtó szervezetre is visszahatnak, alakítják azt is. Ezért felesleges arról beszélni, hogy a kezdetektől álljon fel egy szervezet a tevékenység ellátására. Véleményünk szerint erre csak a második, de leginkább a harmadik periódusban van szükség. A minősítő szervezet/intézmény alapfeladata a 4. és 5. fejezetek által meghatározott követelmények érvényesítése az információs rendszerek és a fejlesztést végrehajtó intézmények illetve az általuk vezetett fejlesztési projektek tekintetében. A szervezet ezen feladatát megfelelő szintű jogszabály által nevesítetten látja el. A jogszabály kormány/ágazati szintű rendelet formájában jelenik meg. Összeállította a GYEMSZI szakértői munkacsoportja 122

127 Javasolt jogszabályi változtatások 7 Javasolt jogszabályi változtatások 1. Az egészségügyi ellátó intézménynek ki kell alakítania az egészségügyi tevékenységének ellátásához használt informatikai rendszer biztonságával kapcsolatos szabályozási rendszerét és gondoskodnia kell az informatikai rendszer kockázatokkal arányos védelméről. 2. A szabályozási rendben ki kell térni az információtechnológiával szemben támasztott követelményekre, a használatából adódó biztonsági kockázatok felmérésére és kezelésére a tervezés, a beszerzés, az üzemeltetés és az ellenőrzés területén. 3. Az egészségügyi intézmény köteles az informatikai rendszer biztonsági kockázatelemzését szükség szerint, de legalább kétévente felülvizsgálni és aktualizálni. 4. Az informatika alkalmazásából fakadó biztonsági kockázatok figyelembevételével meg kell határozni a szervezeti és működési rendeket, a felelősségi, nyilvántartási és tájékoztatási szabályokat, a folyamatba épített ellenőrzési követelményeket és szabályokat. 5. Az egészségügyi intézménynek ki kell dolgoznia az informatikai rendszerének biztonságos működtetését felügyelő informatikai ellenőrző mechanizmust 186 és azt folyamatosan működtetnie kell. 6. A biztonsági kockázatelemzés eredményének értékelése alapján a biztonsági kockázattal arányos módon gondoskodni kell legalább az alábbiakról: a) a rendszer legfontosabb elemeinek (eszközök, folyamatok, személyek) egyértelmű és visszakereshető azonosításáról, b) az informatikai biztonsági rendszer önvédelmét, kritikus elemei az illetéktelen hozzáférést tekintve érintett rendszerelemek védelmének zártságát és teljes körűségét biztosító ellenőrzésekről, eljárásokról, c) a rendszer szabályozott, ellenőrizhető és rendszeresen ellenőrzött felhasználói adminisztrációjáról (hozzáférési szintek, egyedi jogosultságok, engedélyezésük, felelősségi körök, hozzáférés naplózás, rendkívüli események), d) olyan biztonsági környezetről, amely az informatikai rendszer működése szempontjából kritikus folyamatok eseményeit naplózza és alkalmas e naplózás rendszeres (esetleg önműködő) és érdemi értékelésére, illetve lehetőséget nyújt a nem rendszeres események kezelésére, e) a távadatátvitel bizalmasságáról, sértetlenségéről és hitelességéről, f) az adathordozók szabályozott és biztonságos kezeléséről, g) a rendszer biztonsági kockázattal arányos vírusvédelméről. 7. Az egészségügyi intézménynek tevékenysége ellátásához, nyilvántartásai naprakész és biztonságos vezetéséhez meg kell valósítania a biztonsági kockázatelemzés alapján indokolt védelmi intézkedéseket és rendelkeznie kell legalább a következőkkel: a) informatikai rendszerének működtetésére vonatkozó utasításokkal (minta, vagy tartalomjegyzésk; van-e NFM sablon?) és előírásokkal, valamint a fejlesztésre vonatkozó tervekkel, b) minden olyan dokumentációval, amely az egészségügyi ellátási tevékenységet közvetlenül vagy közvetve támogató informatikai rendszerek folyamatos és biztonságos működését - még a szállító, illetőleg a rendszerfejlesztő tevékenységének megszűnése után is - biztosítja, c) DRP? van-e erre NFM sablon? az egészségügyi szolgáltatások ellátásához szükséges informatikai rendszerrel, valamint a szolgáltatások folytonosságát biztosító tartalék berendezésekkel, illetve e berendezések hiányában az ezeket helyettesítő egyéb - a tevékenységek, illetve szolgáltatások folytonosságát biztosító - megoldásokkal, d) olyan informatikai rendszerrel, amely lehetővé teszi az alkalmazási környezet biztonságos elkülönítését a fejlesztési és tesztelési környezettől, valamint a megfelelő változáskövetés és változáskezelés fenntartását, e) az informatikai rendszer szoftver elemeiről (alkalmazások, adatok, operációs rendszer és környezetük) olyan biztonsági mentésekkel és mentési renddel (mentések típusa, módja, visszatöltési és helyreállítási tesztek, eljárási rend), amelyek az adott rendszer helyreállíthatóságát a rendszer által nyújtott szolgáltatás kritikus helyreállítási idején belül lehetővé teszik. Ezen mentéseket kockázati szempontból elkülönítetten és tűzbiztos módon kell 186 Szabályzatban rögzített eljárások sorozata Összeállította a GYEMSZI szakértői munkacsoportja 123

128 Javasolt jogszabályi változtatások tárolni, valamint gondoskodni kell a mentések forrásrendszerrel azonos szintű hozzáférés védelméről, f) jogszabályban meghatározott nyilvántartás ismételt előhívására alkalmas adattároló rendszerrel, amely biztosítja, hogy az archivált anyagokat a jogszabályokban meghatározott ideig, bármikor visszakereshetően, helyreállíthatóan megőrizzék, g) a szolgáltatásai folyamatosságát akadályozó rendkívüli események kezelésére szolgáló tervvel. 8. Az egészségügyi intézménynél mindenkor rendelkezésre kell állnia: a) az informatikai rendszer felépítésének és működtetésének az ellenőrzéséhez szükséges rendszerleírásoknak és modelleknek b) az informatikai rendszernél az adatok szintaktikai szabályainak, az adatok tárolási szerkezetének konkrétabban: fejlesztői vagy üzemeltetői kézikönyv? Annak elvárt sablonjával az NFM-től?, c) az informatikai rendszer elemeinek az egészségügyi előírások által meghatározott biztonsági osztályokba sorolási rendszerének mi ez: cégszintű adatbesorolás?, d) az adatokhoz történő hozzáférési rend meghatározásának, e) az adatgazda és a rendszergazda kijelölését tartalmazó iratnak mi ez: IT szervezetimunkaköri leírás, amely bizonyos kötelező elemeket tartalmaz?, f) az alkalmazott szoftver eszközök jogtisztaságát bizonyító szerződéseknek, 9. az informatikai rendszert alkotó ügyviteli, egészségügyi szoftvereszközök teljes körű és naprakész nyilvántartásának. 10. A szoftvereknek együttesen alkalmasnak kell lenni legalább: a) a működéshez szükséges és jogszabályban előírt adatok nyilvántartására, b) az egészségügyi adatok és az egészségügyi dokumentumok biztonságos nyilvántartására, c) az egészségügyi intézmény tevékenységével összefüggő informatikai rendszerekhez történő közvetlen vagy közvetett csatlakozásra, d) a tárolt adatok ellenőrzéséhez való felhasználására, e) a biztonsági kockázattal arányos logikai védelemre és a sérthetetlenség védelmére. 11. Az egészségügyi intézménynek belső szabályzatában meg kell határoznia az egyes munkakörök betöltéséhez szükséges informatikai végzettséget és ismereteket. Összeállította a GYEMSZI szakértői munkacsoportja 124

129 Nemzetközi minősítési gyakorlat MELLÉKLETEK 8 A követelmények rendszerét meghatározó fejezetek 8.1 Az egészségügyi információs rendszerek nemzetközi minősítési követelményei és gyakorlata A fejezet célja A fejezet célja, hogy bemutassa azokat a nemzetközi trendeket és követelményeket, amelyeket az egészségügyi informatikai projektek tervezésekor javasolt figyelembe venni annak érdekében, hogy a projektek eredményei fenntarthatók és kompatibilisek legyenek más egészségügyi informatikai megoldásokkal. A nemzetközi környezet két legfontosabb eleme a globális egészségügyi kihívásokra reagáló legjobb iparági gyakorlat és kutatási irányok, valamint az alkalmazott technológiákra és módszerekre vonatkozó jogi szabályozás, iparági standardok és ajánlások.. Általánosságban megállapítható, hogy bár az egészségügyi informatika nemzetközi szabályozása, ill. követelmények megfogalmazása az elmúlt években jelentősen előrelépett, a rendelkezésre álló szabályok, standardok még nem nyújtanak egyértelmű iránymutatást a szállítók és felhasználók részére és ezek projektszintű alkalmazása nehézségekbe ütközik. A standardok és az ajánlások is megfogalmaznak olyan követelményeket, amelyek teljesítésének feltételei jelen pillanatban sok tagállamban még nem adottak. Az egészségügyi informatikai projekteket ugyanakkor általában hosszú távra tervezik, ill. egy-egy projekt későbbi fejlesztések alapját is képezi. Ezért szükség van a standardok, ajánlások tanulmányozására a projektek tervezése során és annak megállapítására, hogy az azokban foglalt követelményeket a projekt eredményeként létrejövő termék hogyan tudja teljesíteni, ill. hogyan tehető alkalmassá arra, hogy a jövőben meglegyen a lehetőség a standardokhoz való alkalmazkodásra. Egészségügyi informatika alatt jelen fejezetben elsősorban az egészségügyi ellátás során, ill. annak céljából és ahhoz kapcsolódóan alkalmazott infokommunikációs technológiákat értjük. A fejezet három részből áll: melyek azok a nemzetközi egészségügyi trendek, amelyek az informatikával kapcsolatos követelmények felhasználói alapját jelentik, ill. melyek az egészségügyi informatika ezekre adott válaszai és fejlődési irányai, és specifikusan melyek az Európai Unió szakpolitikájának fő elemei, amelyek Magyarország számára is meghatározóak, különös tekintettel az EU fejlesztési programjaiban való kedvezményezetti szerepkörre az EU vonatkozó szabályozási anyagai, amely a tagállamok tekintetében kötelező érvénnyel bírnak, ill. bizonyos fokú konformitást tesznek szükségessé az Európai Unió szakpolitikája által támogatott szabványosítási törekvések, amelyek eredményeit a projektek tervezése során vizsgálni kell Összeállította a GYEMSZI szakértői munkacsoportja 125

130 Nemzetközi minősítési gyakorlat A fejezetben bemutatott követelmények több szinten értelmezhetők: 1. a jogi kötelezettségek, szakpolitikai ajánlások a nemzeti hatóságok részére szólnak, így ezeket elsősorban ezen a szinten kell figyelembe venni a szakpolitikák tervezésekor, a vonatkozó pályázati kiírások és kiemelt projektek tervezése során, valamint az állami szervek által megrendelt informatikai beruházások tervezése során 2. az egészségügyi informatikai beruházásokat megvalósító szereplők a projektek tervezése során tudják figyelembe venni a kötelezettségeket és ajánlásokat. A kötelezettségek a nemzeti szabályozáson keresztül jelennek meg. 3. A szabványosító testületek munkájának az eredménye kötelezően alkalmazandó iparági szabványokban és ajánlásokban jelenik meg, amelyet a rendszerek szállítói és a projektek megrendelői alkalmaznak a projektek tervezése során. A követelmények értelmezésekor figyelemmel kell lenni arra is, hogy jelenleg számos szabvány, profil, specifikáció fejlesztési fázisban van, ill. részben ajánlásként jelenik meg, ugyanakkor a most tervezési fázisban levő alkalmazások, projektek eredményei hosszú távra kihatnak, amikor ezen szabványok, ajánlások már egy kiforrottabb állapotban lesznek. A későbbi inkompatibilitás elkerülése és az adaptációs költségek csökkentése érdekében ezért abban az esetben is célszerű figyelembe venni a szabványokat, ajánlásokat, ha azok jelen pillanatban esetleg nem is jelennek meg kötelezettségként vagy általánosan elfogadott iparági gyakorlatként A globális egészségügyi trendek hatása az egészségügyi informatikára A fejezet célja az egészségügyi trendek és az egészségügyi informatika kapcsolatának és fejlődési irányainak rövid áttekintése. A legfontosabb nemzetközi egészségügyi kihívásokat az alábbiakban összegezhetjük a nemzetközi szervezetek és az EU stratégiai dokumentumai alapján: Az egészségügyi kiadások az EU tagállamok GDP-jének 9%-át teszik ki, növekedésük gyorsabb a gazdasági növekedésénél, emellett növekszik a fejlett egészségügyi (orvosi) technológia bevezetésének és alkalmazásának költsége A demográfiai változások okán növekszik az idősek aránya Nő a krónikus betegséggel élők aránya, közülük jelentős hányadot az idős emberek képviselnek A kórházi ellátás költsége miatt nő az otthoni ápolás és monitoring, valamint az ezt támogató megoldások jelentősége Az emberi egészség magas szintű védelme érdekében szükség van a személyre szabott egészségügyi megoldások (personal health) alkalmazására, amelyek az egyén szempontjából optimális eredményt produkálnak és pénzügyi, valamint társadalmi szempontból is költséghatékonyak Összeállította a GYEMSZI szakértői munkacsoportja 126

131 Nemzetközi minősítési gyakorlat Nő a világméretű fertőző betegségek, járványok és egészségügyi veszélyhelyzetek bekövetkezésének valószínűsége, ami szükségessé teszi az ezekre való időbeni reagálást és a hatóságok együttműködését Az állampolgárok szolgáltatási színvonallal kapcsolatos elvárása növekszik, az informatikai eszközök és szolgáltatások minden korosztályban elterjedtek Nő a (tag) államok közötti és nemzetközi mobilitás, ami a magas színvonalú egészségügyi ellátáshoz való egyenlő hozzáférés biztosításával kapcsolatban új kihívásokat támaszt Az egészségügyi dolgozók hiánya és egyenlőtlen területi eloszlása nő, ezzel párhuzamosan növekszik mobilitásuk és a telemedicinális szolgáltatások jelentősége Az ágazatban az informatikai penetráció kisebb az átlagosnál, a fejlett technológiák szigetszerű megléte jellemző, annak ellenére, hogy a piac fejlett alkalmazásokat kínál Az egészségügyi modell reaktív, a megelőzés és rehabilitáció relatív gyengesége Szakmai és fogyasztói (beteg) szempontból is szükség van az egyes nem csak egészségügyi - ellátási formák és szolgáltatások integrációjára és ezek szolgáltatói közötti kommunikációra Az egészségügyi informatika ebben a helyzetben egyrészt kihívás, hiszen a kapcsolódó költségek növekednek és ez egy újfajta egyenlőtlenség megjelenését eredményezheti, másfelől lehetőség, mivel segítségével javítható az ellátás eredményessége és egyes szolgáltatások elérhetősége széles körben költséghatékony módon biztosítható. Az egészségügyi informatika fő fejlődési irányai jelzik a kihívásokra adott válaszokat: Az ellátás folyamatosságának biztosítása, ami kiterjed az egészségügyi és nem egészségügyi ellátási és szolgáltatási formák közötti integrációra és kommunikációra Személyre szabott ellátás, amely az egyedi jellemzők figyelembevételével pontosabb diagnózist és optimálisabb terápiát eredményez Telemedicina, amely potenciálisan költséghatékony és magasabb minőségű ellátást eredményezhet a betegek számára On-line hozzáférés és szolgáltatások, amelyek biztosítják a betegek és az egészségügyi intézmények számára a betegek adatainak on-line elérését és feldolgozását, ezáltal jelentősen javítva az ellátás hatékonyságát, biztonságát ás minőségét Interoperabilitás, amely lehetővé teszi a rendszerek kommunikációját és ezáltal a fenti fejlesztési irányok széles körben történő gyakorlati megvalósítását. Az e-egészségügyi alkalmazások, iparági gyakorlat ismertetésére jelen anyagban nincs módunk, továbbá egy gyorsan fejlődő iparágról beszélünk, ahol egyes gyakorlatok rögzítésének nem lenne értelme. A nemzetközi szabályozás és a nemzetközi szervezetek tevékenységének a kulcsterülete az interoperabilitás és az ezzel kapcsolatos szabványok, Összeállította a GYEMSZI szakértői munkacsoportja 127

132 Nemzetközi minősítési gyakorlat profilok, specifikációk előállítása, mivel ez biztosítja a különböző szolgáltatások széles körben való elérését és az alkalmazások költséghatékony fejlesztését. Jelen fejezetben ezért elsősorban erre a területre fókuszálunk. Magyarország, mint az EU tagállama számára meghatározó az EU egészségügyi és e- egészségügyi szakpolitikája, mivel ez végső soron kötelezettségeket eredményez, amelyek projektszinten is megjelennek. Az EU egészségügyi informatikával kapcsolatos politikája alapvetően három elemre fókuszál: az ellátási helyek összekapcsolása: ennek célja a szolgáltatók összekapcsolása biztonságos adathálózatokon keresztül és interoperábilis alkalmazások segítségével. Ennek része az epsos projekt, az e-kórlap és az e-recept. az ellátásban résztvevő személyek összekapcsolása: ennek célja, hogy az otthonukban tartózkodó betegek állapotáról folyamatosan adatot nyerjen, az adatokat feldolgozza és a szolgáltatókkal megossza. Ennek része a személyes egészségügyi rendszerek (personal health systems, PHR), telemedicina és telemonitoring rendszerek (RPM) teljes kép a betegek egészségügyi állapotáról: ennek része a környezeti, a beteg állapotával kapcsolatos és genetikai adatok kinyerése és feldolgozása, amit bioszenzorok és biochipek segítenek. Az EU szakpolitikája több eszközzel segíti elő a fenti célok megvalósulását, amelyek a tagállamok számára közvetlen feladatot keletkeztetnek, a projektek megrendelői és a szállítók számára pedig általában közvetetten jelentkeznek, ilyenek elsősorban: Egészségügyre és e-egészségügyre vonatkozó szakpolitikai dokumentumok és szabályozás, amely a tagállamok számára határoz meg akciókat, valamint Irányelveket, amelyeket a tagállamok jogába át kell ültetni, de nem közvetlenül hatályosak a jogalanyok számára Az egészségügyet közvetve érintő szakpolitikák és szabályozás, ami kiterjed többek között az általános szabványalkotásra, a személyes adatok védelmére, a belső piac szabályozására Szabványosítás, amely a belső piac megvalósítását szolgálja az e-egészségügy területén is K+F tevékenység, amely EU-szintű projektek révén segíti elő többek között az interoperabilitás megvalósulását, az elektronikus betegeadatok on-line hozzáférését, a személyre szabott egészséget, a betegbiztonságot, a telemedicina fejlődését és az egészségügyi szimulációt és modellezést. A továbbiakban áttekintjük az EU vonatkozó szabályozását, ami Magyarország, mint tagállam részére feladatokat és kötelezettségeket keletkeztet Az Európai Unió egészségügyi ellátással kapcsolatos szabályozása és politikája Összeállította a GYEMSZI szakértői munkacsoportja 128

133 Nemzetközi minősítési gyakorlat Az Európai Unió szabályozása Magyarország, mint tagállam részére közvetlenül vagy közvetve alkalmazandó. Az egészségügyi informatikával kapcsolatos szabályozás egyrészt az egészségüggyel és magával az egészségügyi informatikával, másrészt az erre ható határterületekkel kapcsolatos szabályozásra és törekvésekre osztható. Az egészségüggyel és egészségügyi informatikával kapcsolatos szabályozás legfontosabb elemei a következők: 1. A Szerződés 168. cikkelye rendelkezik arról, hogy biztosítani kell az emberi élet magas szintű védelmét. A cikkelyből nem csak az emberi élet így az egészség védelme következik, hanem az is, hogy ezt magas színvonalon kell biztosítani, tehát a tagállamok és az Unió polgárai közötti különbségek megszüntetésére kell törekedni /24/EU Irányelv a betegek jogainak alkalmazásáról a határon átnyúló egészségügyi ellátásban, amelyet 2015-ig kell a nemzeti jogba átültetni 3. A Bizottság 2008/594/EC Ajánlása az elektronikus egészségügyi nyilvántartási rendszerek határon átnyúló interoperabilitásáról 4. A Bizottság 2008-as kommünikéje a telemedicináról, amely elsősorban a tagállamok számára határoz meg feladatokat 5. A Tanács júniusi határozata meghatározta az EU egészségügyi ellátásának közös értékeit és elveit. A Tanács december 1-i következtetései Biztonságos és hatékony egészségügyi ellátás az e-egészségügyön keresztül címmel specifikusan is meghatározta az EU e-egészségügyi napirendjét, amit a Magyar Elnökség 2011-es kommünikéje megerősített és kiegészített. A Tanács decemberi következtetései négy területet emelnek ki az e-egészségügy fejlesztése területén: 1) a tagállamok köteleződjenek el az e-egészségügy fejlesztése, mint az egészségügyi ellátáshoz való hozzáférés, az ellátás minősége és biztonsága javításának egyik fő eszköze mellett 2) fejlesszék az e- egészségüggyel kapcsolatos bizalmat a betegbiztonság, adatvédelem és a magánélet szentsége tiszteletben tartásának biztosításával 3) az egészségügyi adatok védelme és a jogi szabályozás egyértelműsítése 4) a technikai kérdések megoldása és a piac fejlődésének elősegítése. 6. A Bizottság 2008-as Fehér Könyve Együtt az egészségért: stratégiai megközelítés ra az EU egészségügyi stratégiájának három irányát határozza meg. Az egyik iránya expliciten az új technológiák és az elektronikus egészségügy alkalmazása. További irányok az egészséges idősödés elősegítése, ami feltételezi az idősek folyamatos monitorozását és az ellátásukban résztvevők közötti kapcsolatot. A harmadik irány a polgárokat érintő egészségügyi fenyegetésekre adott válasz. 7. A Bizottság 403-as Mandátuma a CEN, a CENELEC és az ETSI részére az e- egészségügyi interoperabilitási szabványok tárgyában. Összeállította a GYEMSZI szakértői munkacsoportja 129

134 Nemzetközi minősítési gyakorlat A 2008/594/EC ajánlás az egészségügyi informatikai nyilvántartási rendszerek interoperabilitásával kapcsolatban fogalmaz meg ajánlásokat, amit a tagállamok szakpolitikájuk kialakítása során figyelembe vesznek. A természetes és jogi személyekre ez nem ír elő kötelezettséget, ugyanakkor a rendszerek megrendelőinek és így közvetve a rendszerek szállítóinak figyelembe kell venniük ezeket az ajánlásokat a rendszerek tervezése során. Az ajánlások figyelembe veszik egy-egy területen a tagállamok eltérő gyakorlatát, érdekeit és fejlettségét és erre való tekintettel nem fogalmaznak meg jogi kötelezettséget. Az ajánlás legfontosabb pontjai: az Ajánlást a tagállamoknak a Bizottság ajánlása szerint 2015-ig kell megvalósítaniuk. A jelenlegi és a következő költségvetési periódusra tervezett egészségügyi informatikai projektek tervezése során ezért ezeket az ajánlásokat a tervezés során már célszerű figyelembe venni. Az Ajánlás bevezető rendelkezései (12) szakasza szerint az adatoknak szabadon kell áramolniuk a tagállamok között, azonban a betegek alapvető jogainak tiszteletben tartását biztosítani kell ennek során. A személyes adatok védelmére a 93/46/EC és a 2002/58/EC irányelvek vonatkoznak, amelyeket a tagállamok a nemzeti jogalkotásban érvényesítenek. A 6 (a) pont értelmében a tagállamok megállapodnak a betegek azonosítására és az egészségügyi dolgozók azonosítására vonatkozó útmutatás kialakításában. Erre a szakaszra alapozva, az elkészülő nem jogszabályi szintű útmutatást kell figyelembe venni az egészségügyi informatikai rendszerek tervezése során. A (7) szakasza a technikai interoperabilitással kapcsolatos ajánlásokat tartalmazza. Az ajánlás egyrészt felhív a jelenleg létező elektronikus egészségügyi adatokra és információcserére vonatkozó - standardok felmérésére. Az ajánlás szerint tehát nem új standardok alkotására van szükség, hanem a létező standardok, standard információs modellek használatára, és a standardokra alapuló, a projekt-szintű specifikáció során használható profilok kialakítására. Új lehetőség szerint nyílt standardokat csak a jelenleg létezőkhöz képest javasol kialakítani. A (8) szakasz a szemantikai interoperabilitásra vonatkozó ajánlásokat tartalmazza. Az ajánlások szerint, amennyiben lehetséges, a nemzetközileg elfogadott orvosi terminológiát, osztályozásokat, betegségek osztályozását kell használni a rendszerek fejlesztése során. A (9) szakasz a rendszerek tanúsítására vonatkozó ajánlásokat fogalmaz meg. Ezek szerint törekedni kell a rendszerek megfelelőségi tesztelési módszereinek kölcsönös elismerésére. Ennek érdekében egyrészt a már meglevő elektronikus egészségügyre vonatkozó standardokat és profilokat kell alkalmazni, másrészt a megfelelőségi tesztekre vonatkozó iparági standardokat. A (14) szakasz értelmében a rendszereknek felhasználó-barát technológia révén biztosítania kell, hogy a betegek saját maguk rendelkezhessenek egészségügyi adataik megosztásáról és mások számára hozzáférhetővé tételéről kivétel ez alól az Összeállította a GYEMSZI szakértői munkacsoportja 130

135 Nemzetközi minősítési gyakorlat egészségügyi adatok egészségügyi ellátás céljából való tárolása. A rendszereket úgy kell megtervezni, hogy lehetőség szerint azonosítás céljából ne használjanak személyes adatot, hanem csak anonim azonosítókat. Azonosítani kell továbbá azokat az egészségügyi adatokat, amelyek elektronikus hozzáférése az ellátás szempontjából lényeges, és azokat, amelyek ebből a körből kizárhatók (pl. genetikai vagy pszichiátriai adatok). A 2011/24/EU Irányelv a betegek jogainak alkalmazásáról a határon átnyúló egészségügyi ellátásban a tagállamok jogrendszerébe átültetendő szabályokat fogalmaz meg, amelyek többek között az elektronikus egészségügyre vonatkozóan is tartalmaznak előírásokat. Az Irányelv egyfelől megfogalmaz általános értékeket és szabályokat, amelyek a határon átnyúló ellátás alapját jelentik, ilyen: a betegek joga a jó színvonalú ellátáshoz (Bevezető rendelkezések 20. szakasz), a tagállamok kötelezettsége a minőségi és biztonsági standardok javítására (bevezető rendelkezések, 22. szakasz), az egészségügyi állapotra vonatkozó személyes adatok továbbítása és az ezekhez való hozzáférés joga az ellátás folyamatossága érdekében (bevezető rendelkezések 25. szakasz), az állampolgárok joga ahhoz, hogy az ellátást más tagállamban vegyék igénybe, ideértve az e-egészségügyi szolgáltatásokat is (bevezető rendelkezések 26. szakasz), az e-egészségügyi rendszerek közötti interoperabilitás elérése (bevezető rendelkezések 57. szakasz),annak érdekében, hogy a tagállamok egészségügyi ellátás feletti felügyeleti joga. A 10. szakasz szerint a tagállamoknak elő kell segíteniük a határon átnyúló ellátást info-kommunikációs technológiák révén. Az egészségügyi informatikát érintő, de nem egészségügyi tárgyú szabályozás fontosabb elemei: 1. A Szerződés belső piaccal kapcsolatos rendelkezései, amelyek a személyek, a szolgáltatások, a tőke és az áru szabad mozgását írják elő. Az egészségügy esetében a közösségi jog elismeri a tagállamok azon jogát, hogy az egészségügyi rendszerek tervezhetősége érdekében, ill. indokolt egészségügyi okból korlátozhatják a négy szabadság érvényesülését. Az Európai Bíróság azonban több határozatában is konzekvensen rámutatott arra, hogy a beteg nem elérhető vagy nem időben elérhető szolgáltatás esetén, ha ennek igénybevétele az egészségi állapotát érdemben befolyásolja, más tagállamban is igénybe veheti a szolgáltatást, amelynek körébe tartozik az egészségügyi informatika is. A Szerződés továbbá explicit is megfogalmazza az emberi élet magas szintű védelmének kötelezettségét (168.szakasz) és az ezzel kapcsolatos új fejlesztések alkalmazásának szükségességét (114.szaaksz). 2. Az Európai Unió Alapvető Jogok Chartája 8. cikkelye a személyes adatok védelméről 3. A 95/46/EC Irányelv az egyének védelméről a személyes adatok védelme és az adatok szabad mozgása tekintetében 4. A 2002/58/EC Irányelv a személyes adatok védelméről az elektronikus kommunikáció során Összeállította a GYEMSZI szakértői munkacsoportja 131

136 Nemzetközi minősítési gyakorlat 5. A Digital Agenda (2011), az EU 2020 stratégia része. A Digital Agenda 13. kulcs akciója azt a célt tűzi ki, hogy kísérleti projekteken keresztül 2015-ig minden európai polgár számára biztosítsa az egészségügyi adataihoz való biztonságos online hozzáférést és 2020-ig elérje a telemedicinális szolgáltatások széleskörű bevezetését. A 14-es kulcs akció célja az, hogy meghatározza a betegadatok egy minimális körét, amely lehetővé teszi az elektronikusan hozzáférhető és cserélhető betegadatok interoperabilitását 2012-ig. Célul tűzi ki továbbá az EU-szintű standardok bevezetését az e-egészségügy területén és az e-egészségügyi rendszerek tanúsítását 2015-ig. 6. Az elektronikus kereskedelemről szóló 2000/31/EC Irányelv. Az Irányelv különösen jelentős az e-egészségügy szempontjából, mivel az Európai Bíróság határozata szerint az egészségügyi szolgáltatások sem vonhatók ki a belső piac hatálya alól. Az Irányelv megállapítja többek között azt, hogy egy terméknek (szolgáltatásnak) milyen megfelelőségi kritériumokat kell teljesítenie. Eszerint az üzleti szolgáltatók közötti (business to business) szolgáltatás (pl. telepatológia) esetén a szolgáltatásnyújtás helye szerinti követelményeknek kell megfelelni, fogyasztóknak nyújtott szolgáltatás (business to consumer) esetén viszont a szolgáltatás használója szerinti ország követelményeit kell teljesíteni (pl. telemonitoring). Az egészségügyi és e-egészségügyi szolgáltatások továbbá azonos követelményeknek kell, hogy megfeleljenek annak érdekében, hogy egyes szolgáltatásokkal szemben ne alakuljon ki piaci diszkrimináció (pl. a telemedicina szolgáltatás esetlegesen alacsonyabb ára miatt alacsonyabb követelményrendszer esetén). Szabványosítási törekvések A szabványosítás célja általában véve a belső piacot korlátozó tényezők felszámolása, az egészségügy területén pedig specifikusan a személyek és szolgáltatások szabad áramlásának lehetővé tétele. A két általános szabványosítási testület az ISO és a CEN utóbbi az EU által elismert szervezet, amely az EU kötelezésére is alkot szabványokat -, az informatika és telekommunikáció területén specifikus szervezetek a CENELEC és az ETSI, az egészségügy és egészségügyi informatika területén pedig a HL7, az openehr, a DICOM, a LOINC és az IHTSDO a specifikus szabványalkotó szervezetek. A specifikus szabványok egy része CEN (EN)/ISO szabványként is elfogadásra kerül. A szabványalkotást kiegészítik további iparági szervezetek (elsősorban az IHF és a Continua) tevékenysége, amelyek a szabványok gyakorlati alkalmazását leíró profilokat készítenek. A szabványalkotó szervezetek tevékenysége átfed, egyrészt mivel a specifikus szervezetek szabványait az általános célú szervezetek is részben átveszik (pl. az ISO vagy a CEN a HL7 szabványokat), részben pedig a szabványok tartalma is átfed és nem minden esetben konzisztens. A szabványok lényege, hogy alkalmazásuk elősegíti a piac működését azáltal, hogy az egyes államokban azonos gyakorlatot követnek és az elkészült alkalmazások kompatibilisek egymással. A szabványosítás ezért az EU alapvető törekvése minden iparágban és az egészségügy területén is. Az egészségügy területén ezen túl a szabványok alkalmazása biztosíthatja a különböző informatikai rendszerek interoperabilitását, amely feltétele annak, Összeállította a GYEMSZI szakértői munkacsoportja 132

137 Nemzetközi minősítési gyakorlat hogy a személyek egészségügyi adatai az egyes tagállamok között mozogjanak, ezáltal megvalósuljon a magas színvonalú egészségügyi ellátáshoz való egyenlő hozzáférés joga. A problémát az okozza, hogy a szabványok általában nem alkalmazhatók egyértelműen a projekt szintű specifikációkban. A szabványok és a specifikációk közötti rés áthidalását segítik az olyan szervezetek, mint az IHF, valamint az EU 403-as mandátuma alapján a szabványok összehangolása és a gyakorlati alkalmazást lehetővé tevő un. profilok kidolgozása egyes kulcsterületeken. Az European Institute for Health Records (EuroRec) célja, hogy a létező szabványok, specifikációk használatát elősegítése, támogassa, összehangolja a tagállamok EHR rendszerek minősítéséért felelős szerveinek ezzel kapcsolatos munkáját és a Bizottsággal együttműködésben kidolgozza az EHR rendszerek európai szintű minősítésének követelményeit és rendszerét. Az EuroRec ezzel kapcsolatban egyrészt kidolgozott egy jelenleg is alkalmazott önkéntes minősítési rendszert, másrészt az Európai Bizottság támogatásával megvalósuló projektekben, így elsősorban a Q-REC és az EHR-Q TN projektek keretében kidolgozta az létező szabványok jegyzékét és a rendszerekkel kapcsolatos funkcionális követelmények jegyzékét. Az EuroRec egy harmadik fontos tevékenysége a klinikai adatstruktúrákat leíró EHR archetípusokkal és ezek táraival kapcsolatos minőségi követelmények leírása. Az Eurorec minősítési rendszere nem helyettesíti a tagállamok minősítési rendszerét, azonban az egyik tagállamban már minősített és az EuroRec-nek megfelelő rendszer minősítését nem szükségszerű ismét megkövetelni. Az EuroRec minősítés ( Seal, azaz pecsét) első szintje az EHR rendszerek klinikai adattartalmának megbízhatóságára koncentrál és alapvetően minimumkövetelményeknek való megfelelést jelent. A második szint 50 alapvető funkcionális követelményt tartalmaz (a követelmények elérhetők a GYEMSZI honlapján: Megjegyezzük, hogy az Egyesült Államokban szintén a jelentős szabványalkotó testületek és iparági szereplők részvételével zajlik az egészségügyi informatikai szabványok, ezen belül az EHR szabványok elfogadása, valamint az EHR rendszerek minősítése. A rendszerek minősítése össze van kapcsolva az ellátás finanszírozásával is. Ennek jogi szabályozását az Egészségügyi és Humán Szolgáltatások Minisztériuma (Department of Health and Human Sciences) végzi, a standardok első elfogadott körét a Federal Register július 28-i száma tartalmazza. A szabványok összehangolását és az un. használati esetekhez (use case) való igazítását a HITSP nevű szervezet végzi. Az EU és az USA évi megállapodása alapján a két fél ilyen jellegű tevékenységét összehangolják. Szabványosítási területek áttekintése A szabványok alkalmazási területük szerint lehetnek terület-független (pl. általános információtechnológiai szabvány), terület-specifikus (pl. egészségügyi), általános (pl. minden iparágban alkalmazandó) és alkalmazás-specifikus standardok. Az e-egészségügyi rendszerek középpontjában az EHR rendszerek állnak. Az EHR rendszerekkel kapcsolatosban megfogalmazott általános jellemzők a komponens-orientáció, az architektúra-központúság, a modell-vezérelt architektúra, a referencia információs és üzleti modellek alkalmazása, a referencia terminológiai és ontológiai modellek alkalmazása, a fejlett biztonsági szolgáltatások és a személyiségi jogok védelme, a szemantikai interoperabilitás és a szolgáltatás-orientáció. Összeállította a GYEMSZI szakértői munkacsoportja 133

138 Nemzetközi minősítési gyakorlat Ennek megfelelően az EHR rendszerekkel kapcsolatos releváns standardok kapcsán beszélhetünk architekturális, modellezési, terminológiai, ontológia, osztályozási, azonosítási, biztonsági, infrastrukturális, személyiségi jogi, fejlesztési és más standardokról. A projektek megrendelőinek azt kell biztosítaniuk, hogy az alkalmazások szállítói az alkalmazások tervezése során alkalmazzák a rendelkezésre álló szabványokat és nyilatkozzanak az alkalmazások megfelelőségéről és az esetleges fenntartásokról és ezek okairól. Szervezet Alkalmazási terület ASTM Az USA legjelentősebb szabványosítási szervezete. A szabványok széles területet lefednek. CEN (EN) Kötelezően alkalmazandó, általános. ISO Általános az egészségügyi informatikai szabványok a TC 251 munkacsoport termékei CENELEC ETSI A szabványok az EN szabvány alatt jelennek meg a CEN-el együttműködésben, ezeket technikai jelentések (TR) egészítik ki Európai telekommunikációs szabványosítási intézet. A technikai specifikációtól az EN szabványok kidolgozásáig terjed a tevékenysége. HL7 Elsődlegesen egészségügyi informatikai rendszerek interoperabilitását szolgáló standardok. openehr DICOM LOINC IHTSDO IHE Continua GS1 W3C Elektronikus betegadatok kezelése, tárolása Digitális képalkotó technológiák Orvosi terminológia adatbázis, amely általános kód és azonosítási rendszert alkalmaz, így támogatja a rendszerek közötti kommunikációt. Szemantikai interoperabilitás Specifikus profilok alkotása, amelyek a szabványok gyakorlati alkalmazását biztosítják Ellátás folyamatossága Elektronikus kereskedelem/vonalkódok (betegbiztonság) Web service leíró nyelv (WSDL 1.1) alkalmazások közötti kommunikációra Összeállította a GYEMSZI szakértői munkacsoportja 134

139 Nemzetközi minősítési gyakorlat Megemlítjük, hogy az e-egészségüggyel kapcsolatos szabványokon kívül természetesen számos olyan szabvány, iparági ajánlás van, amit informatikai projektek és alkalmazások tervezése során alkalmazni kell. Ezek közül kiemeljük a projektek tervezése során használandó menedzsment standardokat, így különösen az ITIL-t, amelyet jelen dokumentum egyéb fejezetei is felhasználnak. Amíg az e-egészségügyi szabványok és ajánlások a technikai és szemantikai interoperabilitást biztosítják többek között, addig a menedzsment standardok azt teszik lehetővé, hogy a projektek megrendelői és szállítói közös, az iparági gyakorlatban bevett szabályokat kövessenek a fejlesztés és az üzemeltetés során. A Bizottság 403-as mandátumának teljesítése (INTEROP projekt) és a specifikus profilok alkalmazása Az Európai Unió kezdeményezése közvetlenül az interoperabilitásra vonatkozó bizottsági Ajánláson és az informatikai szabványosításra vonatkozó ajánláson alapul. Az Európai Uniónak nem célja újabb szabványok kidolgozása, ezért a 403-as mandátumban a szabványosító szervezeteket bízta meg az elektronikus egészségügyre vonatkozó szabványok felmérésével, kiegészítésével és ezekre alapozva a projekt-szintű specifikációkban felhasználható dokumentáció kidolgozásával. A szabványok felmérése és értékelése a CEN, CENELEC és ETSI szabványosítási szervezetek bevonásával zajlott. A specifikációk alapjául szolgáló un. használati esetek és profilok kidolgozása és értékelése az EHI, Continua iparági szervezetek bevonásával történik. A munkának az első fázisa zárult le, amely a szabványok felmérésére irányult, a második fázis, amely 7 specifikus használati esetet (use case) ír le, folyamatban van. A munka eredményeként 7 európai szintű modell use case áll elő, amely a továbbiak alapjául is szolgál. A 7 használati eset: kórlapokhoz való hozzáférés, receptekhez való hozzáférés, egy-egy kórházon és területi egységen (pl. ellátási térség) belüli folyamat (laboratóriumi és/vagy radiológiai vizsgálatok megrendelése és az eredmények elosztása), valamint 2 további laboratóriumi eset és egy kórházon kívüli ellátásra vonatkozó eset. A használati esetek jelentik valójában a rendszerekkel kapcsolatos (felhasználói) követelményeket, amelyeket üzleti (szakmai) és technikai használati esetekre bonthatunk. Az üzleti használati esetek átfednek egymással. A technikai használati esetek már specifikus eseteket írnak le (pl. betegazonosítás), amelyek több üzleti esetben megjelennek. A standardok egy vagy több technikai használati esethez kötődnek. Az átfedéseket kiküszöbölik a technikai használati esetekhez kapcsolódó un. profilok, amelyek több használati esetben újrafelhasználhatók és amelyeken a rendszerek specifikációja alapul (egy interoperabilitási specifikáció több profilt használ fel). A szállítók évente több száz rendszert tesztelnek abból a szempontból, hogy megfelelnek-e a profiloknak, ami többek között ezen rendszerek interoperabilitását biztosítja. A legjelentősebb tesztelő szervezet az IHE, amely évente kb. 300 rendszert tesztel, valamint az ETSI. Az EHI és az ETSI tesztjei során a rendszereket csoportban tesztelik és így minősítik interoperabilitási képességeiket. Ennek alternatívája de gyakorlati szempontból kevésbé megbízható az ISO 9001 szerinti fejlesztési folyamat vagy egy harmadik fél általi tesztelés. A használati esetek és a profiloknak való megfelelés biztosítása jelentősen növeli a rendszerek megfelelőségének átláthatóságát, a standardok ugyanis számos elemében megjelennek a rendszereknek. Amennyiben lehetséges, ezért a profiloknak való megfelelést és az európai szintű használati esetek és profilok alkalmazását kell követni. Az EpSOS az EU Versenyképességi és Innovációs programja keretében futó kezdeményezés, amely 2013-ig gyakorlati, tesztelt eredményeket kíván produkálni a határon átnyúló Összeállította a GYEMSZI szakértői munkacsoportja 135

140 Nemzetközi minősítési gyakorlat egészségügyi ellátás és az e-egészségügyi rendszerek egyes kulcsterületein, úgy mint az e- kórlap és az e-recept, valamint ezeket követően az európai egészségbiztosítási kártya és a betegek egészségügyi adatokhoz való hozzáférése. Az epsos szolgáltatásai web-service szolgáltatásként valósulnak meg. A kommunikáció hivatalosan kijelölt un. nemzeti kapcsolati pontokon (NCP) keresztül történik, amelyek a szolgáltatást nyújtják a felhasználóknak. Öt szolgáltatást definiál a projekt: azonosítás, beteg-adat lekérése és megrendelése, e- gyógyszerkiadás, beteg-beleegyezés. Az epsos a későbbikben ismertetett szabványokon és profilokon alapul. A CALLIOPE az EU kezdeményezése, amely az interoperabilitással kapcsolatos akadályokat és teendőket térképezte fel és felvázolt egy cselekvési menetrendet (Interoperability Roadmap), amely elsősorban tagállami szinten értelmezhető. Fontosabb szabványok Az alábbiakban bemutatjuk a fontosabb e-egészségügyi szabványokat, amelyeket az alkalmazások és projektek tervezése során figyelembe kell venni és amelyekre az EU szabványosítási munkája is alapul. A szabványok aktuális listája megtalálható az EuroRec és a OENO honlapján, valamint az egyes szabványalkotó szervezetek honlapjain. A szabványok változása miatt feltétlenül javasolt ezek áttekintése. Azonosító Megnevezés/Leírás Megjegyzés ASTM ASTM E , ASTM E Azonosítás, biztonság és személyiségi jogok CEN CEN (EN) egészségügyi informatikai standardok CEN CEN CEN DICOM ASTM E1239 CEN 13608: Az egészségügyi ellátás során történő kommunikáció biztonsága CEN 13606: Elektronikus egészségügyi rekord kommunikáció CEN 13729: Biztonságos felhasználó azonosítás Digitális Képalkotás és Kommunikáció A betegek regisztrációját, felvételét, szállítását és elbocsátását kezelő rendszerek (R-ADT) leírásának standardja Kommunikáció Kommunikáció Személyiségi jog/biztonság Összeállította a GYEMSZI szakértői munkacsoportja 136

141 Nemzetközi minősítési gyakorlat ASTM E1284 ASTM E1384 ASTM E1633 ASTM E1714 ASTM E1715 ASTM E1744 ASTM E1762 ASTM E1869 ASTM E2171 ASTM E2183 ASTM E2184 Útmutató az Elektronikus egészségügyi rekordokat támogató klinikai nomenklatúra kialakításához Elektronikus egészségügyi rekord tartalma és struktúrája Az elektronikus egészségügyi rekordokban használt kódolt értékek specifikációja Egységes egészségügyi azonosító tulajdonságai (UHID) Objektum-orientált beteg regisztrációs, -felvételi, - szállítási és elbocsátási (RADT) funkciók az EHR rendszerekben Sürgősségi ellátás az EHR rendszerekben Egészségügyi ellátási információk elektronikus azonosítása Az egészségügyi információ adatbiztonsági, hozzáférési, személyiségi jogi elvei Elektronikus egészségügyi rekordokkal kapcsolatos mérési skálák XML DTD tervezés, architektúra és implementáció Egészségügyi dokumentáció standard specifikációja Összeállította a GYEMSZI szakértői munkacsoportja 137

142 Nemzetközi minősítési gyakorlat ASTM E2211 ASTM E2369 ASTM E2473 EN 1068 Személyes elektronikus egészségügyi rekordok személyei és szolgáltatói közötti kapcsolat specifikációja Ellátás folyamatosságára vonatkozó rekord (CCR) specifikációja Az elektronikus egészségügyi rekord foglalkozás- és környezetegészségügyi nézete Kódolási rendszerek regisztrációja EN 12967:2005 Egészségügyi információs rendszerek standard architektúrája EN EHRcom Elektronikus egészségügyi rekordok kommunikációja EN 14484:2003 (lásd 14485:2004 is) EN EN ENV HL7 Az EU adatvédelmi irányelve által lefedett egészségügyi adatok nemzetközi szintű cseréje Szolgáltatás kérési és riportolási üzenetek GPIC Általános célú információs komponensek Egészségügyi igazgatási információ cseréjére vonatkozó üzenetek V3 üzenetküldési standard (a HL7 V3 modellnek megfelelő rendszerek Magas-szintű adatvédelem Kommunikáció Kommunikáció Kommunikáció Összeállította a GYEMSZI szakértői munkacsoportja 138

143 Nemzetközi minősítési gyakorlat esetén) HL7 GELLO UML-alapú klinikai döntéseket támogató leíró nyelv HL7 CCOW/vizuális integráció Standard protokoll, amely különálló rendszereket támogat a felhasználói és beteg kontextus megosztásában felhasználói szinten. HL7 Standard elektronikus mellékletek Beutalók, elszámolások struktúrája jelentések, standard HL7 Arden syntax Orvosi ismeretek (tudás) kódolására alkalmas nyelv, amely az orvosi/klinikai döntéseket támogatja HL7 Strukturált termék címkézés Gyógyszerek standard termék leírásának modellje HL :2009 Elektronikus egészségügyi adat (personal health record) HL7/ISO 21713:2006 Referencia Információs Modell (RIM) HL7/ISO 27931: verzió üzenetküldési standard HL7/ISO 27932:2009 Klinikai dokumentum architektúra (CDA) Elektronikus egészségügyi nyilvántartó rendszerek funkcióinak leírása Klinikai és adminisztratív környezetben használt adattartalom leírása Informatikai rendszerek által előállított és fogadott tranzakciók interoperabilitási specifikációja. Az üzenetküldést a MML protokoll támogatja. Xml használatán alapuló model, amely biztosítja klinikai dokumentumok cseréjét, gépi és humán értelmezését Összeállította a GYEMSZI szakértői munkacsoportja 139

144 Nemzetközi minősítési gyakorlat IEEE IEEE IEEE IHE profilok ISO 12052:2006/DICOM Betegágy melletti orvosi eszközök kommunikációja - nomenklatúra Betegágy melletti orvosi eszközök kommunikációja számítógépek és orvosi eszközök összeköttetése LAN rendszerekben Betegágy melletti orvosi eszközök kommunikációja alkalmazási entitások közötti kommunikáció A profilok a különböző standardok gyakorlati alkalmazását írják le specifikus adott klinikumi környezetben Orvosi digitális képalkotás és kommunikáció Kommunikáció Kommunikáció Kommunikáció Jelenleg a következő területeken létezik leírt és tesztelt profil: patológia, kardiológia, szemészet, IT infrastuktúra, orvosi laboratórium, radiológia, sugárterápia, betegellátás koordinációja, betegellátással kapcsolatos egyes eszközök ISO Publikus kulcs infrastruktúra Infrastruktúra ISO 18308:2003 Elektronikus egészségügyi referencia architektúra ISO 20514:2005 Elektronikus beteg rekord ISO Elektronikus egészségügyi kártya ISO 22857:2004 Betegadatok védelme a határon átnyúló ellátásban ISO CT 215 Az ISO egészségügyi informatikai bizottsága, amely a releváns standardokat dolgozza ki. Adatvédelem Összesen 59 szabvány ezek közül csak néhány fontosabbat sorolunk fel Összeállította a GYEMSZI szakértői munkacsoportja 140

145 Nemzetközi minősítési gyakorlat ISO/TR 18307:2001 Üzenetküldési és kommunikációs standardok interoperabilitása és kompatibilitása Kommunikáció ISO/TS 25237:2008 Pszeudo-anonimizáció Azonosítás openehr OpenEHR keretrendszer Az egészségügyi adatok kezelését, tárolását, kinyerését leíró standard OpenEHR/EN Elektronikus beteg adat kommunikáció SNOMED CT /IHTSDO) Orvosi terminológia standard leírása Az elektronikus beteg dokumentáció egészének vagy egy részének továbbítását támogató információs modell Rendszerek szemantikai interoperabilitása Összeállította a GYEMSZI szakértői munkacsoportja 141

146 Gazdasági és VIR rendszerek adatkezelési követelményei 8.2 Egészségügyi gazdasági információs rendszerek és VIR rendszerek speciális adatkezeléssel kapcsolatos minősítése ajánlásai Törvényi háttér Esetfinanszírozott adatok jelentése 43/1999. (III. 3.) Kormányrendelet. Tételes elszámolású eszközök és a nagy értékű műtéti beavatkozások (17. sz. melléklet) Az esetfinanszírozott beavatkozások teljesítmény jelentése számítógépes adathordozón (mágneslemezen) szabványos formátumban küldhető. A havi teljesítményadatokat illetve az esetleges korrekciós adatokat külön adatállományokba kell szervezni. Jelenlegi adatküldési rekordkép az alábbi személyes adatokat tartalmazza: Beteg személyazonosító jele Beteg születési dátuma Beteg neme Beavatkozás dátuma Beavatkozás indikáció A fenti személyes adatokon túl megtalálható a Elvégzett beavatkozás kódja Térítési kategória Elvégzett beavatkozás forintérték Tételes elszámolású eszközök és a nagy értékű műtéti beavatkozások 43/1999. (III. 3.) Kormányrendelet Tételes elszámolású eszközök és a nagy értékű műtéti beavatkozások (17. sz. melléklet) A kórházi információs rendszerek az költség adatok kimutatása illetve az eszközök nyilvántartása érdekében a műtét során felhasznált anyagokról tételes, betegre szóló bizonylat készül. A bizonylat vagy a gazdasági rendszerben vagy a klinikai rendszerben kerül rögzítésre, de a raktári mozgásokkal és felhasználásokkal kapcsolatban a beteg személyes adati a gazdasági rendszerben tárolásra kerülnek. Nagy értékű anyagok betegre történő rögzítését törvény írja elő () Ráfordítási adatgyűjtés Az egészségügyi szolgáltatások, a finanszírozási paraméterek folyamatos karbantartását a 6/1998. (III. 11.) NM rendelet szabályozza. Az átfogó karbantartáshoz szükséges adatbázis létrehozásának egyik fő forrása a kijelölt ellátási területeken, ellátási esetekhez, szolgáltatásokhoz felhasznált erőforrások kijelölt időszakban, kijelölt szolgáltatóknál történő megfigyelése Orvosválasztás kapcsán felmerülő díj Összeállította a GYEMSZI szakértői munkacsoportja 142

147 Gazdasági és VIR rendszerek adatkezelési követelményei január 1-jétől külön, részleges térítési díj megfizetése mellett lehetőség van arra, hogy az egészségügyi intézmény munkarendje alapján a beteghez beosztott orvos helyett másik orvost kérjen a beteg, ha ezt a választást a beteg egészségi állapota által indokolt ellátás szakmai tartalma és az ellátás sürgőssége nem zárja ki. A részleges térítési díj ellenében a beteg olyan orvost is választhat, aki az ellátó egészségügyi szolgáltatónál nem áll munkaviszonyban (közalkalmazotti jogviszonyban) Fizetős szolgáltatások Egyes egészségügyi ellátásokra a szolgáltató térítési díjat állapíthat meg, amelyekről a szolgáltatás megkezdése előtt köteles a biztosítottat tájékoztatni. A részleges térítési díj képzésének szabályai, illetőleg több esetben pontos összege a térítési díj ellenében igénybe vehető egyes egészségügyi szolgáltatások térítési díjáról szóló 284/1997. (XII. 23.) Korm. rendelet 1. sz. melléklete meghatározott, attól érvényesen eltérni nem lehet.pl: a terhesség megszakítás térítési díja évi LXXIX. Törvény 284/1997. (XII. 23.) Korm. Rendelet térítési díj ellenében igénybe vehető egyes egészségügyi szolgáltatások térítési díjáról Vizitdíj, kórházi napidíj Megjelenés helye, ideje: Magyar Közlöny 2006/156. (XII. 18.) Hatályosság kezdete:2007. január 1. A 7., 17. és a 19. (1) bekezdés február 15-én, a május 1-jén lépett hatályba február 15-én bevezetésre került a vizitdíj és a kórházi napidíj, a beteg-orvos találkozások csökkentésére és a társadalombiztosítás biztosítási körének csökkentésére, a költségek részleges áthárítására érdekében. Igaz, hogy népszavazás eredményét követően március 31-ével megszüntetésre került, de hasonló intézkedésre a gazdasági rendszereket fel kell készíteni. A vizitdíjat nyugta ellenében kellett megfizetni. A nyugtának tartalmaznia kellett a beteg nevét, a tajszámát és a dátumot. A nyugta az intézetek nagy részében a klinikai és a gazdasági rendszerek integrálását biztosító szoftver (a klinikai rendszer biztosította a beteg személyi adatait) segítségével került kiállításra, tehát a beteg személyi adatai a gazdasági rendszerben kerültek tárolásra Várólistával kapcsolatban évi LXXXIII. törvény a kötelező egészségbiztosítás ellátásairól évi CLIV. törvény az egészségügyről évi CXVI. törvény az egészségbiztosítás hatósági felügyeletéről 287/2006. (XII. 23.) Kormányrendelet a várólista alapján nyújtható ellátások részletes szabályairól 45/2006. (XII. 27.) EüM rendelet a várólista-sorrend kialakításának és az eltérés lehetőségének egészségügyi szakmai feltételeiről 46/2006. (XII. 27.) EüM rendelet a várólista adatainak honlapon történő közzétételére vonatkozó szabályairól Összeállította a GYEMSZI szakértői munkacsoportja 143

148 Gazdasági és VIR rendszerek adatkezelési követelményei Hatókör Jelen anyag hatóköre mindazon egészségügyben működő nem klinikai rendszerekre kiterjed (gazdálkodási rendszerek, VIR rendszer, gyógyszertári rendszer, bér és munkaügyi rendszer, stb.) amelyekbe az egészségügyi ellátás kapcsán beteggel vagy az ellátó személyzettel kapcsolatos személyes adatok vagy különleges személyes adatok kezelése történik. Ezen rendszerekben a személyes adatok kezelését illetőleg a mindenkor hatályos adatvédelmi és az egészségügyi adatvédelmi törvényekben definiáltak szerint kell eljárni mind a betegek mind az ellátó egészségügyi személyzettel kapcsolatosan. Egészségügyi adat: az érintett testi, értelmi és lelki állapotára, kóros szenvedélyére, valamint a megbetegedés, illetve az elhalálozás körülményeire, a halál okára vonatkozó, általa vagy róla más személy által közölt, illetve az egészségügyi ellátó-hálózat által észlelt, vizsgált, mért, leképzett, vagy származtatott adat; továbbá az előzőekkel kapcsolatba hozható, az azokat befolyásoló mindennemű adat (pl. magatartás, környezet, foglalkozás). Amennyiben a beteg gyógykezelése, vagy közegészségügyi okok azt indokolttá teszik, a szexuális szokásokra vonatkozó adat is egészségügyi adatnak minősül. Különleges adat: a) a faji eredetre, a nemzeti, nemzetiségi és etnikai hovatartozásra, a politikai véleményre vagy pártállásra, a vallásos vagy más meggyőződésre, b) az egészségi állapotra, a kóros szenvedélyre, a szexuális életre, valamint a büntetett előéletre vonatkozó személyes adatok. Személyes adat: bármely meghatározott (azonosított vagy azonosítható) természetes személlyel kapcsolatba hozható adat, az adatból levonható, az érintettre vonatkozó következtetés. A személyes adat az adatkezelés során mindaddig megőrzi e minőségét, amíg kapcsolata az érintettel helyreállítható. A személy különösen akkor tekinthető azonosíthatónak, ha őt közvetlenül vagy közvetve név, azonosító jel, illetőleg egy vagy több, fizikai, fiziológiai, mentális, gazdasági, kulturális vagy szociális azonosságára jellemző tényező alapján azonosítani lehet. Hivatkozott törvények: Az 1992 évi LXIII. Törvény a személyes adatok védelméről és a közérdekű adatok nyilvánosságáról (módosította a évi XLVIII.TV.) Az 1996 évi XX. Törvény a személyazonosító jel helyébe lépő azonosítási módokról és az azonosító kódok használatáról Az 1997 évi XLVII törvény Az egészségügyi és a hozzájuk kapcsolódó személyes adatok kezeléséről és védelméről évi CLIV. tv. az egészségügyről A 62/1997. (XII.21.) NM rendelet az egészségügyi és a hozzájuk kapcsolódó személyes adatok kezelésének egyes kérdéseiről évi VI. törvény az egyének védelméről a személyes adatok gépi feldolgozása során Jelen anyag hatókörében nem tartozik mindazon szakmai követelmények specifikálása amelyek a gazdálkodással kapcsolatos funkciók működését és elvárásait tartalmazza. Összeállította a GYEMSZI szakértői munkacsoportja 144

149 Gazdasági és VIR rendszerek adatkezelési követelményei Személyi adatok védelme a nem klinikai rendszerekben A törvényi előírások alapján ellenőrizendő funkciók. A vizsgált szoftverterméket felkészítették-e személyes adatok kezelésére A személyes adatok védelmével kapcsolatos jogosultság kialakítását biztosító funkció, funkciócsoport meglétének és működésének ellenőrzése A személyes adatok kezelésének egyedi felhasználók számára történő engedélyezése megvalósítható-e? A személyes adatok bevitelének egyedi felhasználók számára történő engedélyezése megvalósítható-e? A személyes adatok törlésének egyedi felhasználóhoz történő engedélyezése megvalósítható-e? A személyes adatok nyomtatásának egyedi felhasználóhoz történő engedélyezése megvalósítható-e? A személyes adatok listázásának egyedi felhasználóhoz történő engedélyezése megvalósítható-e? A személyes adatok kezelése a rendszerben (az adat kezelésére nem jogosultak esetén) A rendszerben tárolt személyes adatot tartalmazó tétel kezelése kapcsán az arra nem jogosultak elől oly módon van-e védve az adat, hogy a kapcsolata az érintettel nem helyreállítható (ez történhet egyéb azonosító megjelenítésével vagy a személyes adat kitakarásával, helyettesítésével)? A rendszerben tárolt személyes adatot tartalmazó tétel megtekintése kapcsán az arra nem jogosultak elől oly módon van-e védve az adat, hogy a kapcsolata az érintettel nem helyreállítható (ez történhet például egyéb azonosító megjelenítésével vagy a személyes adat kitakarásával, helyettesítésével)? A rendszerben tárolt személyes adatot tartalmazó tétel nyomtatása kapcsán az arra nem jogosultak elől oly módon van-e védve az adat, hogy a kapcsolata az érintettel nem helyreállítható (ez történhet például egyéb azonosító megjelenítésével vagy a személyes adat kitakarásával, helyettesítésével)? A rendszerben tárolt személyes adatot tartalmazó tétel állományba mentése kapcsán az arra nem jogosultak elől oly módon van-e védve az adat, hogy a kapcsolata az érintettel nem helyreállítható (ez történhet például egyéb azonosító megjelenítésével vagy a személyes adat kitakarásával, helyettesítésével)? A személyes adatok kezelése a rendszerben (az adat kezelésére jogosultak esetén) A rendszerben tárolt személyes adatot tartalmazó tétel kezelése kapcsán az arra jogosultak kezelhetik-e az adatokat (pl: betegszámla felvitel)? A rendszerben tárolt személyes adatot tartalmazó tételsor megtekintése kapcsán az arra jogosultak nyomtathatják-e az adatokat (pl: betegszámla nyomtatás)? A rendszerben tárolt személyes adatot tartalmazó tételsor elemeit nyomtathatják-e az arra jogosultak? A rendszerben tárolt személyes adatot tartalmazó tétel állományba mentése kapcsán az arra nem jogosultak kezelhetik-e az adatokat (pl: ellenőrző lista nyomtatás, file-ba importálás) Összeállította a GYEMSZI szakértői munkacsoportja 145

150 Gazdasági és VIR rendszerek adatkezelési követelményei A személyes adatok kezelésével kapcsolatos tevékenységek naplózása A törvényi előírások alapján ellenőrizendő funkciók. A vizsgált szoftverterméket felkészítették-e a személyi adatok kezelésével kapcsolatos tevékenységek naplózására A személyes adatok védelmével kapcsolatos tevékenységek rendszer szintű megvalósítását biztosító naplózó funkció, funkciócsoport meglétének és működésének ellenőrzése A személyes adatok kezelésével kapcsolatos tranzakciók naplózása beállítható-e a rendszerben? A személyes adatok kezelésével kapcsolatos tranzakciós naplókban tárolt adatok alapján megállapíthatók-e, hogy az adatkezelést ki, mikor, melyik program melyik programrészéből (funkciójából) és melyik számítástechnikai eszközről kezdeményezte? A személyes adatok kezelésével kapcsolatos tranzakciós naplókban tárolt adatok alapján megállapíthatók-e, hogy az adatkezelés során mely adatok kerültek módosításra (módosítás, törlés, adatbevitel,stb.)? A módosítás kapcsán tárolásra kerülnek-e a módosítás előtti és a módosítás utáni adatok minden verziója? A személyes adatok kezelésével kapcsolatos tranzakciós naplók megtekinthetők-e a rendszerben? A személyes adatok kezelésével kapcsolatos tranzakciós naplók nyomtathatók-e a rendszerből? A személyes adatok kezelésével kapcsolatos tranzakciós naplók állományba menthetők-e a rendszerbőn? A személyes adatok kezelésével kapcsolatos tranzakciós naplók mentésre kerülnek-e a rendszerben? A személyes adatok kezelésével kapcsolatos tranzakciós naplók archiválásra kerülnek-e a rendszerben? A személyes adatok továbbításával kapcsolatos tevékenységek naplózása A törvényi előírások alapján ellenőrizendő funkciók. A vizsgált szoftverterméket felkészítették-e a személyi adatok adattovábbításával kapcsolatos tevékenységek naplózására A személyes adatok védelmével kapcsolatos tevékenységek rendszer szintű megvalósítását biztosító adattovábbítást naplózó funkció, funkciócsoport meglétének és működésének ellenőrzése A személyes adatok továbbításával kapcsolatos tranzakciók naplózása beállítható-e a rendszerben? A személyes adatok kezelésével kapcsolatos tranzakciós naplókban tárolt adatok alapján megállapíthatók-e, hogy az adattovábbítást ki, mikor, melyik program melyik programrészéből (funkciójából), melyik számítástechnikai eszközről és mely törvényi előírás utasítására kezdeményezte? A személyi adatokat tartalmazó továbbított állományok (adatküldő, javító és elszámoló állományok) a személyes adatok védelmével kapcsolatos előírás szerint védett módon kerülnek-e tárolásra? Összeállította a GYEMSZI szakértői munkacsoportja 146

151 Gazdasági és VIR rendszerek adatkezelési követelményei Egyéb adatok továbbításával kapcsolatos elvárások A törvényi előírások alapján ellenőrizendő funkciók. Adatok adattovábbításával kapcsolatos tevékenységek A gazdálkodási rendszernek támogatnia kell az államháztartás felé jelentési kötelezettséggel bíró operatív gazdálkodási folyamatait, tranzakcióit és biztosítania kell az egészségügyi intézményeknél alkalmazott szakrendszerek által a gazdálkodási rendszer felé kezdeményezett pénzügyi/gazdasági tranzakciók elektronikus kezelését. A továbbított adatok digitális aláírását A továbbított adatok naplózását és visszakereshetőségét. Felhasználói interfész: Az alkalmazások felhasználói interfészét az egyes alkalmazások esetében úgy kell kialakítani, hogy azok biztosítsák az alkalmazás képernyők, oldalak elvárható sebességű, elérhetőségét az általánosan elterjedt, kereskedelmi forgalomban rendelkezésre álló szélessávú internet kapcsolatokon keresztül az adatbiztonság megőrzése mellett. Összeállította a GYEMSZI szakértői munkacsoportja 147

152 Portál követelmények 8.3 Intézményi portálok közzététellel kapcsolatos tartalmi követelményei Törvényi háttér A honlapon történő közzététel kötelezettséggel kapcsolatban Az elektronikus információszabadságról szóló évi CX törvény, (Eitv.) törvényből adódó közzétételi kötelezettségek,és o Az Eitv. 6. (2) bek. szerint Jogszabály egyes ágazatokra, a közfeladatot ellátó szervtípusra vonatkozóan meghatározhat egyéb közzéteendő adatokat (különös közzétételi lista). o Az Eitv. 6. (3) bek. értelmében A közfeladatot ellátó szerv vezetője az adatvédelmi biztos véleményének kikérésével, valamint jogszabály a közfeladatot ellátó szervre, azok irányítása, felügyelete alá tartozó szervekre vagy azok egy részére kiterjedő hatállyal további kötelezően közzéteendő adatkört határozhat meg (egyedi közzétételi lista) a közpénzek felhasználásával, a köztulajdon használatának nyilvánosságával, átláthatóbbá tételével és ellenőrzésének bővítésével összefüggő egyes törvények módosításáról szóló évi XXIV. törvény, a közbeszerzésekről szóló évi CXXIX. törvény, valamint a 305/2005. korm. rendelet o A 305/2005. korm. rend. 6/A. (1) bek. alapján minden intézet a honlapján a Közérdekű adatok között köteles feltüntetni a közzéteendő adatok teljes körét (vezetői döntés alapján közzéteendő adatok) Várólistával kapcsolatban évi LXXXIII. törvény a kötelező egészségbiztosítás ellátásairól évi CLIV. törvény az egészségügyről évi CXVI. törvény az egészségbiztosítás hatósági felügyeletéről 287/2006. (XII. 23.) Kormányrendelet a várólista alapján nyújtható ellátások részletes szabályairól 45/2006. (XII. 27.) EüM rendelet a várólista-sorrend kialakításának és az eltérés lehetőségének egészségügyi szakmai feltételeiről 46/2006. (XII. 27.) EüM rendelet a várólista adatainak honlapon történő közzétételére vonatkozó szabályairól Az anyag elkészítésénél figyelembe vettük a NEFI elődjének Egészségügyi Minisztérium Belső Ellenőrzése által adott iránymutatásokat és ellenőrzési terveket. Összeállította a GYEMSZI szakértői munkacsoportja 148

153 Portál követelmények Szervezeti és személyzeti adatok A törvényi előírások alapján megjelenítendő és ellenőrizendő tartalom. Megjelenítették-e a közfeladatot ellátó szerv nevét székhelyét postai címét telefonszámát faxszámát elektronikus levélcímét honlapja ügyfélszolgálatának elérhetőségét Megjelenítették-e a közfeladatot ellátó szerv szervezeti felépítését a szervezeti egységeket az egyes szervezeti egységek feladatait Megjelenítették-e a közfeladatot ellátó szerv vezetőinek nevét beosztását elérhetőségét (telefon- és faxszáma, elektronikus levélcíme) Megjelenítették-e a közfeladatot ellátó szervnél az egyes szervezeti egységek vezetőinek nevét beosztását elérhetőségét (telefon- és faxszáma, elektronikus levélcíme) Megjelenítették-e a szervezeten belül illetékes ügyfélkapcsolati vezető nevét az ügyfélfogadási rendet Megjelenítették-e a közfeladatot ellátó szerv irányítása, felügyelete, vagy ellenőrzése alatt álló, vagy alárendeltségében működő más közfeladatot ellátó szervek nevét székhelyét postai címét telefonszámát faxszámát elektronikus levélcímét ügyfélszolgálatának elérhetőségét Megjelenítették-e a közfeladatot ellátó szerv többségi tulajdonában álló, illetve részvételével működő gazdálkodó szervezet (Ptk.685. c.) pontja) nevét székhelyét elérhetőségét (telefon- és faxszáma, elektronikus levélcíme) tevékenységi körét képviselőjének nevét a közfeladatot ellátó szerv részesedésének mértékét Megjelenítették-e a közfeladatot ellátó szerv által alapított közalapítvány(ok) nevét székhelyét alapító okiratát Összeállította a GYEMSZI szakértői munkacsoportja 149

154 Portál követelmények kezelő szervének tagjait Megjelenítették-e a közfeladatot ellátó szerv által alapított lapok nevét a szerkesztőség nevét címét a kiadó nevét címét a főszerkesztő nevét Megjelenítették-e a közfeladatot ellátó szerv felettes, illetve felügyeleti szervének, ennek hiányában a közfeladatot ellátó szerv felett törvényességi ellenőrzést gyakorló szerv nevét székhelyét postai címét telefonszámát faxszámát elektronikus levélcímét ügyfélszolgálatának elérhetőségét Javasolt ellenőrzési terv A közzétételi szabályzat készítésére sor került-e? (305/2005. korm. rendelet 3.. (1) bek.); A közzétételi szabályzat készítésére sor került-e? (305/2005. korm. rendelet 3.. (2) bek.); Kinevezték-e az adatfelelőst? Az Eitv. végrehajtásával összefüggő kötelezettségek teljesítésnek ellenőrzésére sor került-e 305/2005. korm. rendelet 3.. (3) bek-ben foglaltak szerint? A honlap kialakítása során figyelembe vették-e a 305/2005. korm. rendelet előírásait?( 305/2005. korm. rendelet /A.) Az Eitv. továbbá a 305/2005. korm. rendelet előírásai alapján bejelentkeztek-e az egységes közadatkereső rendszerbe? Az adatfelelős kezdeményezte-e a bejelentkezést a központi elektronikus jegyzékbe? Megjelenítették-e közfeladatot ellátó szerv adatait Eitv. Melléklete I. 1. pontjában meghatározott módon és tartalommal Megjelenítették-e közfeladatot ellátó szerv adatait Eitv. Melléklete I. 2. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szerv vezetőinek adatait az Eitv. Melléklete I. 3. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szervnél az egyes szervezeti egységek vezetőinek adatait az Eitv. Melléklete I. 3. pontjában meghatározott módon és tartalommal Nyilvánossá tették-e a szervezeten belül illetékes ügyfélkapcsolati vezető adatait az Eitv. Melléklete I. 4. pontjában meghatározott módon és tartalommal Feltüntették-e a közfeladatot ellátó szerv irányítása, felügyelete, vagy ellenőrzése alatt álló, vagy alárendeltségében működő más közfeladatot ellátó szervek adatait az Eitv. Melléklete I. 6. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szerv többségi tulajdonában álló, illetve részvételével működő gazdálkodó szervezet (Ptk.685. c.) pontja) adatait az Eitv. Melléklete I. 7. pontjában meghatározott módon és tartalommal Nyilvánossá tették-e a közfeladatot ellátó szerv által alapított közalapítvány(ok) adatait az Eitv. Melléklete I. 8. pontjában meghatározott módon és tartalommal Feltüntették-e a közfeladatot ellátó szerv által alapított lapok adatait az Eitv. Melléklete I. 9. pontjában meghatározott módon és tartalommal Feltüntették-e a közfeladatot ellátó szerv felettes, illetve felügyeleti szervének, ennek hiányában a közfeladatot ellátó szerv felett törvényességi ellenőrzést gyakorló szervnek az adatait az Eitv. Melléklete I. 10. pontjában meghatározott módon és tartalommal Összeállította a GYEMSZI szakértői munkacsoportja 150

155 Portál követelmények Tevékenységre, működésre vonatkozó adatok A törvényi előírások alapján megjelenítendő és ellenőrizendő tartalom. Megjelenítették-e a közfeladatot ellátó szerv feladatát meghatározó jogszabályt hatáskörét meghatározó jogszabályt alaptevékenységét meghatározó jogszabályt a szervre vonatkozó alapvető jogszabályokat az állami irányítás egyéb jogi eszközeit a Szervezeti és Működési Szabályzat vagy az Ügyrend hatályos és teljes szövegét Megjelenítették-e az országos hatáskörű szervek esetén a közfeladatot ellátó szerv feladatáról szóló tájékoztatást magyar nyelven angol nyelven tevékenységéről szóló tájékoztatást magyar nyelven angol nyelven Megjelenítették-e a közfeladatot ellátó szerv által nyújtott vagy költségvetésből finanszírozott közszolgáltatások megnevezését tartalmát a közszolgáltatások igénybevételének rendjét a közszolgátaásért fizetendő díj mértékét az abból adott kedvezményeket Megjelenítették-e a közfeladatot ellátó szerv által fenntartott adatbázisok jegyzékét fenntartott nyilvántartások jegyzékét az adatvédelmi nyilvántartásba bejelentendő nyilvántartásoknak az Avtv a szerinti adatait: a közfeladatot ellátó szerv által - alaptevékenysége keretében - gyűjtött adatok fajtái a hozzáférés módja másolatkészítés költségei Feltüntették-e a közfeladatot ellátó szerv nyilvános kiadványainak címét témáját hozzáférés módját a kiadvány ingyenességét a költségtérítés mértékét Megjelenítették-e a közfeladatot ellátó szerv által kiírt pályázatok szakmai leírását eredményeit indoklásukat Megjelenítették-e a közfeladatot ellátó szervnél végzett alaptevékenységgel kapcsolatos vizsgálatok, ellenőrzések nyilvános megállapításait Megjelenítették-e a közfeladatot ellátó szerv feladatellátásnak teljesítményére kapacitásának jellemzésére hatékonyságának mérésére szolgáló Összeállította a GYEMSZI szakértői munkacsoportja 151

156 Portál követelmények mutatókat és értéküket időbeli változásukat teljesítményének mérésére mutatókat és értéküket időbeli változásukat Megjelenítették -e a közérdekű adatok megismerésére irányuló igények intézésének rendjét az illetékes szervezeti egység nevét elérhetőségét (telefon- és faxszáma, elektronikus levélcíme) az adatvédelmi felelős nevét az információs jogokkal foglalkozó személy nevét Megjelenítették -e a közfeladatot ellátó szerv tevékenységére vonatkozó, jogszabályon alapuló statisztikai adatgyűjtés eredményeit időbeli változásukat Megjelenítették -e a közérdekű adatokkal kapcsolatos kötelező statisztikai adatszolgáltatás adott szervre vonatkozó adatait Megjelenítették -e azon közérdekű adatok hasznosítására irányuló szerződések listáját, amelyekben a közfeladatot ellátó szerv az egyik szerződő fél Megjelenítették -e a közfeladatot ellátó szerv kezelésében lévő közérdekű adatok felhasználására vonatkozó általános szerződési feltételeket hasznosítására vonatkozó általános szerződési feltételeket Megjelenítették-e a közfeladatot ellátó szervre vonatkozó különös és egyedi közzétételi listát Javasolt ellenőrzési terv Feltüntették-e a közfeladatot ellátó szervre vonatkozó adatokat az Eitv. Melléklete II. 1. pontjában meghatározott módon és tartalommal Feltüntették-e az országos illetékességű szervek esetén a közfeladatot ellátó szervre vonatkozó adatokat az Eitv. Melléklete II. 2. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szerv által nyújtott vagy költségvetésből finanszírozott közszolgáltatásokra vonatkozó adatokat az Eitv. Melléklete II. 5. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szerv által fenntartott adatbázisokkal, illetve nyilvántartásokkal összefüggő adatokat az Eitv. Melléklete II. 6. pontjában meghatározott módon és tartalommal Feltüntették-e a közfeladatot ellátó szerv nyilvános kiadványaira vonatkozó adatokat az Eitv. Melléklete II. 7. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szerv által kiírt pályázatokkal összefüggő adatokat az Eitv. Melléklete II. 10. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szervnél végzett alaptevékenységgel kapcsolatos adatokat az Eitv. Melléklete II. 11. pontjában meghatározott módon és tartalommal Feltüntették-e a közfeladatot ellátó szerv feladatellátására vonatkozó adatokat az Eitv. Melléklete II. 12. pontjában meghatározott módon és tartalommal Feltüntették-e a közérdekű adatok megismerésére irányuló igényekel összefüggő adatokat az Eitv. Melléklete II. 13. pontjában meghatározott módon és tartalommal Feltüntették-e a közfeladatot ellátó szerv tevékenységére vonatkozó adatokat az Eitv. Melléklete II. 14. pontjában meghatározott módon és tartalommal Feltüntették-e a közérdekű adatokkal kapcsolatos kötelező statisztikai adatszolgáltatásra vonatkozó adatokat az Eitv. Melléklete II. 15. pontjában meghatározott módon és tartalommal Feltüntették-e azon közérdekű adatok hasznosítására irányuló szerződésekre vonatkozó adatokat az Eitv. Melléklete II. 16. pontjában meghatározott módon és tartalommal Feltüntették-e a közfeladatot ellátó szerv kezelésében lévő közérdekű adatokra vonatkozó adatokat az Eitv. Melléklete II. 17. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladato ellátó szervre vonatkozó különös és egyedi közzétételi listát Összeállította a GYEMSZI szakértői munkacsoportja 152

157 Portál követelmények Gazdálkodási adatok A törvényi előírások alapján megjelenítendő és ellenőrizendő tartalom. Megjelenítették-e a közfeladatot ellátó szerv éves (elemi) költségvetését számviteli törvény szerinti beszámolóját a költségvetés végrehajtásáról - a külön jogszabályban meghatározott módon és gyakorisággal készített beszámolók Megjelenítették-e a közfeladatot ellátó szervnél foglalkoztatottak létszámára vonatkozó összesített adatokat személyi juttatására vonatkozó összesített adatokat összesítve a vezetők illetményére vonatkozó adatokat összesítve a vezetők munkabérére vonatkozó adatokat összesítve a vezetők rendszeres juttatásaira vonatkozó adatokat összesítve a vezetők költségtérítésére vonatkozó adatokat egyéb alkalmazottaknak nyújtott juttatások fajtájára vonatkozó adatokat összesítve egyéb alkalmazottaknak nyújtott juttatások mértékére vonatkozó adatokat összesítve Megjelenítették -e a közfeladatot ellátó szerv költségvetéséből nyújtott nem normatív támogatások kedvezményezettjeinek nevére vonatkozó adatokat támogatás céljára vonatkozó adatokat a támogatás összegére vonatkozó adatokat a támogatási program megvalósítási helyére vonatkozó adatokat céljellegű támogatások kedvezményezettjeinek nevére vonatkozó adatokat támogatás céljára vonatkozó adatokat a támogatás összegére vonatkozó adatokat a támogatási program megvalósítási helyére vonatkozó adatokat fejlesztési támogatás kedvezményezettjenek nevére vonatkozó adatokat támogatás céljára vonatkozó adatokat a támogatás összegére vonatkozó adatokat a támogatási program megvalósítási helyére vonatkozó adatokat Megjelenítették-e az államháztartás pénzeszközei felhasználásával, az államháztartáshoz tartozó vagyonnal történő gazdálkodással összefüggő - a külön jogszabályban meghatározott értékű árúbeszerzésre vonatkozó szerződések megnevezését (típusa) tárgyát a szerződést kötő felek nevét a szerződés értékét határozott időre kötött szerződés esetében annak időtartamát építési beruhárzásra vonatkozó szerződések megnevezését (típusa) tárgyát a szerződést kötő felek nevét a szerződés értékét határozott időre kötött szerződés esetében annak időtartamát szolgáltatás megrendelésre vonatkozó szerződések Összeállította a GYEMSZI szakértői munkacsoportja 153

158 Portál követelmények megnevezését (típusa) tárgyát a szerződést kötő felek nevét a szerződés értékét határozott időre kötött szerződés esetében annak időtartamát vagyonértékesítésre vonatkozó szerződések megnevezését (típusa) tárgyát a szerződést kötő felek nevét a szerződés értékét határozott időre kötött szerződés esetében annak időtartamát vagyonhasznosításra vonatkozó szerződések megnevezését (típusa) tárgyát a szerződést kötő felek nevét a szerződés értékét határozott időre kötött szerződés esetében annak időtartamát vagyon, vagy vagyoni értékű jog átadására vonatkozó szerződések megnevezését (típusa) tárgyát a szerződést kötő felek nevét a szerződés értékét határozott időre kötött szerződés esetében annak időtartamát koncesszióba adásra vonatkozó szerződések megnevezését (típusa) tárgyát a szerződést kötő felek nevét a szerződés értékét határozott időre kötött szerződés esetében annak időtartamát Megjelenítették-e a közfeladatot ellátó szerv által nem alapfeladatai ellátására fordított, 5 millió forintot meghaladó kifizetéseket társadalmi szervezet támogatás esetén foglalkoztatottai szakmai és munkavállalói érdekképviseleti szervei számára foglalkoztatottai, ellátottjai oktatási, kulturális, szociális és sporttevékenységét segítő szervezet támogatására alapítványok által ellátott feladatokkal összefüggő kifizetésekre Javasolt ellenőrzési terv Megjelenítették-e a közfeladatot ellátó szervre vonatkozó adatokat az Eitv. Melléklete III. 1. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szervnél foglalkoztatottak létszámára és juttatásaira vonatkozó adatokat az Eitv. Melléklete III. 2. pontjában meghatározott körben, módon és tartalommal Megjelenítették-e a közfeladatot ellátó szerv költségvetéséből nyújtott nem normatív támogatások kedvezményezettjeire vonatkozó adatokat az Eitv. Melléklete III. 3. pontjában meghatározott módon és tartalommal céljellegű támogatások kedvezményezettjeire vonatkozó adatokat az Eitv. Melléklete III. 3. pontjában meghatározott módon és tartalommal fejlesztési támogatás kedvezményezettjeire vonatkozó adatokat az Eitv. Melléklete II. 3. pontjában meghatározott módon és tartalommal Megjelenítették-e az államháztartás pénzeszközei felhasználásával, az államháztartáshoz tartozó vagyonnal történő gazdálkodással összefüggő - a külön jogszabályban meghatározott értékű árúbeszerzésre vonatkozó szerződésekkel összefüggő adatokat az Eitv. Melléklete III. 4. Összeállította a GYEMSZI szakértői munkacsoportja 154

159 Portál követelmények pontjában meghatározott módon és tartalommal építési beruhárzásra vonatkozó szerződésekkel összefüggő adatokat az Eitv. Melléklete III. 4. pontjában meghatározott módon és tartalommal szolgáltatás megrendelésre vonatkozó szerződésekkel összefüggő adatokat az Eitv. Melléklete III. 4. pontjában meghatározott módon és tartalommal vagyonértékesítésre vonatkozó szerződésekkel összefüggő adatokat az Eitv. Melléklete III. 4. pontjában meghatározott módon és tartalommal vagyonhasznosításra vonatkozó szerződésekkel összefüggő adatokat az Eitv. Melléklete III. 4. pontjában meghatározott módon és tartalommal vagyon vagy vagyoni értékű jog átadására vonatkozó szerződésekkel összefüggő adatokat az Eitv. Melléklete III. 4. pontjában meghatározott módon és tartalommal A koncesszióról szóló törvényben meghatározott nyilvános adatokat az Eitv.Melléklete III. 5. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szerv által nem alapfeladatai ellátására fordított, 5 millió forintot meghaladó kifizetésekkel összefüggő adatokat az Eitv. Melléklete III. 6. pontjában meghatározott módon és tartalommal Várólistával kapcsolatos adatok A törvényi előírások alapján megjelenítendő és ellenőrizendő tartalom. Megjelenítették-e az egészségügyi ellátásra várakozó betegek várólistára kerülési sorrendjének kialakítására vonatkozó szempontokat a várólistára kerülő beteg kiválasztásának szakmai szempontjait egészségügyi adatait személyazonosító adatait kiválasztásukat indokoló körülményeket Javasolt ellenőrzési terv A várólistán szereplő adatok közül a honlapon közzétételre kerültek-e a 46/2006. (XII. 27.) EüM rend. 1. (1) bek. szerinti adatok A közzétételre statikus html oldalon került sor (1. (2) bek.) A közzétételre várólista-kezelő számítógépes programmal került sor (1. (2) bek.) A közzétételre intézményi integrált informatikai rendszer várólista-kezelő modulja révén került sor (1. (2) bek.) A várólistán szereplő adatok közül a honlapon közzétételre kerültek-e a beteg személyazonosító adatai (rend. 1. (1) bek.) Összeállította a GYEMSZI szakértői munkacsoportja 155

160 Portál követelmények Közbeszerzési eljárással kapcsolatos adatok A törvényi előírások alapján megjelenítendő és ellenőrizendő tartalom. Megjelenítették-e a költségvetési év elején, legkésőbb április 15-ig az éves összesített közbeszerzési tervet ha módosították a közbeszerzési tervet, annak módosításait 5 munkanapon belül szerepeltették-e a közbeszerzéi tervben a terv elkészítése előtt - ha volt - indított közbeszerzési eljárás(oka)t Megjelenítették-e közbeszerzési eljárásonként csoportosítva 5 munkanapon belül a közbeszerzési eljárást megindító hirdetményt az eljárás eredményéről vagy eredménytelenségéről szóló tájékoztatót tartalmazó hirdetményt a szerződés megkötéséről szóló tájékoztatót tartalmazó hirdetményt megkötött szerződéseket a szerződés módosításáról szóló tájékoztatót tartalmazó hirdetményt a szerződés teljesítéséről szóló tájékoztatót tartalmazó hirdetményt amennyiben az ajánlatkérő készített az előzetes összesített tájékoztatót tartalmazó hirdetményt az időszakos összesített tájékoztatót tartalmazó hirdetményt egyéb hirdetményeket az ellenszolgáltatás teljesítésével kapcsolatos adatokat a közbeszerzési eljárás kapcsán indult jogorvoslati eljárás vonatkozásában a kérelem törvényben meghatározott adatait a Közbeszerzési Döntőbíróság érdemi határozatát a Közbeszerzési Döntőbíróság a közbeszerzési ügy befejezését eredményező határozatát a Közbeszerzési Döntőbírósága szerződés megkötését engedélyező végzését a bíróság határozatát az éves statisztikai összegzést A közbeszerzési eljárás eredményeként megkötött szerződés teljesítését követően, vagy teljesítésének elmaradása esetén - a szerződés teljesítéséről szóló tájékoztató mellett a teljesítés megtörténtét a teljesítéssel kapcsolatban esetlegesen felmerült problémákat a teljesítés elmaradásának okát Javasolt ellenőrzési terv Megjelenítették-e a költségvetési év elején, legkésőbb április 15-ig az éves összesített közbeszerzési tervet (Kbt. 5. (1) - (2) bek.) ha módosították a közbeszerzési tervet, annak módosításait (5. (2) bek.) 5 munkanapon belül szerepeltették-e a közbeszerzési tervben a terv elkészítése előtt - ha volt - indított közbeszerzési eljárás(oka)t (5. (3) bek.) Megjelenítették-e közbeszerzési eljárásonként csoportosítva 5 munkanapon belül a közbeszerzési eljárást megindító hirdetményt (17/C. (1) bek.a) pont) az eljárás eredményéről vagy eredménytelenségéről szóló tájékoztatót tartalmazó hirdetményt (17/C. (1) bek. b) pont) 99. (4) bek. Szerinti szerződéseket 17/C. (1) bek. D) pont) Összeállította a GYEMSZI szakértői munkacsoportja 156

161 Portál követelmények megkötött szerződéseket 17/C. (1) bek. d) pont) a szerződés módosításáról szóló tájékoztatót tartalmazó hirdetményt (17/C. (1) bek. e) pont) a szerződés teljesítéséről szóló tájékoztatót tartalmazó hirdetményt (17/C. (1) bek. e) pont) amennyiben az ajánlatkérő készített az előzetes összesített tájékoztatót tartalmazó hirdetményt (17/C. (1) bek. f) pont) 17/C. (2) bek. Szerinti tájékoztatást egyéb hirdetményeket (17/C. (1) bek. g) pont) adott esetben az ellenszolgáltatás teljesítésével kapcsolatos adatokat (17/C. (1) bek. h) pont) a közbeszerzési eljárás kapcsán indult jogorvoslati eljárás vonatkozásában a kérelem törvényben meghatározott adatait (17/C. (1) bek. ia) pont) a Közbeszerzési Döntőbizottság érdemi határozatát (17/C. (1) bek. ib) pont) a Közbeszerzési Döntőbíróság a közbeszerzési ügy befejezését eredményező határozatát (17/C. (1) bek. ib) pont) a Közbeszerzési Döntőbizottság szerződés megkötését engedélyező végzését (17/C. (1) bek. ib) pont) a bíróság határozatát (17/C. (1) bek. ic) pont) az éves statisztikai összegzést 17/C. (1) bek. j) pont) Összeállította a GYEMSZI szakértői munkacsoportja 157

162 Telemedicina 8.4 A telemedicina alkalmazásának helyzete Magyarországon, a telemedicina rendszerkövetelményei Bár a technológiai fejlesztések jópár éve lehetővé tennék a betegek diagnosztikai és terápiás ellátását távol az egészségügyi ellátás hagyományos helyszínétől (kórház, háziorvosi rendelő, diagnosztikai központ, stb.), az alkalmazható személyi szenzorok (vérnyomásmérő, vércukormérő, stb.) sokfélesége és a vonatkozó szabványok hiányossága, valamint az egészségügyi ellátás konzervatív felfogású gyakorlata mindezidáig nem tette lehetővé a telemedicina rendszerszerű alkalmazását. Mit tekintünk telemedicina alkalmazásnak? A külföldi szakirodalom a következő kategóriákat sorolja (e tárgyban, illetve e tárgy körül): Social alarm otthoni riasztó szolgáltatás (első generációs telecare) Telecare szociális alapon biztosított otthoni riasztó rendszerek, és ráépülő szociális szolgáltatások, második generációs telecare Telemedicina szolgáltatás telemonitoring, telekonzultáció, telediagnosztika, telerehabilitáció, stb. ami segíti a betegeket a saját egészségük menedzselésében a megszokott környezetükben, másrészt az ellátási FOLYAMAT részeként de távoli pontokon szolgálja a betegellátást Smart-Home intelligens otthon, amely környezeti vezérlési- és automatizálási szolgáltatásokkal biztosítja az emberek életvezetését az otthonukban Az első kategória az egyszerű nyomógombos riasztó rendszerek kategóriája. Sok követelményt a működőképességen kívül megfogalmazni nem lehet. A Telecare már bonyolultabb rendszer, de még nem egészségügyi indíttatású, ezért nem tárgya a jelen dolgozatnak. A Telemedicina szolgáltatások azok, amelyek elterjesztése a jövő feladatainak egyike. A Smart-Home ennek a teljes társadalomra (betegekre-egészségesekre) kiterjedő csúcs alkalmazása. Ez még igen távol van a rendszerszerű megvalósítástól. Bevezetettségét tekintve, nemcsak Magyarországon várat magára a telemedicina térnyerése, nálunk fejlettebb országokban is csak szigetszerű megoldások (néha nagy szigetek is léteznek) találhatóak. Mindenhol így Magyarországon is a finanszírozási modell bonyolultsága, a sok szereplő közötti megosztása jelenti az egyik legnagyobb problémát. Hasonlóan nagy gond a rendszer biztonságossága mind adatvédelmi szempontból, mind működési szempontból is. Harmadik akadály a robbanásszerű elterjedés útjában a technológiai komponensek sokfélesége, működési rendszerük egyedisége a szabványosság hiánya derekán kormányzati szimpátia mellett 187 Magyarországon is elindult egy mozgalom a telemedicina alkalmazásba vételének kutatására. Ez az evita kezdeményezés, amely tömöríteni próbálta azokat a kutatóhelyeket, ipari fejlesztőket, megoldásszállítókat, valamint kormányzati tényezőket, amelyek koordinációja lehetőséget teremtett volna a hazai alkalmazásba vételre. Szokásos magyar tempó mellett nehezen alakult ki a közös gondolkozás arról, hogy mit is kellene tenni, utána az akkori kutatás-fejlesztés fellegvára a Nemzeti Kutatási és Technológiai Hivatal (NKTH) pályázatán elnyert forrás felhasználásával elindult a téma formalizációja, a kutatás-fejlesztési terv és a hozzá kapcsolt kutatás-fejlesztési 187 Nem igen lehetett támogatásnak nevezni azt a lendülettelen hozzáállást, amelyet a kormányzat különösen az egészségügyi adminisztráció a témával kapcsolatban tanúsított. Összeállította a GYEMSZI szakértői munkacsoportja 158

163 Telemedicina munkaterv elkészítése. A tevékenységek ekörül a mai napig sem fejeződtek be, amely mutatja mind a megváltozott kormányzat, mind a kutatás-fejlesztésben más szempontból érintettek motiválatlanságát. A kormányzat fejlesztésért felelős minisztériuma szintén felismerve a téma fontosságát szándékot mutatott a közelmúltban a telemedicina finanszírozásának megoldására, a szándék hamar n. prioritássá vált a szükséges források híján. Az ipari szereplők és egészségügyi szolgáltatók rendre összefognak kisebb-nagyobb projektek végig vitelére, azonban a kezdeti lelkesedés hamar semmivé foszlik, ha a ki fizeti a révészt kérdése felvetődik, vagy milyen fenntartási környezet lehet alkalmas a telemedicinális szolgáltatások biztonságos ellátására. A mai napon sok szándéknyilatkozat és együttműködési megállapodás hever a fiókokban minden további tartalom nélkül. Kicsit más a helyzet a nemzetközi projektekben való magyar részvétellel, amely bíztató számosságot és eredményt tud felmutatni! Ezeknek az eredményeknek a hazai alkalmazása mégsem megoldott. A kérdés tehát bonyolult, a megoldáshoz még sok akadályt kell leküzdeni. A nemzetközi tapasztalatok azt mutatják, hogy a működőképes modell csak szűk körben bevezetett pilotprojekt volt képes kimunkálni azokat a felelősség szinteket, költség elemeket, amelyek segítségével az adott alkalmazás működő és fenntartható modellje kialakult. Nem lenne ártalmas néhány sikeres minta-alkalmazást tanulmányozni, mielőtt a hazai ezirányú kutatások elindulnak. Az egészségügyi információs rendszerek/projektek követelményeit feldolgozó dokumentum nem hagyhatja figyelmen kívül a telemedicina alkalmazásokat, lévén súlyponti informatikaiinformációs megoldások tárháza. Mégis azt kell mondanunk a jelen helyzetben, hogy korai általánosságban és specifikus jelleggel követelményeket megfogalmazni, hiszen amíg a standardizáció, a finanszírozás és az orvosi alkalmazásba vétel hármas feladata megoldatlan, addig nincs miről beszélni. Ettől függetlenül meg kell állapítani, hogy az adatkezelés/adatfeldolgozás jogszabályi környezetének telemedicina-komform kialakítása azelőtt fontos feladat, mielőtt a fenti hármas akadály megoldódik. Ez a terület lehet a negyedik problémás terület olyan gyakorlat jogszabályi környezetét kell, hogy kimunkálja, amely után már nem kérdés az adatok gyűjtésének, elhelyezésének, feldolgozásának helye és végrehajtója Szabványosítás. A szabványosítás egyik szerepe az európai gyakorlathoz igazodó szabványos (CENT és MSZ szerinti) kommunikációs struktúra kialakítása és a szemantikus interoperabilitás megvalósítása ezen szakterületeken. A szabványosítási törekvéseket jogi eszközökkel is támogatni szükséges. A kommunikáció rétegeinek, a csatlakozó eszközök, szolgáltatások párbeszédének már korábban más alkalmazások gyakorlatához hasonlóan egységes, lehetőleg nemzetközi standardjainak (pl: DICOM 3) rögzítése és alkalmazási követelménye az első feladat Finanszírozás. A telemedicina alkalmazások tipikusan olyan szolgáltatási modellt alkotnak, amelyben egyaránt megtalálhatóak a közfinanszírozandó és a piaci értékesítésre számot tartó elemek. Nem gondolhatjuk, hogy a beteg kényelmét szolgáló, nem feltétlenül a szükséges ellátáson belül lévő, szolgáltatások közfinanszírozottak lehetnek. Meggyőződésünk viszont az, hogy a közfinanszírozási rendszerbe való befogadás nélkül a telemedicina nem tud tömegesen elterjedni, legalábbis a hazai piac méretét figyelembe véve nem lehet rentábilis a Összeállította a GYEMSZI szakértői munkacsoportja 159

164 Telemedicina működtetése. Tehát a finanszírozási modellt ennek figyelembevételével vegyes modell építésével kell kialakítani. A finanszírozás pontos meghatározásához mi sem úszhatjuk meg azokat a pilot-projekteket, amelyek során a szolgáltatás felelősségi- és költség elemei kialakulnak Orvosi gyakorlatba vétel. A telemedicina olyan ellátási mód, amelynél a beteg-orvos fizikai találkozása elmarad. Hiányzik tehát a rendszerből az a hagyományos értelemben vett bizalom, amely ezt a találkozást körüllengi. A bizalom kétirányú: (i) a beteg bizalma a vele szemben álló megfelelő (feltételezett) szaktudású orvosban, másrészt (ii) az orvos bizalma azokban az eszközökben és eljárásokban, amelyeket alkalmaz ebben a találkozásban (megvizsgál, diagnosztizásl, terápiát alkalmaz, stb.) a legjobb szaktudása szerint. Most ezek hiányoznak, de van egy elektronikus csatorna, amelyen információ áramlik valahonnan (az orvosi aspektus) valahova (a beteg aspektusa). Mind a valahonnan, mind pedig a valahova megfoghatatlan, és akkor nem beszéltünk az információról, amely szintén emberi beavatkozás (hatás) nélkül keletkezik, ami szintén bizalmatlanságot szülhet a betegben és az orvosban egyaránt. Egyértelmű definíció szükséges arra, hogy egyes telemedicinális alkalmazások felügyeletét és leletezését milyen informatikai rendszer és technikai infrastruktúra meglétéhez és milyen orvos szakmai végzettséghez kötjük. Nézzük ezt egy gyakorlati példán: A beteg karjára egy egyszerű vérnyomásmérő van feltéve. Eddig ez hasonló azokkal az eszközökkel, amelyeket 24 órás folyamatos vérnyomás monitorozásra ma is kiadnak a betegnek. Tételezzük fel, hogy a vérnyomásmérőnk hitelesített, ugyanúgy, ahogy a kihelyezett monitoré. A kettő között azonban nagy különbség van: a telemedicinális vérnyomásmérő nem 24 órás megfigyelésre szolgál, hanem hosszabbra. Ebből következik, hogy a beteg néha tisztálkodás okán leveszi azt, majd visszateszi. A 24 órás kihelyezett vérnyomásmérőt a kórházban, szakrendelőben az asszisztens szakszerűen felhelyezi, majd 24 óra múlva akár a beteg is leveszi. A mért értékek már a berendezés memóriájában vannak. HA az elemek is jók voltak, az akció sikeresen zárult, az információ a megfelelő betegről a megfelelő helyre került. De mi történik a telemedicinás vérnyomásmérővel? Jókor került le a betegről, jól került-e vissza, egyáltalán arra a betegre került vissza, vagy valaki játszik vele? Tekintettel arra, hogy az egészségügy szereplői nincsenek jelen, a kérdés megválaszolatlan. A következő probléma a kommunikáció. A távadatátvitel megfelelő volt? Volt-e kapcsolat. Az az érték jutott be a központba, amit az eszköz mért? Ha kiugróan eltérő értéket észlelnek a betegnél, mitől van. Nincs ott a beteg, hogy ellenőrizzük. Erre egy külön a helyszínre kijáró személy kell. Az orvosi protokollok a hagyományos eljárásokat ismerik, azokra vonatkoznak. Mi a teendő egy telemedicinás alkalmazásnál? Hova helyezzük ezt a megszokott protokollok esetében. Nyilvánvaló, hogy a telemedicina meg is változtatja a protokollokat, hiszen éppen az a szerepe, hogy a beteget ne kelljen feleslegesen mozgatni. De hol van az a protokoll, amely ezt figyelembe veszi? Megannyi kérdés, aminek megválaszolatlansága természetes akadállyá merevül, és alapvető bizalmatlanságot kelt orvosban-betegben egyaránt. A bizalmi kérdések megnyugtató megválaszolásához a telemedicina rendszerek számára kidolgozandó speciális minőségbiztosítási rendszer szükséges. Egy kidolgozott, az orvosi gyakorlat számára klinikai teszteken kipróbált telemedicina rendszer tömeges méretben történő előállítása olyan minőségbiztosítási hátteret kell, hogy feltételezzen, amely biztosítja a Összeállította a GYEMSZI szakértői munkacsoportja 160

165 Telemedicina működési, biztonsági és felelősségi kérdések teljes körű megoldását. Ezekkel felvértezve, kétség sem férhet ahhoz, hogy a rendszer megbízható Jogszabályi környezet. A telemedicina rendszerben milyen eljárások garantálják a betegadatok védelmét? Lehetséges-e a betegadatokat feldolgozni egy telekommunikációs szolgáltatónak, aki a kapcsolatot üzemelteti, és a betegadatokat temporáris állományokba gyűjti? Lehet-e a beteg adata a beteg vagy az egészségügyi szolgáltató hatókörén kívül? A hozzáférésnek milyen erősségű azonosítási rendszer felel meg? Ezekre a kérdésekre még ma nincs válasz. Ennek ellenére a telemedicina alkalmazások az ipari lobby feszítésére terjednek. Ezért alapvető informatikai követelmények megfogalmazhatóak: X X X X X X X X X X X X X A telemedicina rendszer valós ellátási igényt elégítsen ki A rendszer az orvos számára adekvát információkat szolgáltasson A rendszer a betegadatokat a hatályos jogszabályoknak megfelelően kezelje Amennyiben a rendszer üzemeltetésében az ellátásban érintett egészségügyi intézményen kívüli szervezet is részt vesz, csak a beteg felhatalmazása mellett kezelheti a beteg adatait A telemedicina rendszer csak orvosi felügyelet mellett működtethető, vagy úgy, hogy a betegadatokat orvosi háttér értelmezi és tesz beavatkozásokat A telemedicina rendszerben alkalmazott diagnosztikai készülékek érvényes minősítéssel kell rendelkezzenek A betegadatokat csak védett csatornán lehet továbbítani Azt a telemedicina rendszert, amely a beteggel szoros kapcsolatban működik (szenzorok, jeltovábbítók, stb), csak a beteg hozzájárulásával lehet alkalmazni A teleradiológiai és telepatológiai rendszerekben dolgozó leletező szakorvos számára a beteg személyes adata nem lehet hozzáférhető, csak elkódoltan lehet az esethez tartozó objektumot (képet, stb.) azonosítani A beteg környezetében alkalmazott telemedicina rendszer érvényes érintésvédelmi tanúsítással kell rendelkezzen A telemedicina rendszer, annak személyes szenzorai a beteget sértő, megalázó vagy emberhez méltatlan helyzetbe nem hozhatják A telemedicina rendszer által gyűjtött esetadatok csak beteg beleegyezése mellett, személyes adatoktól megtisztítottan lehet más pl. statisztikai célra felhasználni A telemedicina rendszer működtetésének a betegre vonatkozó részleteiről a beteget pontosan ki kell oktatni, számára írásos dokumentumot kell biztosítani erről. Összeállította a GYEMSZI szakértői munkacsoportja 161

166 NFM IT követelményrendszer integrálása 8.5 IT konszolidációs munkacsoport + Nemzeti Fejlesztési Minisztérium (NFM) által gondozott IT követelmény-rendszer integrálása, intézményi üzemeltetési-szabályozási konzekvenciák meghatározása Előzmények, összefoglaló A Nemzeti Együttműködés Program, a 2010 végén megjelentetett Digitális Megújulás Cselekvési terv, a 2011 tavaszán publikált Széll Kálmán terv és a 2011 júniusában ismertetett Magyary-program is egységesen kulcsfontosságú feladatnak írja elő a közigazgatás hatékonyságának és versenyképességének javítását. Ez jelenti egyfelől a közigazgatási működési költségek csökkentését, másfelől a bürokratikus eljárások és folyamatok felszámolását. A cél elérése érdekében a kormányzati informatikai stratégia szervezeti, folyamati és technológiai konszolidációt fogalmaz meg. A kormányzati egyeztetésre kerülő NFM előterjesztés bemutatja a kormányzati informatika kiemelt prioritásainak kontextusát a szolgáltatások és folyamatok konszolidációjának fényében. A szolgáltatások konszolidációjára tett intézkedési javaslatok mellett az anyag bemutatja ezek közvetlen, illetve hosszú távú hatásait is. Az egyes intézkedések bemutatásánál különös hangsúlyt fektettek a forrásigény, illetve a realizált megtakarítás bemutatására. Az intézkedések végrehajtásával a közigazgatás nagyobb hitelességre tehet szert a saját felhasználói, valamint az állampolgárok szemében és eredményesebben növelheti működésének gyakorlati értékét. A bevezetésre kerülő konszolidált működéssel az egész kormányzati informatika hatékonyabban működhet, ezzel könnyebben biztosíthatja az informatikai szolgáltatások jelentette előnyöket az igazgatás és az állampolgárok számára. A Kormány által elfogadott 1277/2010. (XII.9.) kormányhatározat a benne megfogalmazott feladatokkal a kormányzati informatikai konszolidáció mentén történő átalakulást célozza meg. A kormányzati informatika jelenlegi állapotának feltárásával és elemzésével számos olyan pontra lehet rámutatni - megerősítve a stratégia helyzetelemzésében leírtakat - ahol az állam működése nem racionális, többnyire pazarló. A szervezetek korábban a magasabb szintű rendező- és keretelveket figyelmen kívül hagyva, saját fejlesztési irányokat követtek. Ez szakmailag nem indokolható mértékben eltérő architektúrákat, fejlesztői és működési környezeteket, interfészek használatát, decentralizált kormányzati informatikát, egyben szigetszerű hálózatot és alkalmazásfejlesztést eredményezett. A szervezetek a rendszerek üzemeltetését több esetben külső üzemeltetésbe adták ki, hol állami, hol pedig magánkézben lévő piaci cégek részére. A kormányzati informatika működését ésszerűbben és költséghatékonyabban a jelen határozatban megfogalmazott feladatok végrehajtásával lehet kialakítani. A következő három év kiemelt prioritása a kormányzati infokommunikáció terén a hatékonyság javítása, a vállalkozások és lakosság számára gyors, egyszerű és költséghatékony elektronikus ügyintézés feltételeinek megteremtése, a bürokrácia csökkentése lesznek. Ez utóbbi a vállalkozások hatékony működésének egyik alapja, hiszen ezzel egyszerűsödik az adminisztráció és javul a költséghatékonyság. A 1277/2010. (XII.9.) kormányhatározatban megadott feladatok végrehajtásával újabb, a kormányzati informatika konszolidációjára vonatkozó részletes feladatkiadást tartalmazó kormányhatározat elfogadására, illetve a határozatban megfogalmazott feladatok végrehajtására van szükség. A közigazgatásban használt alkalmazások a közigazgatás Összeállította a GYEMSZI szakértői munkacsoportja 162

167 NFM IT követelményrendszer integrálása folyamataira épülnek. A folyamatoktól független, informatikai és infrastrukturális konszolidációt a teljes közigazgatás szintjén lehet maradéktalanul teljesíteni, ezen felül az alkalmazások szintjén is felmerülnek konszolidációs lehetőségek. Az intézkedési terv a központilag végrehajtható racionalizálási feladatokat tartalmazza (lásd később). A felmérés folyamata A végrehajtandó feladatok kijelölését átfogó elemzés előzte meg, amelyet a 1277/2010. (XII. 9.) kormányhatározat alapján végzett el 5 tárcaközi munkacsoport a Nemzeti Fejlesztési Minisztérium koordinálásában. Az elemzés és értékelés a kormányhatározat alapján kiterjedt valamennyi minisztériumra, valamint a minisztériumok által felügyelt valamennyi szervre, a gazdasági társaságok kivételével. Ez a központi közigazgatási intézményekkel együtt összesen 176 szervezet infokommunikációs tevékenységének felmérését jelentette. Az elemzés négy fő szempont mentén készült: az informatikai infrastruktúra felkészültségét; a humán-erőforrások képességeit, releváns tapasztalatát; az informatikai szabályozás minőségét; valamint az informatika szerződéses és pénzügyi jellemzőit vizsgálta. Ezen belül a 2008-tól 2010-ig terjedő periódusra koncentrált. A felmérés alapjául szolgáló kérdőívet a Nemzeti Fejlesztési Minisztérium állította össze 2010 decemberében. A kérdőív az informatikai infrastruktúra és szolgáltatások igénybe vételének alábbi kérdéseire tért ki: a központi és végfelhasználói hardver elemek, a központi és a munkaállomásokon üzemelő szoftver elemek számítógépes hálózat (lan-wan), a teljes informatikai struktúra, illetve az egyes adatbázisok közötti adatkapcsolat informatikai szervezeti felépítés, a szervezeti működési szabályzatok, az informatikai létszám bemutatása szerződéses kötelezettségvállalások, illetve a és 2010-es évekre szóló informatikai kiadások a szervezetek informatikai fejlesztési tervei A feldolgozást az egyes minisztériumok, így a NEFMI-GYEMSZI által is delegált szakértők végezték. Az értékelés és feldolgozás alapján lehetővé vált a fejlesztési javaslatok és a hatékonyság-javító intézkedési terv összeállítása Az egészségügyi információs rendszerkövetelmények anyag megfelelése a kormányzati infokommunikációs konszolidációs intézkedési tervben leírtakhoz Az NFM infokommunikációs konszolidációs intézkedési terve a központi költségvetési szférára, vagyis a minisztériumok és háttérintézményeik infokommunikációs tevékenységeire vonatkozik, alsóbb szintű regionális, vagy megyei szintű, vagy más ellátórendszerben, így az egészségügyben működő állami fenntartású intézményekre nézve ajánlásokat tud adni (már amennyiben azok relevánsak). A GYEMSZI és az NFM Kormányzati Informatikai Helyettes Államtitkárság közös álláspontja, hogy a jelen, egészségügyi információs rendszerek követelményei anyag kapcsán összevetésre, illetve beépítésre kerüljenek a kormányzati infokommunikációs konszolidációs intézkedési terv vonatkozó részei. A két alapos szakértői előkészítés után létrejött anyag egymáshoz felelését a következő táblázatban ismertetjük: Összeállította a GYEMSZI szakértői munkacsoportja 163

168 NFM IT követelményrendszer integrálása NFM infokommunikációs konszolidációs intézkedési terv GYEMSZI Egészségügyi információs rendszerek követelményei Témakör Feladat / Intézkedés Vonatkozó rész Végponti szolgáltatások kiterjesztése IT Intézkedési terv készítése a kormányzati végfelhasználói és központi infokommunikációs infrastruktúra biztosítását és üzemeltetését biztosító kedvezőbb ár-érték arányú technológiák alkalmazásáról Kormányzati végfelhasználói és központi infokommunikációs infrastruktúra konszolidált biztosítása és üzemeltetésének kiterjesztése a 168/2004. (V. 25.) Korm. rendelet 1. -ában meghatározott szervek számára A vonatkozó központi intézkedések annyiból relevánsak egészségügyi informatikai szempontból, hogy a 3. Központi kormányzati egészségügyi informatikai fejlesztések, a rendszerkövetelmények anyag illeszkedése részben leírt, GYEMSZI által megvalósítani kívánt core-saas központ látná el szolgáltatásokkal, alkalmazásokkal az alap-, járó- és fekvőbeteg intézményeket a 4. részben ismertetett követelmények betartása szerint (ez összhangban van azzal, hogy a központi közigazgatásban központosított infrastruktúra üzemeltetés lép életbe a jövőben). Így a központi kormányzati intézményi-informatikai szinthez hasonlóan az egészségügyi ellátórendszer egységeinél is megtakarítás érhető lenne el egyes, főleg a szoftver, IT szolgáltatási, de a felhőalapú technológiákra áttéréssel a hardver típusú infokommunikációs költségek vonatkozásában is. Licensz-, és supportgazdálkodás központosítása Informatikai fejlesztések konszolidációja A központi kormányzati szoftverlicenc-, és szoftver támogatási-követési szolgáltatásgazdálkodásért felelős végrehajtó szervezet kialakítása, amelytől a 168/2004. (V. 25.) Korm. rendelet 1. -ában meghatározott szervek veszik igénybe a szolgáltatásokat Az állam által meghatározott szoftverektől, szerzői jogi jogosultaktól való függés, és az ezzel kapcsolatos kockázatok mértékének csökkentéséért felelős szervezet létrehozása Lásd előző cella. Ezenkívül fontos, hogy a 4. részben mind a szofver beszerzés/fejlesztés, mind az üzemeltetés support - licenszgazdálkodás kapcsán meg vannak fogalmazva testreszabott követelmények az egészségügyi intézményekre nézve, összhangban a központi kormányzati informatikai elvárásokkal. Az egészségügyi információs rendszerkövetelmények kialakításának fontos célja, hogy az intézmények IT szállítói függését csökkentsük, illetve, hogy a beszállítóiktól egységes elvárások szerinti szolgáltatási szinteket és rendszerképességeket kapjanak. Ennek fényében lettek kialakítva az anyag 4. és 5. fejezetei (illetve azok tartalmai), így elérhető, hogy az egészségügyi informatikában megfelelő minőséget nyújtó és árazású szállítók működjenek közre magas színvonalú infokommunikációs termékekkel és szolgáltatásokkal. A felállítani javasolt, egészségügyi ágazati koordinációs szerepet betöltő GYEMSZI-n belüli minősítő rendszer és szervezet (lásd 6. fejezet) a központi kormányzatban hasonló célt szolgáló intézménnyel összhangban, annak Összeállította a GYEMSZI szakértői munkacsoportja 164

169 NFM IT követelményrendszer integrálása iránymutatásai alapján kellene, hogy működjön. Alkalmazások üzemeltetésének konszolidációja Informatikai alkalmazások konszolidációjának végrehajtása Kormányzati központi szerver-, és alkalmazás-elhelyezési (hosting) szolgáltatás kialakítása A 4. és 5. fejezetben leírt követelmények a specifikációik szerint meghatározzák illetve megszabják azon megoldások körét, amelyeket a jövőben használniuk kellene az egészségügyi intézményeknek, ezáltal az ágazaton belül is megvalósul (a rosszabb minőségű, szakmailag kifogásolható szállítók és azok rendszereinek kiszűrésével) egyfajta alkalmazáskonszolidáció. Ezt az is segíti, hogy várhatóan az egészségügyi (lásd rész: TIOP 2.3.1) core-saas központ egyes szolgáltatásai (lásd pl. e-recept, háziorvosi rendszer) is el fognak indulni. A szerverek és a hosting vonatkozásában az anyag 4.1 és 4.5 részei tartalmaznak követelményeket az egészségügyi intézményekre nézve. Ugyanakkor ismét a coresaas központban megvalósítani, szolgáltatni kívántakra hivatkozva azok igénybevételével az intézményi hardverjellegű költségek csökkenthetők. Előterjesztés készítése a felhő alapú alkalmazásfuttatási modellről és a szabványos, központi üzemeltetésű informatikai alkalmazásoknak különösen a közigazgatási szervek folyamataiban történő bevezetéséről A legfontosabb állami nyilvántartások számára kiemelt fizikai biztonságot nyújtó állami megoldás kialakítására vonatkozó intézkedési terv elkészítése Az anyag 4. fejezetében leírt követelmények vonatkoznak a felhőalapú rendszerekre is (illetve külön jelöljük, ha esetleg nem). A coresaas központ maga is felhőalapú szoftverszolgáltatásokat is fog szolgáltatni, ezáltal teljesül az ágazatban a központi kormányzati infokommunikációs elvárásokhoz való igazodás. Az egészségügyi intézmények biztonsági követelményeit (amelyek igazodnak az általános kormányzati informatikai elvárásokhoz, de nyílván a releváns körre vonatkoznak) elsősorban a IT biztonsági követelmények és a Informatikai biztonság menedzsment részek taglalják. Infokommunikác iós eszközök beszerzésének konszolidációja Igénybevett távközlési Úgy látjuk ez a központi kormányzati Új, modulárisan felépített intézkedés nem releváns az egészségügyi közbeszerzési portál létrehozása rendszerkövetelmények vonatkozásában. (közbeszerzési, használteszközkezelési, selejtezési és részben vannak infokommunikációs Egyedül az Beszállítói követelmények jótékonysági ill. szállítóknál közbeszerzési témájú elvárások. Központi elfekvő készletek felhasználását egészségügyi informatikai beszerzési portál lehetővé tevő modulokkal) elindításának tervéről nincs tudomásunk. A központi államigazgatási szervek összességét átfogó Az intézkedések nem igazán relevánsak, mivel az egészségügyi rendszerkövetelmények anyag Összeállította a GYEMSZI szakértői munkacsoportja 165

170 NFM IT követelményrendszer integrálása szolgáltatások konszolidációja Távközlési alaphálózat konszolidációja és kiterjesztése Közigazgatási humánerőforrás fejlesztése vezetékes és mobil telefonszolgáltatás igénybevételi lehetőségeinek feltérképezése A nemzeti informatikai alaphálózatok konszolidációja és kiterjesztése lehetőség szerint minél több kistérségi központig, településig A távközlési alaphálózatok központi államigazgatási szervek, más államigazgatási szervek, állami vállalatok és egyéb állami szervezetek körében kötelező használatát jogszabály-módosítások előterjesztése megalapozó Az informatikai szakember gárda megtartását és az állami informatikai pozíciók vonzerejét biztosító, a közigazgatásban informatikai munkakörben dolgozó állami alkalmazottakra vonatkozó életpálya modell kidolgozása 4. fejezete csak az intézményi informatikai (és nem telekommunikációs!) rendszerek megfelelő (biztonságos) használatához kapcsolódó távközlési jellegű elvárásokat (pl. internetes sávszélesség igény, backup szükséglet, hálózat) tartalmazza. Egységes egészségügyi távközlési hálózat kialakításáról, vagy annak konszolidációjáról nem rendelkezünk információkkal, de a fejlesztésre kerülő nemzeti egységes kormányzati informatikai gerinchálózat szolgáltatásait az intézmények várhatóan igénybe vehetik majd (legalábbis javasolt lenne). Az egészségügyi informatikai humán erőforrással (szakemberekkel), tehát nem a felhasználókkal, kapcsolatban az anyag 4. (lásd ; részek), illetve 5. (lásd 5.1.1; 5.1.2) fejezete állít fel infokommunikációs és menedzsment jellegű követelményeket. A rendszerkövetelmények anyagtól függetlenül, de a kormányzati szintű törekvésekkel összhangban megjegyezzük, hogy az egészségügyben is szükség van az informatikai szakemberállomány fejlesztésére, képzésére, életpálya modell kidolgozására, erre a kulcsprojektek (lásd 3. fejezet) leírásaiban nem látunk utalást. Javasoljuk a leginkább releváns TÁMOP (alapvetően képzési jellegű) projekt térjen ki erre is. Ágazati IT szakmai mátrixok és szakember-nyilvántartások felállítása is a kormányzati intézkedés része, értelemszerűen ez érinti az egészségügyet is. Országos videokonferenciarendszer kiépítése Nem releváns intézkedési javaslat, illetve az egészségügyi intézményeknél nem célszerű országos szintű videokonferencia-rendszerben gondolkodni (a 3. részben tárgyalt kiemelt kormányzati projektek nem is célozzák annak megvalósítását). Ugyanakkor az egészségügyi intézményi csoportmunka rendszerekkel kapcsolatban az anyag (lásd rész) tesz elvárásokat. Informatikai szabályozás informatikai szervezete és A közigazgatási informatika szabályozottságának javítása érdekében szabályrendszerek kidolgozása A pénzügyi elszámolási és szerződéses gyakorlat fejlesztése Az egészségügyi információs rendszerek anyag szempontjából leginkább releváns kormányzati infokommunikációs konszolidációs intézkedési javaslatok, ezért ezeket külön részben tárgyaljuk (lásd 8.5.3) Összeállította a GYEMSZI szakértői munkacsoportja 166

171 NFM IT követelményrendszer integrálása A költségvetési szervek informatikai szervezetének felépítésére vonatkozó ajánlás készítése Informatikai szabályozás és informatikai szervezete kormányzat / egészségügy A központi közigazgatás informatikai szabályozása és informatikai szervezetének feltételeinek rendbetétele kapcsán a következőket kívánja elérni a felelős szaktárca: A közigazgatási informatika szabályozottságának javítása érdekében szabályrendszerek kidolgozása A pénzügyi elszámolási és szerződéses gyakorlat fejlesztése A költségvetési szervek informatikai szervezetének felépítésére vonatkozó ajánlás készítése Ezen célok kormányzati szinten törtnő megvalósításának érdekében a következő intézkedéseket javasolják (az egyes javasolt beavatkozások mellett feltüntettük, hogy hogyan illeszkedik az egészségügyi információs rendszerkövetelmények anyag): NFM által javasolt, kormányzati szintű javasolt szabályozásiszervezeti jellegű intézkedések A. IT specifikus szabályozási javaslatok Egészségügyi információs rendszerkövetelmények anyag illeszkedése 1. Az informatikai szabályozási elvárások egyértelmű megfogalmazása Elemei: az informatikai szabályozási tudatosság növelése megfelelő információk (pl. mi a kormányzati stratégia), elemzések, tájékoztatók eljuttatása a felelősöknek 2. Egységes központi iránymutatások: Fontos, hogy az egységes informatikai szabályozás kialakításánál a következő elvek érvényesüljenek: a) Módszertan b) Szabályozási térkép c) Szójegyzék d) Központilag kialakított belső szabályozás e) Működtetés központi Maga a rendszerkövetelmények anyag elvárásokat fogalmaz meg (igaz nem jogszabályszerűen) az egészségügyi informatikai fejlesztések, rendszerek vonatkozásában úgy, hogy megfelelően informálja, egyértelműen felvilágosítja a célcsoportot, az ellátórendszerben működő intézmények informatikai vezetőit, szakembereit. A rendszerkövetelményekből következő jogszabályi átültetés (vagy legalábbis javaslat annak módjára) az EIT rendeletelemzés munkacsoport feladata. A rendszerkövetelmények anyag a felsorolt kormányzati szintű paraméterek közül gyakorlatilag valamennyihez illeszkedik, a következőképpen: a) az anyag sorvezető az ágazati informatikai fejlesztések, üzemeltetés és projektmenedzsment vonatkozásában b) egyfajta térkép is, hiszen gyakorlatilag az informatika teljes spektrumát felöleli c) tartalmaz szószedetet, megmagyarázza az alapvető dolgokat, egységesen kezeli a fogalmakat d) e) ágazati központi intézmény számára (GYEMSZI) készül f) megjelöli a központi és alsóbb szintű intézmények egymáshoz való viszonyát g) megkülönbözteti a kötelező és opcionális Összeállította a GYEMSZI szakértői munkacsoportja 167

172 NFM IT követelményrendszer integrálása szabályozása f) Szervezetek kapcsolata g) A kötelező és ajánlott szabályzók elválasztása h) Projektmenedzsment i) Tárcák együttműködése j) Audit k) Alkalmazásvédelem l) Allokáció (az elkészült szabályzásokat belső szabályozási hierarchiájában a megfelelő szintre kell elhelyeztetni). követelményeket h) külön projektmenedzsment kézikönyvet tartalmaz i) mind a NEFMI és alá tartozó szervezetek (GYEMSZI, OEP), mind az NFM részt vesznek kidolgozásában, validálásában, elfogadásában j) felvázolja az optimális minősítési rendszert és annak intézményét k) megfogalmaz biztonsági elvárásokat az ágazatban működő informatikai rendszerekre nézve l) a GYEMSZI felsővezetés számára készül, így annak jóváhagyásával alsóbb szinten is elfogadásra kell, hogy majd kerüljön m) nem terjeszkedik túl az intézmények jelenleg törvényileg szabályozott hatáskörén, nem ér el túlszabályozottságot n) a mellékletben külön fejezet foglalkozik a nemzetközi követelményekkel, gyakorlatokkal o) még az ágazati stratégia projektek elindulása előtt jelenik meg, azokhoz megfelelő alapot ad. m) Elégséges szabályzás elérése n) Benchmark projektek o) Időzítés 3. A helyi intézményi tudásszint növelése Elemei: lokális (intézményi) szintű tudásszint növelése szervezeti felelősök elérhetőségének biztosítása, azok folyamatos tájékoztatásának, képzésének érdekében 4. Átfogó felügyeleti rendszer kiépítése Központi menedzsment kialakítása, amely a kormányzat részéről szakmai felügyeletet gyakorol a szervek szabályzórendszere és annak végrehajtása felett, méghozzá a szerv által létrehozott és működtetett felügyeleti szerven keresztül 5. Rendszeres kapcsolattartás a jogalkotó és a jogalkalmazók között Maga az anyag tájékoztatást, iránymutatást ad az egészségügyi ellátórendszer informatikai stakeholder-ei számára, vagyis azok tudásszintjét növeli. A másik elemmel kapcsolatban annyit jegyeznénk meg, hogy a GYEMSZInek (a felsővezetésnek) kell majd eldöntenie, hogy a rendszerkövetelményeket milyen formában fogja tálalni az ágazati érintetteknek. A kialakítani javasolt, GYEMSZI-n belüli minősítő szervezet (vagy annak egy kibővített egysége) célszerű volna (és tudomásunk szerint ez is a terv), hogy az egészségügyi ágazaton belül informatikai felügyeleti szerepet is ellásson az intézmények felé, így az összhang biztosítva lenne a kormányzati szinttel. Megjegyezzük, hogy az Egészségügyi Informatikai Tanács egyébként már most is (igaz magasabb szinten) betölt ilyen jellegű funkciót. Közvetlenül az anyag kapcsán nem releváns intézkedés. A NEFMI-nek, illetve a GYEMSZI-nek nyilván részt kell majd vennie a tárcaközi bizottságban. Összeállította a GYEMSZI szakértői munkacsoportja 168

173 NFM IT követelményrendszer integrálása szükséges a kormányzati direktívák folyamatos implementálása állandó jellegű tárcaközi bizottság kialakítása B. Az informatikai pénzügyi szabályozás A költségvetési szférában az informatikai üzemeltetést és fejlesztést érintő pénzügyi felelősség megalapozására szükségesnek látjuk az alábbi feladatok mielőbbi végrehajtását: 1. Megrendelői-szolgáltatói viszony kialakítása A központi költségvetés intézmények informatikai tevékenység finanszírozás kérdés nem a dokumentum kompetenciája. 2. Szolgáltatási szintek definiálása Egészségügyi intézményekre vonatkozó informatikai szolgáltatási kötelezettség színvonalával kapcsolatos SLA követelményeket tartalmaz az anyag 4.5 Üzemeltetési fejezete. (elsősorban a Szolgáltatás szint menedzsment rész). 3. EU források bevonhatósága (ne az üzemeltetésre) Az nem a rendszerkövetelmények dokumentum kompetenciája, hogy javaslatot tegyen arra, hogy az egyes intézmények miből finanszírozzák informatikai költségeiket (azzal maximálisan egyetértünk, hogy üzemeltetési kiadásokat nem lehet, és nem szabad hagyni EU-s forrásokból fedezni). 4. Szerződéstípusok előírása Az anyag külön részben (5.3.3 A fejlesztéssel kapcsolatos szerződésháló kialakításának követelményei) foglalkozik az egészségügyi intézménybeszállító informatikai szerződések javasolt tartalmával. 5. Beszállító független megoldások A 4. részben maximálisan arra törekedtünk, hogy az egyes követelmények ne legyenek csak egyes szállítók által teljesíthető elvárások, így garantáltuk a megoldás és informatikai beszállító függetlenséget, annak szem előtt tartásával, hogy az egészségügyben beszerzésre kerülő informatikai eszközöknél, rendszereknél jól bevált termékek, szolgáltatások, technológiák, és az azokat kínáló magas szakmai színvonalú informatikai cégek kerülhessenek előtérbe. 6. Alkalmassági követelmények A beszállítók alkalmassága kapcsán az anyagban külön követelményrészt jelenítettünk meg (lásd 5.2 A beszállító felkészültségének és ajánlatának követelményei). Összeállította a GYEMSZI szakértői munkacsoportja 169

174 NFM IT követelményrendszer integrálása C. Szervezeti keretek 1. Irányítás: Elemei: központi kormányzati felelős minisztérium (NFM) kijelölése jogosítványokkal ágazati szintű felelős szervezetek kijelölése jogosítványokkal informatikai vezetők premizálása 2. Intézményi informatikai szervezetek Elemei: informatikai szervezet helyének kijelölése a szervezetekben informatikai átvilágítás szervezeti átalakítás előtt 3. Informatikát érintő szabályozás megismertetése Elemei: Informatikával jogszabályi összegyűjtése kapcsolatos kötelezettségek Hírlevél jelleggel vagy portálon történő tájékoztatás Az anyag szempontjából annyiban releváns az intézkedésjavaslat, hogy a központi informatikai felelős minisztérium iránymutatásai alapján (lásd az NFM delegált részvételét a munkacsoportban és a jelen fejezetet) az egészségügyi ágazatban az informatikai feladatok koordinálására kijelölt EIT és GYEMSZI megrendelésére, azok elvárásainak beépítésével készül. Az informatikai vezetők premizálásával kapcsolatban jó ötletnek tartjuk ösztönző megoldások bevezetését egészségügyi intézményi szinten. A dokumentumban az Intézményi követelmények a fejlesztés előkészítésére részben van rá utalás, hogy az egészségügyben (értelemszerűen a fekvő- és járóbeteg ellátóknál) milyen elvárások vannak az intézményen belül az informatikai szervezet helyével, a menedzsmenttel kapcsolatban. Maga a rendszerkövetelmények anyag elvárásokat fogalmaz meg (igaz nem jogszabályszerűen) az egészségügyi informatikai fejlesztések, rendszerek vonatkozásában úgy, hogy megfelelően informálja, egyértelműen felvilágosítja a célcsoportot, az ellátórendszerben működő intézmények informatikai vezetőit, szakembereit. A rendszerkövetelményekből következő jogszabályi átültetés (vagy legalábbis javaslat annak módjára) az EIT rendeletelemzés munkacsoport feladata. A másik elemmel kapcsolatban annyit jegyeznénk meg, hogy a GYEMSZInek (a felsővezetésnek) kell majd eldöntenie, hogy a rendszerkövetelményeket, illetve a hivatkozott jogszabály változtatásokat milyen formában fogja tálalni az ágazati érintetteknek Konklúzió Megállapítható, hogy az egészségügyi információs rendszerkövetelmények anyag tartalma gyakorlatilag teljes összhangban van a kormányzati szintű informatikai elvárásokkal, intézkedésjavaslatokkal úgy hogy figyelembe veszi az ágazat specifikumait és azt, hogy nem központi költségvetési intézmények érintettek elsősorban. Összeállította a GYEMSZI szakértői munkacsoportja 170

175 NFM IT követelményrendszer integrálása 9 A dokumentum szerzői A dokumentum szerzői, a GYEMSZI szakértői munkacsoportjának tagjai: Adányi Balázs Berky Tamás Fogarassy Károly Gazdagh Pál Kövesdi Zoltán Nagy István Dr. Valovics István A dokumentumot véleményezték, az egyeztető üléseken részt vettek: Dr. Fónyad Gábor Bizzer László Csuzi Szilvia Frányóné Németh Angéla Pári Mónika Somogyi László Surguta András Dr. Surján György A szerzők fejezetenként: Fejezetcím Felelős szerző Társszerzők 1. Bevezető Fogarassy Károly 2. Szószedet A szerzők 3. Központi kormányzati egészségügyi informatikai fejlesztések, a rendszerkövetelmények anyag illeszkedése 4. Az informatikai rendszerek követelményei 5. A fejlesztési pályázat és a megvalósítási projekt követelményei, minősítése 6. A követelmények alapján folytatott minősítés módszertana, folyamata és Kövesdi Zoltán Nagy István Dr. Valovics István Fogarassy Károly Gazdagh Pál Adányi Balázs, Fogarassy Károly, Gazdagh Pál, Kövesdi Zoltán Nagy István Összeállította a GYEMSZI szakértői munkacsoportja 171

176 NFM IT követelményrendszer integrálása szervezete 7. Javasolt jogszabályi változtatások Nagy István 8. Mellékletek 8.1 Az egészségügyi információs rendszerek nemzetközi minősítési követelményei és gyakorlata 8.2 Egészségügyi gazdasági információs rendszerek és VIR rendszerek speciális adatkezeléssel kapcsolatos minősítése ajánlásai 8.3 Intézményi portálok közzététellel kapcsolatos tartalmi követelményei 8.4 A telemedicina alkalmazásának helyzete Magyarországon, a telemedicina rendszerkövetelményei 8.5 IT konszolidációs munkacsoport + Nemzeti Fejlesztési Minisztérium (NFM) által gondozott IT követelményrendszer integrálása, intézményi üzemeltetési-szabályozási konzekvenciák meghatározása Berky Tamás Nagy István Nagy István Fogarassy Károly Kövesdi Zoltán A dokumentum végső alakját összeállította, a fejezeteket egybeszerkesztette: Fogarassy Károly Összeállította a GYEMSZI szakértői munkacsoportja 172