Az ege szse gü gyi informá cio s rendszerek ko vetelme nyei

Átírás

1 Az ege szse gü gyi informá cio s rendszerek ko vetelme nyei (verzió: C1.0) Összeállította: a GYEMSZI szakértői munkacsoportja augusztus

2 Tartalomjegyzék TARTALOMJEGYZÉK BEVEZETŐ 1 Előszó 1 Szószedet 4 I. EGÉSZSÉGÜGYI INFORMATIKAI PÁLYÁZATOK ÉS PROJEKTEK 10 A Követelmények az egészségügyi informatikai pályázatokhoz és projektekhez 11 A.1 A fejlesztési pályázat és a megvalósítási projekt alapkövetelményei 11 A.1.1 Az intézmény felkészültségének követelményei 13 A A fejlesztés elhelyezése az intézmény működésében 13 A Intézményi követelmények a fejlesztés előkészítésére 15 A.1.2 A beszállító felkészültségének és ajánlatának követelményei 16 A Beszállítói követelmények 16 A Az ajánlott megoldás illeszkedése a kiíráshoz 17 A.1.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 18 A A fejlesztés előkészítésének tervezési feladatai és módszerei 18 A A Projekt Alapító Dokumentum követelményei 19 A A fejlesztéssel kapcsolatos szerződés(háló) kialakításának követelményei 20 A Szoftverszerződésekkel kapcsolatos elvárások 21 A A fejlesztés megvalósítása követésének követelményei 21 A A fejlesztés eredményének követelményei 22 A.2 A fejlesztési pályázat és a megvalósítási projekt specifikus követelményei 23 A.2.1 Az intézmény felkészültségének követelményei 23 A A fejlesztés elhelyezése az intézmény működésében 23 A Intézményi követelmények a fejlesztés előkészítésére 23 A.2.2 A beszállító felkészültségének és ajánlatának követelményei 24 A Beszállítói követelmények 24 A Az ajánlott megoldás illeszkedése a kiíráshoz 24 A.2.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 26 A A fejlesztés előkészítésének tervezési feladatai és módszerei 26 A A Projekt Alapító Dokumentum követelményei 26 A A fejlesztéssel kapcsolatos szerződés(háló) kialakításának követelményei 26 A Szoftverszerződésekkel kapcsolatos elvárások 26 A A fejlesztés megvalósítása követésének követelményei 28 A A fejlesztés eredményének követelményei 28 A.3 Alkalmazandó eljárások a jövőben 28 A.3.1 Az intézmény felkészültségének követelményei 28 A A fejlesztés elhelyezése az intézmény működésében 28 A Intézményi követelmények a fejlesztés előkészítésére 28 A.3.2 A beszállító felkészültségének és ajánlatának követelményei 28 A Beszállítói követelmények 28 A Az ajánlott megoldás illeszkedése a kiíráshoz 28 A.3.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 28 A A fejlesztés előkészítésének tervezési feladatai és módszerei 28 A A Projekt Alapító Dokumentum követelményei 29 A A fejlesztéssel kapcsolatos szerződés(háló) kialakításának követelményei 29 A Szoftverszerződésekkel kapcsolatos elvárások 29 A A fejlesztés megvalósítása követésének követelményei 29 i

3 Tartalomjegyzék A A fejlesztés eredményének követelményei 29 II. KÖVETELMÉNYEK AZ EGÉSZSÉGÜGYI SZAKELLÁTÁSI INFORMÁCIÓS RENDSZEREK FELÉPÍTÉSÉHEZ 30 B Egészségügyi szakellátási információs rendszerek implementációs követelményei 31 B.1 Az informatikai rendszerek alapkövetelményei 31 B.1.1 Az informatikai infrastruktúra architektúrális követelményei 31 B Bevezetés 31 B Jogi formában rögzítendő ajánlások az egészségügyi informatikai rendszerek védelme és biztonsága érdekében 31 B Általános architekturális követelmények 34 B Infrastruktúrális követelmények 36 B Mentési, archiválási, visszatöltési követelmények 37 B Biztonságos működéssel-működtetéssel kapcsolatos követelmények 39 B Működtetéssel kapcsolatos dokumentáció 45 B.1.2 Intézményközi rendszerszolgáltatások általános és specifikus követelményei 47 B A Kooperatív Tér 47 B A Kooperatív tér kialakításával kapcsolatos általános követelmények 51 B A Kooperatív téren belül megvalósuló alkalmazásokkal kapcsolatos követelmények 53 B.1.3 Üzenetkezelés 55 B A Kooperatív Tér üzenetkezelésével kapcsolatos általános követelmények 55 B.1.4 Intézményközi technológiai protokollok követelményei 55 B Interoperabilitás 55 B.1.5 A telemedicina alkalmazásának helyzete Magyarországon, a telemedicina rendszerkövetelményei 60 B Telekonzultáció, teledignosztika 61 B Telemedicina a beteg környezetében 62 B Betegállapotot (életfunkciót, egészségügyi paramétereket) mérő eszközök 65 B Szabványosítás. 67 B Adatátviteli hálózati technológiák 68 B Finanszírozás. 71 B.2 Az egészségügyi szakellátási szintek specifikus követelményei 72 B.2.1 A szakellátás specifikumai 72 B Tranzakció és eseménynaplózás a HIS rendszerekben 72 B Az egészségügyi dokumentumok adatvédelmével kapcsolatos adatvédelmi elvárások 73 B Az alkalmazásokkal kapcsolatos jogosultság kezelés 75 B ISO OID (Object IDentifier egyedi azonosító) rendszer használata 76 B Kódok, kódszótárak, nyilvántartások, szabályok 77 B Betegadminisztrációs rendszer 78 B Alapvető járó és fekvőbeteg ellátási funkciók 80 B Megrendelésekkel kapcsolatos általános elvárások 81 B Labor kommunikációval kapcsolatos alapvető elvárások 82 B Dokumentum kezelés (szerkesztés és nyomtatás) 84 B Statikus és dinamikus űrlapok 88 B Recept 89 B Erőforrás ütemezés 91 B Lekérdező modul 93 B.2.2 A betegfelvétel során elvárt minimális funkcionalitás 94 B Páciens adatkezeléssel kapcsolatos funkciók 94 B Előjegyzés, ellátás ütemezés 94 B Biztosítás, finanszírozás 94 B Dokumentumszerkesztés 94 B.2.3 A Járóbeteg szakellátás során elvárt minimális funkcionalitás 95 ii

4 Tartalomjegyzék B Páciens adatkezeléssel kapcsolatos alapvető funkciók 95 B Előjegyzés, ellátás ütemezés 95 B Biztosítás, finanszírozás 96 B Ambuláns dokumentumok kezelése (szerkesztés és nyomtatás) 96 B PACS illesztés 96 B.2.4 A fekvőbeteg szakellátás során elvárt minimális funkcionalitás 96 B Páciens adatkezeléssel kapcsolatos alapvető funkciók : 96 B Felvételtervezés, várólista kezelés 97 B Biztosítás, finanszírozás 97 B Fekvőbeteg dokumentumok kezelése (szerkesztés és nyomtatás) 98 B PACS illesztés 98 B.2.5 Az elektronikus kórlaptól és lázlaptól elvárt minimális funkcionalitás 98 B.2.6 Az ápolási dokumentációtól elvárt minimális funkcionalitás 99 B.3 A szakellátás jövőképe 101 B.3.1 Múlt és jövő folyamatai 101 B Az informatikai rendszerek fejlődése 101 B Az egészségügyi folyamatok fejlődése 101 B.3.2 Várható fő kimenetek 102 B Online hálózatok hatása 102 B Hálózati input pontok bővülésének hatása 103 B Információ hiányból információ áradatra váltás 104 B Epizód kezelésből gondozási folyamat kezelésre váltás 105 B Életmód támogató informatikai rendszerek 106 III. KÖVETELMÉNYEK AZ EGÉSZSÉGÜGYI SZAKELLÁTÁSI INFORMÁCIÓS RENDSZEREK ÜZEMELTETÉSÉHEZ 107 C Egészségügyi szakellátási információs rendszerek üzemeltetési követelményei 108 C.1 Üzemeltetési alapkövetelmények 108 C.1.1 Szolgáltatás tervezés 108 C Szolgáltatás szint menedzsment 108 C Rendelkezésre állás és a szolgáltatások folytonosságának biztosítása 110 C Informatikai biztonság menedzsment 111 C.1.2 Szolgáltatás bevezetés 117 C Változáskezelés 117 C Kiadás és üzembe állítás 117 C Konfigurálás 118 C.1.3 Kiadás elfogadása 118 C Telepítés tervezése 118 C Ismeret menedzsment 118 C.1.4 Szolgáltatás üzemeltetés 118 C Incidens menedzsment 118 C Ügyfélszolgálat 119 C Probléma menedzsment 119 C Kérésteljesítés menedzsment 120 C Hozzáférés menedzsment 120 C Folyamatos szolgáltatásfejlesztés 121 C Üzemeltetési szerződésmenedzsment 121 C.2 A szakellátási rendszerek üzemeltetésének ajánlott követelményei 122 C.2.1 Szolgáltatás tervezés 122 C Szolgáltatás katalógus menedzsment 122 C Szolgáltatás szint menedzsment 122 C Kapacitás menedzsment 124 C Rendelkezésre állás és a szolgáltatások folytonosságának biztosítása 124 iii

5 Tartalomjegyzék C Informatikai biztonság menedzsment 126 C A hozzáférés ellenőrzése 129 C.2.2 Szolgáltatás bevezetés 130 C Szolgáltatási eszköz és konfiguráció menedzsment 130 C Változáskezelés 130 C Kiadás és üzembe állítás 131 C Konfigurálás 131 C Kiadás elfogadása 131 C Ismeret menedzsment 132 C Szolgáltatás validálás és tesztelés 132 C.2.3 Szolgáltatás üzemeltetés 132 C Eseménymenedzsment 132 C Incidens menedzsment 133 C Probléma menedzsment 134 C Kérésteljesítés menedzsment 134 C Hozzáférés menedzsment 135 C Folyamatos szolgáltatásfejlesztés 135 C Üzemeltetési szerződésmenedzsment 135 iv

6 Bevezető Előszó BEVEZETŐ Az egészségügy informatikájával szemben támasztott követelményeket sokféleképpen írhatjuk le. Igen nehéz egyszerre eleget tenni valamennyi szempontnak, amelyeket a felhasználhatósága támaszt vele szemben, tehát olyan szerkezetet kell alkalmaznunk a követelmény jegyzékünknek, amely áttekinthetően elégíti ki a következőket: 1. Legyen a követelmény jegyzék alkalmas informatikai tárgyú pályázatok mellékleteként meghatározni a szállítandó rendszerekkel szembeni követelményeket 2. Legyen alkalmas megítélni a működő informatikai rendszerek állapotát, megfelelését a követelményeknek 3. Feleljen meg az elvárható mértékben a 2014-el kezdődő tervezési időszak információ és kommunikációs technológiájának. A fenti feltételek első hallásra nem is olyan nehezen teljesíthetők. Viszont végig gondolva a feladatot, a kivitelezés nem is olyan egyszerű. Gondoljuk el, hogy egy adott terület (pl. az informatikai biztonság) követelménye egy most fejlesztendő rendszerre vonatkoztatva mennyiben tér el egy már évek óta működő informatikai rendszerétől. Nagyon eltér. Ami az egyik esetben alapkövetelmény, az a másik esetben lehet, hogy ajánlott csupán, és a megvalósítása messze túlmutat az üzemeltető anyagi lehetőségein. Ezért fel kell állítani egy mátrixot, amely oszlopai a követelmények szigorúságát jelentik, sorai pedig az alkalmazásuk területeit alkotják: Normatív követelmények Kötelező követelmények Kötelező/ajánlott követelmény, amennyiben specifikus 1 Ajánlott megoldás, illetve best practice Egészségügyi információs rendszerek pályázatai és projektjei A projektgazdára, a pályázati dokumentációra és projekt szervezetre kötelező érvényűek A projekt, illetve pályázat szakterületére vonatkozóan specifikus kötelező követelmények A projekt lebonyolításának best practice megoldásai 1 A követelmények specifikus területenként. 1

7 Bevezető Normatív követelmények Kötelező követelmények Kötelező/ajánlott követelmény, amennyiben specifikus 1 Ajánlott megoldás, illetve best practice Egészségügyi információs rendszerek B-implementációja C-üzemeltetése Olyan követelmények, amelyek függetlenül az implementálandó informatika alkalmazási területétől, kötelezőek Olyan követelmények, amelyek valamennyi informatikai rendszer üzemeltetésénél kötelezőek Olyan követelmények, amelyek egy-egy alkalmazási területen történő implementációnál relevánsak, és kötelezőek Olyan követelmények, amelyek valamennyi informatikai rendszer üzemeltetésénél ajánlottak Olyan követelmények, amelyek a legjobb megoldásokat eredményezik, illetve ajánlottak az implementáció esetén Nem értelmezett Nézzük meg, hogy ezzel a megoldással kielégítettük-e az előszó elején található szempontokat: 1. A pályázati rendszerben (projektek tervezésekor és lebonyolításakor) az A.1-A.2; B.1- B.2; C.1 követelmények beépíthetőek a projekt dokumentációba, képezhetik a rendszer technikai specifikációját. A C.2-ben leírtak szélesíthetik a követelményt. Ugyanakkor a B.3 képezheti azt a bónusz rendszert, amely az azonos értékű pályázatok közötti különbséget megadhatják. 2. A meglévő rendszerek architektúrájának, komponenseinek és kapcsolati rendszerének megítélésére az A.1-A.2 és B.1-B.2 használható. 3. Az előttünk álló tervezési időszakkal való összhangot az A.3-B.3 követelmények és megoldások fokozatos előrepozícionálásával lehet megteremteni. Ami ma javasolt megoldás, az holnap normatívvá válhat. Ez nem jelenti azt, hogy a ma kötelező követelmények 2020-ban is kötelezőek lesznek, lehet, hogy a technológia meghaladja azokat. A fenti struktúra szerint a követelményjegyzék valamennyi fejezete az A.1 C.3 besorolással tagozódik. Így az egyes szempontnak megfelelően dolgozó ember könnyen ki tudja magát ismerni az anyagban, hiszen pl. ha egy képalkotó diagnosztikai alrendszer beszerzésének normatív követelményeit keresi, akkor a B2 besorolású követelmények között kell a képalkotó diagnosztika specifikus követelményeket keresnie. Ez a megoldás látszólag egyszerűvé teszi az anyag kezelését, viszont még ez is válhat kevésbé áttekinthetővé: amennyiben a specifikus követelmények több részterületre specifikusak. 2

8 Bevezető Ilyenkor vagy megismétlődik a felsorolás, vagy újabb mátrix rendezi össze az összetartozóakat. Mi az előző megoldást választottuk, nem akarva a hivatkozások dzsungelét előállítani, kilátástalan bolyongásra kényszeríteni az olvasót. Az elkövetkező két évben olyan szintű változások előtt áll a hazai egészségügyi informatikai piac, amelyre még nem volt példa az egészségügyi informatika történetében. Reméljük, hogy a TIOP, EKOP és TÁMOP projektek melyek hamarosan a műszaki specifikáció a kiírás és a megvalósítás fázisába lépnek olyan szintű változásokat fognak indikálni, hogy az eddig bónusz kategóriába tartozó elvárások a mindennapok természetes részévé tudnak válni. Örömmel tekintjük át akkor újra ezt az anyagot és foglaljuk össze a generális váltást megélt magyar egészségügyi informatikát. 3

9 Bevezető Szószedet Adatbázis 2 : logikai objektumok és az azokat tároló fizikai adatállományok rendszerbe szervezett egysége. Az általánosan elterjedt relációs adatbázisok a világ entitásait jellemzőik, attribútumaik alapján írják le, és táblázatos formában ábrázolják; elemei között a kapcsolatot ún. kulcsok teremtik meg. Az adatbázisban elérhető adatok tetszőleges feltételek szerinti kinyerése (lekérdezése), illetve az adatoknak és az adatbázis szerkezetének módosítása az SQL nyelv segítségével lehetséges. Adatbáziskezelő-rendszer (Data Base Management System, DBMS) Az adatbázisokban tárolt adatok szervezését és kezelését, az azokon végrehajtható műveletek (adatok lekérdezése, módosítása, törlése, adatbázis karbantartása)elvégzését lehetővé tevő programrendszer. 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. Adattárház (Data Warehouse) Az adattárház egy szervezet legfontosabb adatai kronologikus tárolásának a helye. Az adatokat a szervezet alaptevékenységében szerepet játszó informatikai rendszerektől, az ún. operatív rendszerektől, mint forrásoktól veszi át, amelyeket speciális adattranszformációs eszközökkel alakítanak át, és tárolnak el az adattárházban. Az adattárház elsődleges célja, hogy a szervezetek vezetését taktikai-stratégiai szintű vállalatirányítási, döntéshozatali tevékenységében támogassa. Adatvédelem: az adatok gyűjtésének, feldolgozásának és felhasználásának szabályozását, az érintett személyek védelmét biztosító alapelvek, törvények, szabályok, eljárások, adatkezelési eszközök és módszerek összessége. Az egészségügyben kiemelt szerepet kap a személyes és egészségügyi adatok szigorú előírások szerinti kezelése. Algoritmus: egy probléma megoldására bevezetett, véges számú cselekvéssor, módszer, utasítás(sorozat), részletes útmutatás melyet az előírás szerint végrehajtva a probléma megoldását kapjuk. Audit: a szervezet, illetve meghatározott program, szolgáltatás vagy alkalmazás folyamataira vonatkozó menedzsment- és üzemeltetési biztonsági intézkedések szabványokban, ajánlásokban, illetve a nemzetközi legjobb gyakorlatokban leírt elvárásoknak való megfelelőségének vizsgálata, és a megfelelés, illetve meg nem felelés tanúsítása 3 Autentikáció: egy szolgáltatást igénybevevő egyén vagy szervezet személyazonosságának igazolása egy hitelesnek minősített forrás alapján. Távkapcsolatoknál használatos eljárás, ahol előre rögzített adatokkal vetik össze a bejelentkező által a bejelentkezési eljárás során megadott adatokat /2009. (X. 14.) Korm. rendelet 4

10 Bevezető Autorizáció: különböző szolgáltatások, alkalmazások igénybevételére vagy műveletek végzésére szolgáló felhatalmazás. Az autentikációs eljárás után a rendszer megállapítja a felhasználó vagy kezelő jogosultságait abban a rendszerben amelybe a bejelentkezés történt. 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. attribútum: olyan tulajdonság amely elválaszthatatlanul hozzátartozik valamihez, vagy valakihez. 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. Cloud computing: (felhő alapú számítástechnika) A felhő alapú számítástechnika az a számítástechnikai megközelítés, amikor igen nagy mértékben rugalmasan skálázható eszközeiket, valamint IT által támogatott képességeiket a szervezetek szolgáltatásként kiajánlják nagy számú, külső partner számára internettechnológiák felhasználásával. Többféle felhő alapú szolgáltatást különböztethetünk meg. Közös bennük az, hogy a szolgáltatásokat nem egy dedikált hardvereszközön üzemeltetik, hanem a szolgáltató eszközein elosztva, a szolgáltatás üzemeltetési részleteit a felhasználótól elrejtve. Ezeket a szolgáltatásokat a felhasználók hálózaton keresztül érhetik el, publikus felhő esetében az interneten keresztül, privát felhő esetében a helyi hálózaton vagy az internet védett vonalán keresztül. 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) EHR (Electronic Health Record): egy lokális HIS-ben tárolt, egy ellátottról szóló egészségügyi adatok. Formátuma tetszőleges,a HIS lokális felelőssége. EHRextract (egészségügyi adat kivonat): a lokális HIS-t elhagyó, szabályozott tartalmú és formátumú elektronikus dokumentum ESB (Enterprise Service Bus) : olyan köztes szoftver (middleware) termékek, amelyek eseményvezérelt üzenetközvetítő szolgáltatást valósítanak meg egy adott szervezet keretein belül. Egy szervezeten belül biztosítja a teljes informatikai rendszerben az alkalmazások és az ezeket alkotó szoftverkomponensek közötti egységes információáramlást, mivel ezek a komponensek szolgáltatások, szabványos, jól definiálható és könnyen módosítható komponensek. 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 Információbiztonság: az információ biztonsági szempontból lényeges alaptulajdonságaira 5

11 Bevezető utal. Ezek közül a három legfontosabb az elérhetőség, a bizalmasság és a sértetlenség. Az információbiztonság igényelt szintjét az információ megfelelő védelmével, mint gyakorlati tevékenységgel lehet biztosítani. Az információbiztonság bővebb, mint az informatikai biztonság, mivel kiterjed a nem IT-eszközökkel tárolt és kezelt adatokra is. Informatikai biztonság: az informatikai rendszerek és eszközök (szoftver, hardver vagy ezek együttese) védettsége az elvárt működést (biztonságos működést) akadályozó vagy veszélyeztető kockázatok (cselekmények, külső hatások vagy ezek következményeként előálló állapotok) ellen. Informatikai közmű: olyan módszerekkel és eszközökkel dolgozó informatikai szolgáltató központ, amely képes arra,hogy sok felhasználónak nyújtson azonos vagy nagyon hasonló informatikai szolgáltatást gyors és megbízható hozzáférés és védelem biztosítása mellett. Interface: két vagy több hardver vagy szoftver rendszer közötti közös egy vagy kétirányú kommunikációra képes kommunikációs felület. 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. ITIL: az ITIL az informatikai rendszerek üzemeltetésére és fejlesztésére szolgáló módszertan, illetve szabvány- és ajánlás-gyűjtemény neve. A betűszó az informatikai internetkönyvtár (Information Technology Infrastructure Library) angol nyelvű rövidítése. Az ITIL az Egyesült Királyság kormányzati beszerzésekért felelős hivatalának (Office of Government Commerce) szabványosító tevékenységeként jött létre. Mára az IT-szolgáltatásmenedzsment nemzetközi szinten elfogadott keretrendszerévé vált, amely praktikus ajánlásokat fogalmaz meg a szervezetek IT-szolgáltatásának kialakítására és fejlesztésére vonatkozóan. kritikus infrastruktúra: olyan, egymással összekapcsolódó, interaktív és egymástól kölcsönös függésben lévő infrastruktúra elemek, létesítmények, szolgáltatások, rendszerek és folyamatok hálózata, amelyek az ország (lakosság, gazdaság és kormányzat) működése szempontjából létfontosságúak, érdemi szerepük van egy társadalmilag elvárt minimális szintű jogbiztonság, közbiztonság, nemzetbiztonság, gazdasági működőképesség, közegészségügyi és környezeti állapot fenntartásában, és ezért meg kell felelniük az alapvető biztonsági, nemzetbiztonsági követelményeknek 4 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 információbiztonsági fenyegetés: mindazok az események, amelynek bekövetkezése esetén a rendszerhez fűződő érzékeny információk jogosulatlanul kerülnek más birtokába, vagy válnak megismerhetővé, vagy válnak elérhetetlenné, vagyis sérülnek az e rendeletben megfogalmazott adat- és információbiztonságra meghatározott követelmények 5 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 /2009. (X. 14.) Korm. rendelet 5 223/2009. (X. 14.) Korm. rendelet 6

12 Bevezető 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. 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. kibertér : globálisan összekapcsolt, decentralizált, egyre növekvő elektronikus információs rendszerek, valamint ezen rendszereken keresztül adatok és információk formájában megjelenő társadalmi és gazdasági folyamatok együttesét jelenti 6. 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 kooperatív tér: egészségügyi ágazati informatikai szféra mely megtartja a korábban kialakított informatikai rendszerek autonómiáját, de azok összekapcsolhatóságát és a közöttük történő folyamatok szabályozását hozzáadott eszközök segítségével valósítja meg. 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. Middleware 7 : (köztes szoftver). Egy olyan elérhető szoftver réteg, mely a heterogén platformok és protokollok hálózati rétege és az üzleti alkalmazás(ok) között helyezkedik el. Leválasztja az üzleti alkalmazásokat bármilyen, a hálózati réteg okozta függőségről operációs rendszerek, hardver platformok és kommunikációs protokollok okoznak. A köztes szoftver megkönnyíti a szoftverfejlesztők dolgát a kommunikációs és az input/output feladatok végrehajtásában. 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 6 Részletesen lásd: 1139/2013. (III. 21.) Korm. határozat (Hatályos: től) 7 A middleware-eket öt csoportba oszthatjuk: távoli eljáráshíváson (remote procedure call - RPC) alapuló middleware, osztott számítási környezet (Distributed Computing Environment - DCE); üzenetközpontú middleware (Message Oriented Middleware - MOM); hordozható tranzakció feldolgozó monitor (Transaction Processing Monitors - TPM); objektum lekérdező ügynök (Object Request Broker - ORB) beleértve az OLE/COM/DCOM technológiát; adatbázis middleware 7

13 Bevezető pszeudonim: nem valódi neven meghjelenő 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-orientált Architektúra. A szoftverrendszerek felépítésének olyan módszere, ahol a programok a hálózaton rendelkezésre álló különböző szolgáltatásokat tudják szabványosított módon elérni. A szolgáltatás-orientált architektúra egy olyan szoftverarchitektúra, amelyben a szoftveralkalmazások alapvetően üzleti funkciót nyújtó szolgáltatásokból, valamint szolgáltatáshasználó (service consumer) és esetleg egyéb szoftvermodulokból épülnek fel. A SOA olyan architektúra, amely a szolgáltatásnyújtó és a szolgáltatáshasználó modulok közötti rugalmas kapcsolódásban valósul meg. A szolgáltatás-orientált architektúra egyik leg jellemzőbb tulajdonsága, hogy a szolgáltatások jellemzően több, különböző alkalmazásban is felhasználásra kerülnek. 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. XML 8 (Extensible Markup Language): általános célú leíró nyelv speciális célú leíró nyelvek létrehozására. Az elsődleges célja strukturált szöveg és információ megosztása az interneten keresztül. Az XML-en alapuló nyelvek (például RDF, RSS, MathML, XSIL, SVG) formális módon vannak leírva, így lehetővé téve a programok számára a dokumentumok módosítását és validálását a formátum előzetes ismerete nélkül. 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). vezeték nélküli személyi hálózat: (Wireless Personal Area Network - WPAN) a személy köré építve szolgálja az életvitelt, egészséget és más területen az egyént néhány méter hatótávolságon belül. 8 wikipedia.org 8

14 Bevezető Rövidítések: CEN CENELEC CEN TC/251 CEN/TS EHCR EHR EPR ETSI HL7 IANA IETF ISO MIME MSZ MSZE PAN RFC TAJ UML URI URL W3C XML XSD Comité Européen de Normalisation (Európai Szabványosítási Bizottság) Comité Européen de Normalisation Electrotechnique (Európai Elektrotechnikai Szabványosítási Bizottság) CEN Technical Committee 251 (A CEN egészségügyi informatikai szabványok fejlesztésével foglalkozó technikai bizottsága) CEN Technical Specification Electronic Healthcare Record Electronic Health Record Electronic Patient Record European Telecommunications Standards Institute Health Level Seven Internet Assigned Numbers Authority Internet Engineering Task Force International Organization for Standardization Multipurpose Internet Mail Extensions Magyar Szabvány Magyar Előszabvány Personal Area Network Request For Comments Társadalombiztosítási azonosító jel Unified Modelling Language Uniform Resource Identifiers Uniform Resource Locator World Wide Web Consortium Extensible Mark-up Language XML Schema Definition 9

15 Egészségügyi informatikai pályázatok és projektek I. EGÉSZSÉGÜGYI INFORMATIKAI PÁLYÁZATOK ÉS PROJEKTEK 10

16 Egészségügyi informatikai pályázatok és projektek A Követelmények az egészségügyi informatikai pályázatokhoz és projektekhez A.1 A fejlesztési pályázat és a megvalósítási projekt alapkövetelményei 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. 11

17 Egészségügyi informatikai pályázatok és projektek 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. 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. Itt is hangsúlyozzuk a leszállított megoldásnak a kiírásban foglaltaknak való megfelelésének fontosságát, ennek ellenőrzését. 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 12

18 Egészségügyi informatikai pályázatok és projektek é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ó 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. Elképzelhető, hogy ezeknek a folyamatoknak a számítógépes alkalmazásokkal való támogatása, azaz ilyen célszoftverek használata ma még talán inkább a best practice kategóriába kívánkozik, de szeretnénk, ha ez a közeli jövőben mindenütt (a beszállítónál) alkalmazásra, a kedvezményezettnél pedig megértésre találna. (Ezért nem is az A.3 részben szerepeltetjük.) 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észletezett szempontok 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 9 állapotával. A.1.1 Az intézmény felkészültségének követelményei A.1.1.1A fejlesztés elhelyezése az intézmény működésében A A A A A A 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. 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.) 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 évi LXXVI. törvény a szerzői jogról 13

19 Egészségügyi informatikai pályázatok és projektek A A A A A A A A A A A A A A A A A A Előzetes pénzügyi elemzés készült (költségvetés megalapozottságának és realitásának vizsgálata, a projekt pénzügyi érzékenység vizsgálata, pénzügyigazdasági megtérülés kiszámítása stb.) 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 ö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 14

20 Egészségügyi informatikai pályázatok és projektek A A A A kerültek. 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. 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. A Intézményi követelmények a fejlesztés előkészítésére A A A A A A A A A A A A A A A A A fejlesztés kedvezményezettje rendelkezik informatikailag képzett kulcsfelhasználókkal. Az intézményi menedzsment elkötelezett az IKT megoldások mellett, az új fejlesztések előnyeit, kedvező hatásait ismeri. 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. A felső vezetés információs igényei pontosan meghatározottak, és ezeket a fejlesztendő rendszer ki fogja szolgálni. Az információ-menedzselés szerkezete pontosan megtervezett, ismert. 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) A projektet végrehajtó intézmény szervezeti, pénzügyi és humán erőforrásoldali felkészültségének felmérése megtörtént. Az intézményi folyamatok informatikai támogatottsága pontosan ismert, felmért és követhető. Az informatikai fejlesztést megelőzően történt szervezetfejlesztési felmérés. A szervezetfejlesztési lépések informatikailag is megalapozottak, tervezettek. A fejlesztések, alkalmazások támogatják az alapvető orvosi/egészségügyi 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 szinten 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. 15

21 Egészségügyi informatikai pályázatok és projektek A A A A 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. A.1.2 A beszállító felkészültségének és ajánlatának követelményei A A A A A A A A A A A A Beszállítói követelmények 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égellenő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 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 16

22 Egészségügyi informatikai pályázatok és projektek A A A A A A 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ó 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ő. A Az ajánlott megoldás illeszkedése a kiíráshoz A A A A A A A A A A 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 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.) Az ajánlat tartalmazza az ajánlott megoldás üzleti koncepciójá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 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) 17

23 Egészségügyi informatikai pályázatok és projektek A A A 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. A.1.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.1.3.1A fejlesztés előkészítésének tervezési feladatai és módszerei A A A A A A A A A A A A A A A A A A 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. Előre definiálásra kerültek azok a folyamatok, amelyeket a fejlesztés érint. 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. Készült kommunikációs terv. 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. 18

24 Egészségügyi informatikai pályázatok és projektek A A Projekt Alapító Dokumentum követelményei A A A A A A A A A A A A A A A A A A A A A A A A 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. 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 19

25 Egészségügyi informatikai pályázatok és projektek A ismertetését. A PAD tartalmazza az infrastruktúra közmű (IT és kommunikációs) ismertetését. A A fejlesztéssel kapcsolatos szerződés(háló) kialakításának követelményei A A A A A A A A A A A A A A A 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ó jogosulte, é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ó jogosulte, é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 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 20

26 Egészségügyi informatikai pályázatok és projektek A A A A A A A A A A (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. A Szoftverszerződésekkel kapcsolatos elvárások A 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 kell lennie a szerződéskötéskor érvényes szerzői jogi törvénnyel 10. A A fejlesztés megvalósítása követésének követelményei A A A A A projekt/fejlesztés minőségbiztosítása (szervezetileg, felelős stb.) biztosított 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) 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 évi LXXVI. törvény a szerzői jogról 21

27 Egészségügyi informatikai pályázatok és projektek A A A A A A A A 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 A fejlesztés eredményének követelményei A A A A A A A A A A A A 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. A garanciális időszak alatt a felmerült hibák javítása biztosított. 22

28 Egészségügyi informatikai pályázatok és projektek A.2 A fejlesztési pályázat és a megvalósítási projekt specifikus követelményei A.2.1 Az intézmény felkészültségének követelményei A A fejlesztés elhelyezése az intézmény működésében A A A A A A A A A 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. Az egyes fejlesztési alternatívákat megalapozó/megerősítő tanulmányok/állásfoglalások rendelkezésre állnak (szakmai, menedzsment, informatikai 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é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és kedvezményezett oldali irányításához szükséges vezető szakemberek (belső menedzsment, IT oldali projektvezető stb.) felmentést 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.) felmentést vagy könnyítést kaptak a fejlesztés idejére egyéb tevékenységeik végzése alól. A Intézményi követelmények a fejlesztés előkészítésére A A A A A A fejlesztés kedvezményezettje rendelkezik informatikailag képzett felhasználókkal. Az informatikai eszközök használata megtalálható az intézmény fejlesztésben érintett egységeinél. 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 Az intézmény elérhető elektronikus úton a betegek, páciensek, ügyfelek számára (elektronikus ügyintézés), illetve a fejlesztés eredményeképpen ez megvalósul. 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) 23

29 Egészségügyi informatikai pályázatok és projektek A A A A 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 Az intézmény fejlesztésben érintett dolgozói képesek a fejlesztési igényeiket informatika közeli szemléletmódban megfogalmazni. A kórházi/intézményi informatika intézeten belüli szinten (pl. osztályok) is felelős (koordinátor) kinevezése mellett van kialakítva és működtetve. 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) A.2.2 A beszállító felkészültségének és ajánlatának követelményei A Beszállítói követelmények A 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 Az ajánlott megoldás illeszkedése a kiíráshoz A A A A A A A A A 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á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. 24

30 Egészségügyi informatikai pályázatok és projektek A A A A A A A A A A A A A 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 11, 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. 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 12 (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 licencezést. 11 Eurorec: GS Eurorec: GS

31 Egészségügyi informatikai pályázatok és projektek A.2.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 A fejlesztés előkészítésének tervezési feladatai és módszerei A A A A A A A A A A A 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). 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. Az előfeltételek, feltételezések és kockázatok elemzése megtörtént (kockázatkezelési terv). 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 feladatok kivitelezőinek (kompetenciák és felelősségek mátrixa) meghatározása megtörtént. A mérföldkövek meghatározásra kerültek. A kritikus út meghatározásra került. 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) 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 A Projekt Alapító Dokumentum követelményei A A fejlesztéssel kapcsolatos szerződés(háló) kialakításának követelményei A Szoftverszerződésekkel kapcsolatos elvárások A 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 A szerződés(ek)ben - a szerzői, illetve felhasználási jogokkal kapcsolatban - 26

32 Egészségügyi informatikai pályázatok és projektek az alábbiak rögzítése elvárt: A A A A A A A A A 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. 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á 13. 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 13 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. 27

33 Egészségügyi informatikai pályázatok és projektek A 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 A fejlesztés megvalósítása követésének követelményei - A A fejlesztés eredményének követelményei - A.3 Alkalmazandó eljárások a jövőben A.3.1 Az intézmény felkészültségének követelményei A A fejlesztés elhelyezése az intézmény működésében - A Intézményi követelmények a fejlesztés előkészítésére - A.3.2 A beszállító felkészültségének és ajánlatának követelményei A Beszállítói követelmények - A Az ajánlott megoldás illeszkedése a kiíráshoz - A.3.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 A fejlesztés előkészítésének tervezési feladatai és módszerei - 28

34 Egészségügyi informatikai pályázatok és projektek A A Projekt Alapító Dokumentum követelményei - A A fejlesztéssel kapcsolatos szerződés(háló) kialakításának követelményei - A Szoftverszerződésekkel kapcsolatos elvárások - A A fejlesztés megvalósítása követésének követelményei - A A fejlesztés eredményének követelményei - 29

35 II. KÖVETELMÉNYEK AZ EGÉSZSÉGÜGYI SZAKELLÁTÁSI INFORMÁCIÓS RENDSZEREK FELÉPÍTÉSÉHEZ 30

36 B Egészségügyi szakellátási információs rendszerek implementációs követelményei B.1 Az informatikai rendszerek alapkövetelményei B.1.1 Az informatikai infrastruktúra architektúrális követelményei B 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. Üzemelési és kommunikációs sztenderdek, 3. Szolgáltatási színvonal és szintek egységesedése, a színvonal emelkedése. 4. Az ágazat stratégiai fejlesztési projektjeivel való összhang biztosítása informatikai képességek szintjén. 5. Ágazati szereplők (intézmények, kórházak, stb.) közpénzzel támogatott informatikai fejlesztéseinek kötelező tartalmi elemei 6. Ágazati szoftver / informatikai rendszer fejlesztés 7. Ágazati szoftver / informatikai rendszer akkreditáció bírálati szempontjai 8. 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, informatikai szempontból teljes egészében kompatibilis és a rendszer külső kapcsolatait nem befolyásolja (azokkal konform módon együtt dolgozik). B Jogi formában rögzítendő ajánlások az egészségügyi informatikai rendszerek védelme és biztonsága érdekében A helyi szabályok kialakításánál a központilag kialakított szabályzott eljárásrendektól eltérni csak a helyi sajátosságoknak megfelelő adaptáció biztosítása mértékéig szabad de ez az eljárásrendek alapvető módosítását nem befolyásolhatja. 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. 31

37 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, 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 32

38 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, 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. 33

39 B Á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 az ESB 14 és a SOA 15 típusú megoldások alkalmazása. A megfelelő fejlesztési technológia kiválasztásával időtálló 16, fenntartható B rendszereket kell fejleszteni. Robosztus hardver és szoftver architektúra (rugalmas, a változásokat jól tűrő): 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) B 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 17 : a megvalósításra kerülő alkalmazás kettő (kliens- szerver), B vagy több rétegű (multi-tiered) architektúrára 18 é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 B intézményrendszernek, mint felhasználó számhoz szükséges méretre való bővítés lehetőségét. A megfelelőséget a gyártó általgarantált technikai paraméterek 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ő, B 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 19. Meg kell határozni, hogy mely eszközök szolgálnak egymás tartalékaiként, illetve az egyes tagok B milyen szerepet (aktívkiszolgálói, tartalék) játszanak. Definiálni szükséges a feladatátvétel módját és az adott szolgáltatás által elvárt feladatátvételi időket. A hardveres redundancia mellett az alkalmazás-szoftveres redundáns megvalósítása a rendelkezésre állás érdekében indokolt. Támogatott azon B technológiák virtualizált szoftveres környezetben történő megvalósítása amelyek működése több egymástól független gyártó virtualizált szoftver környezetében is bizonyítottan működőképes, vagyis a szoftver termék nem 14 ESB (Enterprise Service Bus), olyan köztes szoftver (middleware) termékek, amelyek eseményvezérelt üzenetközvetítő szolgáltatást valósítanak meg egy adott szervezet keretein belül. Egy szervezeten belül biztosítja a teljes informatikai rendszerben az alkalmazások és az ezeket alkotó szoftverkomponensek közötti egységes információáramlást, mivel ezek a komponensek szolgáltatások, szabványos, jól definiálható és könnyen módosítható komponensek. 15 SOA (Service Oriented Architecture), magyar terminológiával Szolgáltatás-orientált 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. 16 Az időtállóságnál figyelembe kell venni a évi XLVII. Törvény-ben foglalt adatmegőrzési időtartamokat. Gyártói és szoftverfejlesztői nyilatkozat és megvalósítási leírás szükséges az időtállóság megvalósításáról. 17 Architektúra: a rendszer alapvető komponenseinek szerveződése. A komponensek egymással jól definiált, hierarchikus szervezésű felületeken keresztül kommunikálnak egymással. 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. 18 Pl. three-tier architektúra - kliensl, alkalmazás szerver (application server), adatbázis szerver (database server) 19 Pl: feladatátvételi pár topológia, forró tartalék, feladatátvételi gyűrű, stb. 34

40 B B B B B B B B B alkalmaz egyedi szoftver specifikus megoldásokat. Az informatikai hálózat szempontból is redundáns kapcsolatot kell biztosítani a kliensek számára a szerver elérés érdekében. Ez különösen fontos több telephelyes vagy ágazati megvalósítások esetében. 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 kommunikációs felületekkel (pl:soa) kell rendelkeznie. A megvalósítás során definitív elvárás, hogy csak az ágazati szinten definiált és előírt kommunikáció protokollok és útvonalak betartásával (pl. kooperatív tér) és használatával történjen a HIS rendszerek és az ágazatirányítás szervei közötti kommunikáció. Ez a megoldás biztosítja, a korábban kialakított informatikai rendszerek autonómiáját és azok összekapcsolhatóságát. Ezért elvárás: o A kommunikációs felületek és eljárások megfelelőségéhez szükséges a kommunikáció logikai modelljének ágazati szintű kidolgozása. o Az ágazati szintű kommunikációs üzenet típusok (archetípusok) 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 Az informatikai rendszereket fel kell készíteni arra, hogy rendszert üzemeltető felhasználók önállóan definiálni tudjanak új szabványos módon specifikált kommunikációs üzeneteket o A megvalósított kommunikációs üzeneteket dokumentáltan, előre mutató módon fel kell készíteni a keretrendszer kapcsán várható jövőbeli változások 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 20 elvárásai és az operatív programokban kidolgozott és megvalósított szabályrendszerek és működési modellek az irányadók. Az informatikai szállítónak minden fejlesztés során be kell mutatnia, hogy a megvalósításra kerülő rendszermilyen módon van felkészítve a szabványos működésre és kommunikációra. Deklarálni szükséges, hogy a tervezés során mely elvárások és milyen módon lettek a rendszer kialakításánál figyelembe véve. Hogyan van a rendszer felkészítve az ágazati szintű működésre felkészítva Felhasználói interfésszel kapcsolatos elvárások: 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ű, 20 Az E-közigazgatási Keretrendszer létrehozásának célja azon szabványoknak, követelményeknek és előírásoknak a meghatározása, amelyek biztosítják az elektronikus közigazgatás teljes fejlesztéséhez és üzemeltetéséhez az egységes technikai, szemantikai, IT biztonsági, alkalmazásfejlesztés-módszertani, valamint projekt-menedzselési és monitoring platformot. 35

41 B B B elérhetőségét az általánosan elterjedt, kereskedelmi forgalomban rendelkezésre álló hálózati kapcsolatokon keresztül 21. A tükrözés 22 vagy a megfelelő szintű RAID 23 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 24. B Infrastruktúrális követelmények A környezeti hibaforrásokat minimálisra kell csökkenteni. Az B alkalmazásokat futtató hardver környezetet minimálisan a következő paraméterekkel rendelkező gépteremben 25 kell elhelyezni ahol biztosított: B o a gépek hőtermelésének megfelelő 26 légkondicionálás; B o az eszközök illetéktelen személyek általi hozzáférése elleni védelme; B o az érvényes tűzvédelmi előírásoknak megfelelő tűzvédelmi infrastruktúra; o a szolgáltatást igénybe vevő, felhasználók számának, és a használt B alkalmazásoknak megfelelően 27 méretezett sávszélességű primer és szekunder betáplálású hálózati 28 csatlakozás; o az alkalmazások által kezelt adatok üzemszerű 29 működéséhez B szükséges méretezésű háttértároló eszközök és kellő számú jogtiszta szoftver licenszek; o az alkalmazások által kezelt adatok rendszeres mentéséhez szükséges B mentési eszköz és a működtetéshez kellő számú jogtiszta mentő szoftver; o a működtető szoftver környezet, alkalmazások és az alkalmazások B által kezelt adatok rendszeres archiválásához 30 szükséges eszköz, archiváló szoftver, kellő számú licence és tároló kapacitás; B o a gépek teljesítmény felvételének megfelelő, szünetmentes B áramellátást biztosító szünetmentes táp rendszer 31 ; o A szerver számítógépek és a szünetmentes áramforrásoknak rendelkezniük kell távmenedzsment 32 kommunikáció megvalósító funkcionalitással az eszközpark operációs 21 Az elvárt válaszidőket alkalmazás típusonként, funkciónként egyedileg kell specifikálni, figyelembe véve az egyidejű belső és külső felhasználói számot, az adott időben kiszolgálandó tranzakció számot és az azonos időben futó alkalmazások számát és típusát, valamint a webes alkalmazói felületen és a hálózatos kommunikációs kapcsolódásokon beérkező (beérkezhető) kérések kiszolgálását is. 22 Operációs rendszer és a felhasználói szoftverek számára minimálisan elvárt a duplikált HDD-ből kialakított RAID 1 (tükrözés) tömb 23 Betegadatok tárolása esetén helyi rendszereknél 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. 24 A hardver eszközöket úgy kell méretezni, hogy lekérdező modult csúcsidőben történő használata ne okozzon az egyéb alkalmazások esetében válaszidő növekedést. 25 Mind lokális mind hosting megvalósítás esetében elvárás 26 A gépek hőtermelését a pontos hardver konfigurációt figyelembe véve a gyártó által biztosított szoftver segítségével történő számítással kell dokumentálni. 27 A sávszélesség megfelelősségét számítással kell dokumentálni. 28 Pl: internet, bérelt vonali, mobilnet, stb. 29 Az üzemszerű működés és fenntartás feltételeit írásban definiálni kell. Eurorec: GS GS 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. 31 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 áramellátás méretezését számítással kell dokumentálni. 32 pl. SNMP (Simple Network Management Protocol) 36

42 B B B B B B o rendszer platformok mindegyikére (pl. Windowsxx, Linux xx, ) 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. A helyes működést rendszeres időközönként a beépített szoftver segítségével teszteléssel kell ellenőrizni. Javasolt a szolgáltatói rendszerek hardver, szoftver, és ahálózat aktív eszközeinek és a hálózati forgalom (protokoll típusú) folyamatos és naplózott monitorozását és távfelügyeletét biztosítani képes felügyeleti és távfelügyeleni 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 33 folyamatosan mérhetők grafikus formában megjeleníthető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 o rendszeres hardver és szoftver önellenőrzés beállíthatósága. Hiba esetén legyen mód a riasztások többféle eszközön történő egyidejű elküldésére (pl. felügyeleti képernyő, , sms, stb.) B 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 rendszereken ütemezetten biztonsági mentéseket és rendszeres időközönként teljes rendszer mentést 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. B Biztosítani kell az adatok és rendszerek időszakos napi, heti, havi, éves mentését a vállalt szolgáltatási szinthez illeszkedő mentési rend alapján 34. A mentő és archiváló rendszerek tegyék lehetővé az operációs rendszer és patch állapotának valamint beállításainak, paramétereinek mentését B az eszköz vezérlő szoftverek és azok path állapotának és beállításainak mentését alkalmazói és rendszer szoftver(ek) környezet és a beállított rendszerparamétereinek mentését Az SLA az angol Service Level Agreement kifejezés rövidítése, ami magyarul szolgáltatási szint szerződést jelent. Az SLA-ban 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. 34 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. 35 system backup 37

43 B B B B B B B B A 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. A mentő és archiváló rendszerek biztosítsák a mentett adatok és a rendszerparaméterek hibamentes, konzisztens visszaállítását. A visszaállítás képességét rendszeres időközönként ellenőrizni szükséges. A mentő és archiváló rendszerek tegyék lehetővé az elektronikus adathordozókon tárolt adatok, állományok utólagos, esetleges részleges elérhetőségét (elolvashatóságát), esetleges visszatölthetőségét. Ezt 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 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 az üzleti folyamatok helyreállítása érdekében működésfolytonossági tervet amely tartalmazzon olyan részletesen kidolgozott eljárásokat amelyek segítségével az egyes rendszerek kiesése esetén a működés papír alapon biztosítható. Az eljárásnak azt is tartalmaznia kell, hogy a kiesés ideje alatt papíron rögzített adatok milyen módom kerülnek utólagosan rögzítésre a rendszerekbe. Az egészségügyi dokumentációnak és az egészségügyi ellátás során képződött adatoknak az adathordozón minimálisan a törvényben előírt időtartamig 36 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 elvégezni 37. A rendszer minimálisan az alábbi mentésekre legyen felkészítve: o Teljes mentés 38 o Inkrementális mentés 39 kumulatív mentés (növekményes) 40 differenciális mentés (különbségi) 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. A (7) bekezdés értelmében A gyógyszertár a vényeket 5 évig őrzi meg.. (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. 37 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. 38 A működtető szerver eszköz háttértárolóján található minden adat válogatás nélkül mentésre kerül (operációs rendszer, eszköz vezérlők,alkalmazások, adatbázisok és mindezek paraméterei beállításai). A mentési folyamat ezért egyszerű, ellenben sok ideig tart és sok tárterület szükséges hozzá. Előnye azonban, hogy a visszaállítás viszonylag gyors. 39 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 kummulatív és a differenciális mentés. 40 Ezen mentés során mindig az utolsó teljes mentés óta megváltozott adatok kerülnek elmentésre. A kumulatív mentési stratégiánál ha egy adatelem valamikor megváltozott, akkor az minden kumulatív mentés alkalmával ismételten mentésre kerül egészen a következő teljes mentésig. Visszaállításhoz az eredeti teljes mentésre, és a legutolsó kumulatív mentésre van szükség. A kumulatív mentés gyorsabb a teljes mentésnél és kevesebb helyet is kíván. A differenciális mentésnél azonban lassabb és a tárigénye is nagyobb. 41 A differenciális mentés során csak az utolsó inkrementális mentés óta megváltozott adategységek kerülnek elmentésre. Ha két teljes mentés között több differenciális mentést végzünk, akkor pl. a második differenciális mentés csak az első óta történt változásokat fogja 38

44 B o Pillanatkép (snapshot készítés) 42 Elosztott rendszereknél az inkonzisztencia elkerülése érdekében a biztonsági mentéseket és visszatöltéseket koordináltan kell végezni az egymással kommunikáló adatbázisok esetében. B 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. B B B B B B B 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 az egészségügyi informatikai rendszerek működtetésére vonatkozó utasításokkal és előírásokkal 43, valamint a fejlesztésre rövid és hosszútávra 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 44, 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 a szolgáltatások folytonosságát biztosító eljárásrendekkel,, 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 45, 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 rögzíteni. Ennek köszönhetően maga a mentés folyamata gyorsabbá válik, és esetenként kevesebb helyet foglal el. Hátránya azonban, hogy a visszaállításhoz a legutolsó teljes mentésre, és az azt követő összes differenciális mentésre szükség van. 42 A rendszer teljes állapotáról készítünk egy "pillanatfelvételt". Ez egy fájl lesz a merevlemezünkön, amely az adott kötet tulajdonságait, programbeállításait tartalmazza, illetve a memória aktuális állapotát. 43 Adatvédelmi és adatkezelési szabályzat, Biztonsági Politikák (felhasználói policy, rendszergazdai policy, fejlesztői policy, ), Felhasználói Hozzáférés szabályzata, Távoli hozzáférés szabályozása (Lásd bővebben a B.1.4 fejezetet) 44 Rendszergazdai leírások, beüzemelési beállítás paraméterezése, működési és üzemeltetési paraméterek, hibaelhárítási útmutatók, stb. 45 Részletesen specifikációt lást a Mentési, archiválási, visszatöltési követelmények 39

45 B B B B B B B B B B B B B B B anyagokat a jogszabályokban meghatározott ideig, bármikor visszakereshetően, helyreállíthatóan megőrizzék 46, o a szolgáltatás folyamatosságát akadályozó rendkívüli események kezelésére üzemeltetési és hibaelhárítási nyomvonalak kialakításai tervet kell kialakítani 47. 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 elemei használatának (eszközök, folyamatok, személyek) egyértelmű és visszakereshető azonosításáról, 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 folyamata, 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 48, sértetlenségéről, naplózásáról és hitelességéről, o az adathordozók szabályozott és biztonságos kezeléséről, tárolásáról, rendszeres időközönként történő cseréjéről, o a rendszer vírusvédelméről 49, annak rendszeres, központi frissítéséről és folyamatos menedzsmentjéről. A napló állományok rendszeres ellenőrzésé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. Különös kockázatot jelent egyedi módon kell foglalkozni a mobil eszközök speciális vírusvédelmével. 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, korrekciójához szükséges rendszerleírásoknak és modelleknek, o az informatikai rendszerekkel kapcsolatban az adatok szintaktikai szabályainak, az adatok tárolási szerkezetének, o az informatikai rendszernél a tárolt 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, 46 EuroRec: GS Hibaelhárítási nyomvonalterven ebben az esetben az Intézetben működő informatikai rendszerek üzemeltetési és hibaelhárítási nyomvonalak kialakításai tartoznak. 48 Eurorec: GS 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. 40

46 B B B B B B B B B B B B 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, ) 50, 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. Ügyfél azonosításával kapcsolatos eljárás esetén olyan biztonsági követelményeknek 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 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 és átláthatóságát az Intézet hálózatán belül. 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 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. Amennyiben az IT biztonság üzemeltetését külső cég végzi, abban az esetben az IT biztonsági szabályzat kialakításában az 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 kártya és kulcsmenedzsmentet a biztonsági szabályzattal összhangban, a korszerű kriptográfia eszközök segítségével kell megvalósítani. A rendszer tegye lehetővé a biztonsági funkciók auditja során a rögzített és tárolt log állományok megtekintését, elemzését. A rendszer logolja és jelezze a biztonságot veszélyeztető eseményeket tegye lehetővé a biztonsági funkciók auditja során a rögzített és tárolt logok megtekintését, elemzését Az informatikai célrendszerre vonatkozó informatikai biztonsági előírások 51 teljesülését meghatározott időközönként (az éves minőségbiztosítási audit kapcsán) rendszeresen felül kell vizsgálni, ellenőrizni. Szükség esetén független szakértővel ellenőriztetni (minősíttetni) javasolt. B Időszinkronizálás 50 Lásd az üzemeltetési és hibaelhárítási nyomvonalak 51 Az előírásokat a 195/2005. (IX. 22.) Korm. rendelet változásának megfelelően módosítani szükséges. 41

47 A pontos rendszeridő 52 ismerete és használata egy egészségügyi informatikai 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 a HIS 53 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. B B B B B Az egészségügyi informatikai rendszerekben 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 hálózati aktív eszközök, szerverek, kliensek és minden alkalmazás időszinkronizálásának megoldását. Megoldásszállítónak be kell mutatnia, hogy hogyan, milyen módon és milyen gyakorisággal kerül megvalósításra a HIS szerver, adatbázis kezelő szoftver és az HIS alkalmazások belső órájának szinkronizálása. 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. Interneten keresztül szabványos protokoll segítségével kell az időszinkronizálást megvalósítani. B 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 eljárások időszakára) minden szöveges kommunikáció legyen nyelvtanilag helyes, az adott nyelv karakterkészletét szabályosan jelenítse B meg. Alapértelmezésben minden esetben magyar nyelvű kezelői felültetet kell biztosítani a működtetéshez. További nyelvi felület megengedhető, de a magyar nyelvű felület hiánya csak előzetes kétoldalú megegyezés esetén engedhető meg. A rendszer minden eleme kezelje helyesen a magyar nyelvi előírásokat (pl. B névsorba rendezés) és a magyar ékezetes karaktereket mind a képernyőn mind a nyomtatásban. A rendszer minden funkcionális nyomtatási igényeit ki tudják szolgálni és csatlakoztathatók legyenek a magyar piacon kapható standard nyomtatók B (lézer, mátrix, etikett, karszalag, stb.). A nyomtatók rendszerhez illesztésének ne legyenek speciális igényei. A rendszergazdai felületeknél törekedni kell a magyar nyelv használatára, de B előzetes kétoldalú megegyezés esetén megengedett az idegen nyelv (javasolt az angol nyelv) használata is. Minden oktatás nyelve alapértelmezés szerint magyar legyen. További B nyelveken történő oktatást előzetesen egyeztetni szükséges. 52 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. 53 Heltcare Information System Egészségügyi Informatikai rendszer 42

48 B A felhasználói dokumentációk nyelve magyar. A rendszergazdai dokumentációknál is törekedni kell a magyar nyelvű B verzióra, de indokolt esetben előzetes kétoldalú megegyezés esetén megengedett az angol nyelvű dokumentáció is. A projekt dokumentumok hivatalos nyelve magyar kell, hogy 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 meghatározó dokumentumok hivatalos magyar B 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) 54 B A megajánlott rendszer felhasználói felületének a nyelve legyen állítható. B A megajánlott rendszer nyelvi beállítottsága egyes felhasználóhoz, vagy felhasználó csoporthoz 55 legyen kapcsolható. B 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 B teljes körűen megfelel a megajánlott egészségügyi munkahelyre 56 vonatkozó magyar jogszabályi előírásoknak és az aszerinti működésnek. B A szoftvernek alkalmasnak kell lennie a működési és finanszírozási gyakorlatnak megfelelő: B o szervezeti struktúra leképezhetőségére a szoftver telepítése, paraméterezése és megjelenése során. o törzsadattárak idősoros kialakíthatóságára o közhiteles kódszótárak és nyilvántartások B o finanszírozással kapcsolatos kódtörzek o ráépülő nyilvántartások o intézet és szakmaspecifikus kódtörzsek. B o Ellátás biztosító személyek személyes és szakmai adatainak rendszerbe történő rögzíthetősége idősorosan. B o Páciens törzsadatok rögzíthetősége. B o Ellátó egységek adatainak rögzíthetősége o alap adatok (pl: cím, megnevezés, finanszírozási szerződés adatai,stb.) o eszköz adatok (pl: gyártó, típus, eszköz darabszáma, életkora, elvégezhető vizsgálat típusa, stb.) o ellátó személyzet adatai (név, azonosítók, szakmai végzettség, beosztás, stb.) o erőforrás ütemezési adatok. B o Szabványos regionális és ágazati szintű működés és kommunikáció kialakíthatósága 57. o Az ellátás folyamata során a magyar szakmai, működési és B finanszírozási gyakorlatnak megfelelő dokumentációs rend kialakíthatósága (Az intézményi folyamatok követése és támogatása). 54 Részletesen lásd A fejlesztés előkészítésének tervezési feladatai és módszerei 55 Eurorec: GS Alapellátás, praxisközösség, ambulancia, szakrendelő, fekvőbeteg ellátás, krónikus ellátás, egynapos sebészet, stb. illetve ezek vegyesen. 57 Részletesebben lásd a Kooperatív tér koncepció ismertetésénél. 43

49 B B B B B B B o Működéssel kapcsolatos automatikus lekérdezések definiálhatósága és ütemezhetősége- Az informatikai szállító által leszállított rendszernek minden olyan modulja rendelkezzen szoftver akkreditációval, ahol ezt törvény előírja (pl: receptíró alkalmazás) 58. A szállított szoftverekre a szerződés teljes időtartamára szóló díjmentes 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épernyők módosítása, a képernyők helpjéhez tartozó kódszótárak megjelenítése, adatbázis felépítés módosítása,, adatküldés formátumának megváltozása, ). A jogszabályváltozások miatti módosítást abban az esetben is térítésmentesen kell 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ő 5 munkanappal előbb 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 legkésőbbi 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 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 adatok a jogszabályi előírásoknak megfelelően díjmentesen visszakereshetők legyenek. Az ajánlatban részletes leírást kell a megvalósítás módjáról adni /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, regionális vagy területi egészségügyi ellátó rendszer,stb. 59 Jelenleg 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 l a szerződés megszűnése után a szervereken tárolt alkalmazásokat virtualizált környezetbe kell áttelepíteni és a működését garantálni. 44

50 B Működtetéssel kapcsolatos dokumentáció B B B B Az átadás-átvétel során minimálisan az alábbi rendszergazdai dokumentumokat kell átadni olyan részletezettséggel, hogy egészségügyi intézmény szakemberei a dokumentáció alapján az üzemeltetési feladatokat el tudják látni 60 : o Logikai rendszerterv o Fizikai rendszerterv o Működési folyamat és kommunikációs leírások B o Adatbázis szerkezet leírás 61 B o Interfész specifikációk 62 B B o Funkcionális tesztelési terv és annak eredménye o Terheléses tesztelési terv és annak eredménye B o Mentési visszaállítási terv 63 B o Telepítési és paraméteresési útmutatók 64 B o Felhasználói kézikönyvek B o Üzemeltetési kézikönyv és szolgáltatási szint leírás B o Informatikai biztonsági szabályzat o Migráció leírás (Mely adatok és dokumentumok milyen kiegészítő B adatokkal, milyen ellenőrzés után lettek a régi rendszerből az új rendszerbe beemelve. A régi és az új adatok megfeleltetésének módja.) B o A Megrendelő szervezet installációs és konfigurációs tevékenységeire vonatkozó kézikönyv B o Az illesztett rendszerek illesztési protokolljának leírása 65, a működés elképzelt folyamatleírása. B o Távoli menedzsment kialakításának paraméterei (honnan, ki, milyen protokollal, milyen címről, mit szeretne elérni, mit szeretne csinálni ) B o Felhasználói kézikönyv (modulonként) B o Vészhelyzeti működési szabályzat B o Az üzemeltetési szabályzat feladatlistájának részletes összeállítása 66 B o Minőségellenőrzési jegyzőkönyvek B o Megvalósítási dokumentáció 67 B o Változáskezelést rögzítő dokumentáció mely a projekt teljes életszakaszában vezetendő dokumentum Eurorec: GS GS 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. 62 Részletesen lásd Architekturális követelmények Általános architekturális követelmények A.1 63 Részletesen lásd Architekturális követekmények - Mentési, archiválási, visszatöltési követelmények A.2 64 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. 65 Lásd az archuterturális követelmény leírásoknál megfogalmazottak 66 Ez az egészségügyi intézmény és az Ajánlattevő közös feladata. 67 Ennek a dokumentumnak tartalmaznia kell a rendszer minden állítható paraméterének éles induláskori értékét 45

51 B B 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 működtetési feladatokat el tudja végezni 69. 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 Ez az egészségügyi intézmény és az Ajánlattevő közös feladata. 69 Eurorec: GS A.3 70 Az elvárásokat lásd az oktatási elvárások megfogalmazásánál 46

52 B.1.2 Intézményközi rendszerszolgáltatások általános és specifikus követelményei B A Kooperatív Tér A Kooperatív Tér 71 kifejezés egységes irányelvek szerint működő ágazati információs környezet kialakítását jelenti. Ezt hívhatjuk egységes előírások alapján kialakított egészségügyi ágazati információ-továbbító és feldolgozó informatikai közműnek is. A kooperatív tér szereplői az egészségügyi ágazat intézményei által működtetett informatikai rendszerek, valamint csatlakozó külső rendszerek (ellátottak, civilek, más ágazati szereplők) Irányítás tere - A tér Kooperatív tér - B tér Publikus tér - P tér Ellátás tere - C tér B A Kooperatív tér szerkezete A továbbiakban az alábbi elnevezéseket fogjuk használni: az Irányítás terét a továbbiakban A térnek nevezzük Itt kapnak helyet az irányítást végző szervezetek és az egészségügyet szervező intézmények szolgáltatásai, nyilvántartásai (pl.: EEKH, OEP, ANTSZ, GYEMSZI, stb.). Ebben a térben biztosítani kell az egyes irányítási rendszerek adat transzformációját és beilleszthetőségét. a Kooperatív teret a továbbiakban B térnek nevezzük A B tér zárt, a benne megvalósított funkcionalitás csak belső erőforrásokra támaszkodhat. Ebben a térben valósul meg valamennyi szolgáltatás, amelyeket a többi tér vesz igénybe (információ transzfer, lekérdezés, központi nyilvántartás kezelés stb.), 71 A Kooperatív tér koncepció ismertetésénél alapdokumentumként szolgált a Gyemszi által elkészíttetett Kooperatív tér koncepció című anyag nyilvánosan ismertetett változata és a HCeXpert Kft. előadásaiban elhangzottak, valamint a publikált értelmező előadások. 47

53 vagyis a tér a többi részről leválasztott módon ágazati szintű funkciókat valósít meg. A B tér tárolt információk, funkciók és eljárások tekintetében hitelesnek minősül. az Ellátás terét a továbbiakban C térnek nevezzük Itt kapnak helyet az ellátást végzők. Itt kell tudni közös platformot teremteni és megjeleníteni az ellátási eseményeket leíró adatok megosztásához szükséges elemeket. A C térben kell kialakítani azokat a technológiai megoldásokat, amelyek biztosítani tudják a B térhez való logikai szintű kapcsolódást, az ehhez tartozó fizikai funkcionális kapcsolódáson keresztül. Az egészségügy számára informatikai szolgáltatásokat kínáló külső szereplők által nyújtott ágazati szinten felhasználható komponenseket P (publikus tér) térnek nevezzük (ellátást végzők, a C tér informatikai rendszereinek szállítóit nem ide soroljuk). Ebben a részben helyezkedik el a külvilág számára nyújtani kívánt online szolgáltatások is (pl. a páciensek számára elérhető információk). Az operatív programok megvalósítása során létrejövő A, B, C és P terek együttműködő infrastruktúrát és technológiai környezetet építenek, emellett egységes formai szabályokat, módszertani előírásokat alakítanak ki a jövőbeli szabványos ágazati és szakmapolitikai működéshez. A Kooperatív Tér működésének egyik legfontosabb jellemzője, hogy megtartja a korábban kialakított informatikai rendszerek autonómiáját, ám azok összekapcsolhatóságát és a közöttük történő kommunikáció szabályozását egy részletesen definiált eszközrendszer segítségével valósítja meg. Ahhoz, hogy a Kooperatív Térben szereplőinek a rendszerei képesek legyenek különböző mértékű interoperabilitásra, szabványos adatentitások rendszerének kialakítása és az entitások kapcsolatainak feltárása szükséges. A Kooperatív Tér magába foglalja az előzőekben meghatározott entitásokból álló közös és közhiteles adat szótárakat, nyilvántartásokat. Megfogalmazhatók, definiálhatók a kapcsolattartást az adatáramlást és az adatgyűjtést rendező szabályok és eljárások. Definiálhatók eljárások, validálási szabályok, kialakíthatók közös katalógusok, eseményeket leíró állományraktárak. A Kooperatív Tér létrehozásával közös, egységes elven felépülő platformra terelődik a jelenleg sokféle adattovábbítási formátumot és állomány típust felvonultató egészségügyi informatikai adattovábbítás rendszere. Az ellenőrizhetőség az egységes elvek szerinti naplózhatóság és átláthatóság előfeltétele az egységesítés. Az egységesen definiált és értelmezett fogalmi definíciók és adatkörök segítségével leírhatók és megvalósíthatók az adatokon végzett műveletek 72, így közös platform teremtődik meg az egészségügyi ágazat informatikai támogatására. Mivel a jelenleg működő különféle gyártó által megvalósított rendszerektől nem várható el hogy belső struktúrájuk rövidtávon is átalakuljon, így azok továbbra is önálló elemei 72 műveleteken az adatokon végrehajtott konverziókat, felbontást, összefűzést stb. értünk. 48

54 maradnak az informatikai környezetnek. Ellenben a kooperatív térhez történő kapcsolódás megteremtése a rendszerekkel szemben rövidtávon elvárásként a fogalmazódik meg. B A Kooperatív tér egyszerűsített felépítése Üzenet kezelés Ágazatspecifikus szolgáltatások Általános szolgáltatások Üzenet-kezelés ellenőrzés (validálás) Minimálisan három szintje különböztethető meg: 1. formai validáció: A formai validáció során a kommunikációs állomány formailag kerül ellenőrzésre. Ennek során ellenőrzésre kerül: a specifikációnak való formai megfelelése, (az üzenet megfelelő szerkezetű: pl. XML állomány XSD alapú validációja, CSV állomány szerkezete megfelelő-e) a metaadatok teljessége és helyessége az üzenet-azonosító egyedisége a beküldő esetleges jogosultsága 2. első szintű tartalmi validáció: ennek során az állomány, mint önálló, zárt egységet vizsgálva annak belső szemantikai szabályai kerülnek ellenőrzésre. Ez a lépés csak az adott jelentésen belüli adatokat ellenőrzi egy szabálybázis alapján, nem végez konzisztencia-vizsgálatot más jelentésekkel. 3. részletes validáció: ez az állomány teljes körű validálását tartalmazza, beleértve az előzmény-jelentésekkel, vagy más típusú jelentésekkel történő összevetését, a köztük lévő konzisztencia vizsgálatát, illetve a jelentés címzettjének belső adataival történő összevetést. feldolgozás A téren áthaladó üzenetek központi ellenőrző és irányító funkcióit látja el. Az üzenet feldolgozó egyik speciális része a Központi Validátor, ami a jelentések ellenőrzését ellátó komponens melyet már fentebb már említettünk. 49

55 Általános tér-szolgáltatások authentikáció, authorizáció 73 logolás 74 Ágazati szolgáltatások Közhiteles adatok szolgáltatása A közhiteles és közcélú adatok, illetve az egyes rendszerek működtetéséhez kapcsolódó nyilvános adatok publikálása mely minimálisan az alábbi adatkörökre terjed ki: használt kódtáblák, kódrendszerek hozzáférés biztosítása a közhiteles és közcélú nyilvántartások releváns adataihoz adatok és funkciók specifikációi és egyéb leírások: eljárásrendek fogalomtár jelentések specifikációi szolgáltatások specifikációi metamodellek validálási szabályok Eseménykatalógus A katalógus lehetőséget teremt arra, hogy a benne tárolt adatok birtokában központi adatfeldolgozó, nyilvántartó és országos hatáskörű informatikai szolgáltatások épüljenek ki az egészségügyi ellátás javítása és szervezésének hatékonyabbá tétele érdekében. Az információk alapján elemezhetők az ellátás folyamatai térségi és országos szinteken, az információk statisztikai feldolgozásával pedig mérhetővé, monitorozhatóvá válik a teljes működés. EHR tároló Az eseménykatalógus létrejötte megteremti az alapjait a központi betegútkövetésnek. Az eseménykatalógus által gyűjtött ellátási eseményekhez szabványos EHR (Electronic Health Record) struktúrákban hozzákapcsolódhatnak az adott eseményekhez tartozó adminisztratív és egészségügyi adatok (dokumentumok), ezáltal megteremtődik az a kapcsolatrendszer, amelynek révén egy-egy beteg egészségügyi életútja informatikailag követhetővé válik. Erőforrás allokációs rendszerek (ebeutaló, Intézményközi szolgáltatáskérésválasz) Olyan beutalási és erőforrás-kiajánlási és -allokációs alrendszer, amelynek célja a beutalók, intézményközi előjegyzések és időpontfoglalások kezelése, és a területi ellátási kötelezettségnek való megfelelés és a rendelkezésre álló kapacitások nyomon követése. erecept A jelenleg csak papír alapon létező recept alapján készülő olyan elektronikus bejegyzés, amely mindazokat az adatokat tartalmazza elektronikus formában amelyek a papír alapú recepten is megtalálhatók Regiszterek 73 Részletesen lásd a szószedetben. 74 A rendszerek üzemelése, működtetése közben használt és a működés kapcsán képződő napló-fájlok kapják ezt a filetípus kiterjesztést. Általában közönséges txt formátumban készülnek és paraméterezhető módon minden fontosabb eseményt feljegyeznek. Ezen állományok rendszerbiztonsági, működtetési és működésfolytonossági szempontból is nagy jelentőséggel bírnak. 50

56 Az egyes orvosi szakterületek számára gyűjtött és feldolgozott információs adatbázis. Az online adatfeldolgozás során előállnak a regiszterek számára továbbítandó pszeudonim adatok. Az egészségügyi események központi tárolásának segítségével, az eseménykatalógusba integráltan kialakulnak a szakregiszterek számára történő adatgyűjtés adatleírói. Az online adatgyűjtés során az egészségügyi események részeként előállnak a regiszterek számára továbbítandó pszeudonim adatok. Digitális képtovábbítás és képtárolás A digitális képtovábbító rendszer az általános egészségügyi dokumentáció elérési eszközökre és folyamatokra épül és további kiegészítő képességekkel rendelkezik. Távkonzílium és csoportmunka támogatás A Kooperatív Térben az intézmények között lehetségessé váló információmegosztás technikai hátterének kialakítása lehetővé teszi két vagy több orvos együttműködését. Digitális önrendelkezés Az egészségügyi adatok felhasználására és a kezelőorvosok számára biztosított betekintési jogosultság mértékének korlátozására létre kell hozni az állampolgárok számára felhasználható digitális önrendelkezést megvalósító megoldás. A fentiek alapján összefoglalásul megállapíthatjuk, hogy a Kooperatív tér egységes ágazati szolgáltatásrendszert hoz létre minőségileg új megoldásokat hoz létre ezeknek meg kell teremteni a környezetét (szervezeti, jogi, technológiai, stb.) több projektben jön létre ezt kezelni kell a jövőben üzemeltetni és fenntartani kell létrehozása nem pusztán informatikai projektek B A Kooperatív tér kialakításával kapcsolatos általános követelmények Törekedni kell arra, hogy a Kooperatív térben a egészségügyi ágazat B információs kommunikációja minél teljesebb módon megjelenjen. Az ágazati ehealth fejlesztések kapcsán megvalósuló Kooperatív Tér szolgáltatás hardver elemeinek és alkalmazásainak ki kell tudnia szolgálnia B az ellátó intézmények és az ágazatirányítás szereplői közötti ún. vertikális adatcserét valamint az ellátórendszer intézményei közötti, ún. horizontális adatkommunikációt is. Igen magas rendelkezésre állású megoldásként folyamatosan biztosítsa a B szolgáltatásai elérhetőségét Kialakítása kapcsán az Általános architekturális elvárások részbe leírtak B mérvadók. B A Tér szolgáltatásai igen gyors válaszidőt kell, hogy biztosítsanak. B A térben tárolt információk kereséséhez biztosítson gyors válaszidőt (a 51

57 B B B B B B B B B B B B B B B B keresési szolgáltatásokat hatékony indexelési megoldásokkal támogassa) A kereshetőség támogatásához biztosítson minél több szűrési lehetőséget, hogy minél relevánsabb információkkal láthassa el a szolgáltatást igénybevevőt A személyes adatok tárolásával kapcsolatban biztosítson támogatást az osztott felelősségű pszeudonimizációs eljárásra A tér infrastruktúra szolgáltatásokat is biztosítson. Az infrastruktúra szolgáltatások használata a tér minden komponense számára legyen kötelező. A Kooperatív Teret minden alkalmazásra és annak minden szereplőjére kötelező érvényű szabályoknak kell leírnia. A szabályok terjednek ki az A, B, C és P térben elhelyezhető hardver és szoftver komponensek: felépítésére, működésére, kapcsolattartására, külső alkalmazások kapcsolódásának módjára, Egyedi szabály rendszert kell készíteni a tér: üzemeltetésének rendszerére karbantartási eljárásaira szoftver komponenseinek és paraméterezésének mentésére, arciválására A térben csak az előírásoknak és a szabályoknak megfelelő (lehetőség szerint szabványos) hardver és szoftver komponensek helyezhetők el a tér teljes életciklusában. Kötelező érvényű szabályokban kell előírni a tér interoperabilitásának megőrzését. Különös tekintettel a további informatikai fejlesztéseinek tekintetében. A későbbi fejlesztéseknek úgy kell elkészülnie, hogy a már működő korábbi rendszerekre épüljenek. A térhez külső rendszerek (beleértve az ágazatirányítás rendszereit is) interfészek felhasználásával csatlakozzanak. A Kooperatív tér határfelülete legyen felkészítve a belépés irányban a tér biztonságának megteremtésére és a nem feldolgozható tartalmak bejutásának megakadályozására, a kilépési irányban a kikerülő információk ellenőrzése, naplózása, jogosulatlan információtartalom kijutásának megakadályozása. Az interfészeken csak a Kooperatív Tér szabályainak megfelelő kétirányú kommunikáció legyen megengedett. Az alkalmazásoknak meg kell felelniük a tér szabályainak. A kapcsolódó rendszerek, alkalmazások közvetlenül vagy valamilyen csatoló rendszer segítségével is megvalósíthatják a térbeli kommunikációs szabályokat. A Kooperatív Tér a külső alkalmazásokkal történő kapcsolattartásra partnerenként biztosítson privát tároló területet. Az ágazati közművekhez való kapcsolódás a B téren keresztül kell, hogy megtörténjen (pl.más ágazathoz tartozó hasonló funkcionalitású rendszer). A tér infrastruktúra autentikációs szolgáltatása legyen képes a szervezetek és a felhasználók azonosítására is. Az azonosítás történhessen egyszeres vagy 52

58 B B B B B B B B B B többszörös azonosítással is 75. A Kooperatív Térben legyen mód a tér szereplőinek természetes és térbeli tulajdonságainak, attribútumainak leírására, idősoros tárolására. Törekedni kell arra, hogy az autentikációt az elektronikus közigazgatásban már létező azonosítási rendszer felhasználásával kerüljön megvalósításra. A jogosultságkezelés kialakítása során definiálni kell a funkcionális és az adatszintű hozzáférés-korlátozáshoz szükséges szabályokat és azok nyilvántartását. A digitális hitelesítés támogatás során a már meglévő ágazatközi közműveket kell igénybe venni (digitális aláírás, titkosítás és időpecsét). A térben zajló műveletek naplózását egységes infrastruktúra szolgáltatásként kell kialakítani az auditálhatóság érdekében 76. A Kooperatív tér bővíthető módon legalább két típusú portálszolgáltatás kiszolgálására legyen felkészítve: szakmai portál az ágazat szereplői részére (csak a megfelelő jogosultságokkal rendelkezők érhessék el) nem szakmai portál a nem szakmai felhasználók informálása) A Kooperatív Tér rendelkezzen olyan teljesítményű automatikus üzenet feldolgozó rendszerrel (AMPC 77 ) amely képes minden üzenetet feldolgozni, ellenőrizni majd továbbítja, illetve hibaágra tereli azokat. A kialakításra kerülő eszközrendszer tegye lehetővé, hogy létrejöjjön egy ellátók közötti szolgáltatáskérés és válasz rendszer, ennek révén mind a kérések, mind a létrejött eredmények adatainak egységesített továbbítása. A kialakításra kerülő eszközrendszer tegye lehetővé, hogy létrejöhessen egy olyan beutalási és erőforrás-kiajánlási és -allokációs alrendszer, amelynek célja a beutalók, intézményközi előjegyzések és időpontfoglalások kezelése, és a területi ellátási kötelezettségnek való megfelelés és a rendelkezésre álló kapacitások nyomon követése. A kialakításra kerülő eszköz és alkalmazások interoperabilitás rendszere tegye lehetővé, hogy az ellátások során képződő digitális képi leletek továbbíthatók legyenek. Ez a megoldás igényli és feltételezi az ellátóknál meglévő PACS rendszerek közötti részben automatizált, részben támogatott adatátadás megvalósítását. B A Kooperatív téren belül megvalósuló alkalmazásokkal kapcsolatos követelmények Az üzenetek küldésére és fogadására vonatkozó képességek megteremtésével B nyíljon lehetőség az infrastruktúra szolgáltatások fölötti magasabb szintű szolgáltatások megvalósítására. A központi rendszer felé feladott egészségügyi események regisztrálásával B váljon nyomon követhetővé egyrészt az intézményen belüli, másrészt az ellátórendszeren belüli betegút. B A központi rendszer képes időrendben eltárolni az egészségügyi 75 pl: egy szervezet eltérő szoftver alkalmazásai különböző módon lehetnek felkésztve a kommunikációra, ezért ezeket más-más módon kell autentikálni. 76 Itt nem a technikai szintű naplózásra kell gondolni! 77 Automatic Message Processing Center (automatikus üzenet feldolgozó rendszer) 53

59 B B B B B B B B B B B B B B B B B eseményeket egy ún. eseménykatalógusba. Az esemény katalógus segítségével kiszolgálhatók legyenek a korábbi vizsgálati eredményekre vonatkozó keresések, illetve megteremthető legyen az egészségügyi adatok historikus tárolása. Az esemény katalógus teremtsen lehetőséget arra, hogy ezen adatok birtokában központi adatfeldolgozó, nyilvántartó és országos hatáskörű informatikai szolgáltatások épüljenek ki. A központilag kezelhető információk alapján legyenek létrehozhatók olyan orvosszakmai információbázisok, amelyek alapján elemezhetők legyenek az ellátás folyamatai térségi és országos szinteken. A központilag kezelhető információk alapján az információk statisztikai feldolgozásával váljanak mérhetővé és monitorozhatóvá a működés adatai. Az ágazati ehealth fejlesztések teremtsék meg a digitális önrendelkezés megvalósításának feltételeit. Az eseménykatalógushoz integráltan ki kell alakítani a szakregiszterek számára történő adatgyűjtés adatleíróit és komponenseit. Olyan egészségügyi informatikai eszközök kifejlesztésére kerüljön sor, amelyek képesek javítani a lakosság egészségtudatosságát és egészségügyi információval való ellátottságát. Az eseménykatalógus legyen felkészítve arra, hogy a Kooperatív Térbe érkező minden egészségügyi esemény, illetve mozzanat tárolására. Az eseménykatalógus képes legyen kiszolgálni eseményszintű adatokkal a térben létrejövő adattárházakat. Az eseménykatalógus nyújtson szolgáltatásokat az események kereshetőségére, tegye lehetővé az eseményekhez tartozó metaadatok kezelését és tárolását Az eseménykatalógus nyújtson szolgáltatásokat a betegek digitális önrendelkezéséhez Az eseménykatalógus nyújtson szolgáltatásokat az ellátást végzők kooperációjához A kifejlesztésre kerülő alkalmazások működtetéséhez ki kell dolgozni azokat a tartalmi leíró szabályokat (archetípusokat), amelyek az egyes dokumentumtípusok belső szerkezetét és részletezettségét kötelező jelleggel. Meg kell oldani a szabványos üzenetek gépi feldolgozhatóságát. Meg kell határozni az egyes dokumentumtípusok tartalmi előírásait. A kifejlesztésre kerülő alkalmazások megvalósítása kapcsán olyan szolgáltatási felületeteket is kell fejleszteni, amely a tárolt szabványos EHR szerkezetek hatékony gépi kezelését biztosítja. Ki kell dolgozni a kifejlesztésre kerülő alkalmazások kötelező bevezetésnek a menetrendjét. 54

60 B.1.3 Üzenetkezelés B A Kooperatív Tér üzenetkezelésével kapcsolatos általános követelmények B B B B B B B B B B B B Törekedni kell arra, hogy a Kooperatív térben a szereplők üzenetek formájában, a felhasználáshoz szükséges mértékig el tudják juttatni egymáshoz az információkat. A térben üzenetek a további felhasználáshoz szükségesen önállóan nem tárolódhatnak 78 Az üzenetek mozgása teljes körű követése és adminisztrálása automatikusan valósuljon meg. A tér az üzenetek közvetítését kösse megfelelő módon definiált és publikált alaki, formai feltételekhez A térnek garantálnia kell (garanciát kell vállalnia) a megfelelő módon kialakított (alaki, formai feltételeknek megfelelő) üzenetek célba juttatására. A tér pontos definícióval rendelkezzen arról, hogy mely üzenetek tekinthetők érvényesnek. Az üzenetek a Kooperatív térben aszinkron módon, egymástól független tranzakcióként, egyedi üzenet- és eseményazonosítóval ellátva legyen ellátva a feldolgozás, továbbítás során. Az üzenetek legyenek strukturáltak, tartalmi szempontból több szintre bonthatók. Az üzenetek leképezése XML formában történjen. Minden üzenettípus legyen definiálva a működéshez szükséges metainformációkat is figyelembe véve. A mindenkor érvényes üzenet típusok ősosztályként (mintaként) a szakma szabályai szerinti formátumban, idősorosan legyen elérhető a tér szakmai felhasználói számára. Az üzenetek elvárt struktúrája: fejléc adminisztrációs leírás címzés 79 két szintű tartalom leíró metaadatok o a külső leírók 80. o belső metainformációk 81 B.1.4 Intézményközi technológiai protokollok követelményei B Interoperabilitás Az interoperabilitás kifejezés az informatikában rendszerek közötti együttműködési képességet jelent. Az interoperabilitás nem azonos a(z) integrációval Pl. logok formájában tárolódhatnak 79 a feladó és a címzett azonosítását szolgálja 80 a tartalomtípusra vonatkozó jellemzők melyek a kezeléshez és továbbításhoz szükséges információkat tartalmazzák 81 a transzformációs leírásokat tartalmazó rész 55

61 kompatibilitással 83 adaptálhatósággal 84 Az együttműködés különböző szinteken valósulhat meg. A megvalósítástól függően szeretnénk az interoperabilitás használatával kapcsolatos kifejezéseket tisztázni, pontosítani. A tisztázáshoz ebben a témában írt magyar nyelvű egészségügyi informatikával foglalkozó szerzők szakmai anyagokat hívtunk segítségül Az interoperabilitás szintjei Nincs interoperabilitás (No Interoperability) Önálló rendszerek együttműködés nélkül. 2. Technikai interoperabilitás (Technical Interoperability) Technikai interoperabilitásról általában az adatcserét megvalósító átviteli közeg kommunikációs összehangoltsága esetén szoktunk beszélni. Az átviteli közeg sok rétegből áll. Talán a legalapvetőbb szintje az alap szintű működést biztosító számítástechnikai infrastruktúra interoperabilitása. Ezt követik a legkülönbözőbb titkosítási, adatvédelmi szoftverek (pl. tűzfalak átjárhatósága) együttműködő képességének megléte. Ebbe a kategóriába tartoznak például a fájl név és típus képzési szabályok specifikálása az állományok méretkorlátozásával kapcsolatos megszorítások valamint az egységes karakterkódolás is. 3. Szintaktikus vagy funkcionális interoperabilitás (Syntactic Interoperabulity) Itt már szorosabb a kapcsolat a rendszerek között. Erről a szintről akkor beszélhetünk ha két vagy több rendszer rendelkezik azzal a képességgel, hogy egymás között adatot tudnak cserélni. Tehát a továbbított adatok, információk mindkét oldalon értelmezhetők legyenek, ha másként nem legalább ember számára olvasható formában jelenjenek meg. Ez a szint már feltételezi az egységes módon kialakított üzenetek csomagolásának módját, a komplex struktúrák részeinek jelölését. Egy XML alapú adatcsere esetében maga az XML szabvány jelenti az interoperabilitás ezt a szintjét. 4. Szemantikus interoperabilitás (Sementic Interoperability) Akkor beszélhetünk ennek a szintnek a megvalósulásáról, amikor a rendszerek az üzenetekbe csomagolt adatokat formálisan definiált fogalmak szintjén értelmezni tudják a maguk komplexitásában. Tehát a megosztott információ számítógép által értelmezhető és feldolgozható a fogadó oldalon. Erre példa a szabványos módon kialakított HL7 86 v3 XML alapú adatcseréje. 5. Pragmatikus interoperabilitás (Pragmatic Interoperability) Abban az esetben beszélünk e szintről, ha a kapcsolt rendszerek nem egyszerűen arra képesek, hogy az üzenetek tartalmát értelmezzék, de a hatásukra kiváltott eljárásokat is figyelembe veszik a kommunikáció során. 82 Integráció Szorosabb kapcsolatot jelent két rendszer között 83 Kompatibilitás - Inkább az eszközök csereszabatosságánál szoktuk használni ezt a kifejezést 84 Adaptáció - egy eszköz megváltoztathatóságára szoktuk használni, plusz képességek hozzáadásával 85 www imeonline hu/article/ / pdf. ( 86 A HL7 v3 szabványról pont a szemantikus interoperabilitás problémakörének megoldását tűzte zászlajára. 56

62 Példa: egy beteg felvétele a fekvőbeteg osztályra a betegadminisztrációs rendszerben (HIS-ben) kivált olyan HL7 üzenet küldését 87 egy konkrét másik rendszer felé, mert a kommunikáció paraméterezésekor ismert volt, hogy a kórházban használt konkrét másik rendszer (pl. labor rendszer) rendelkezik önálló betegadatbázissal, tehát szükséges a regisztráció adatait átadni a másik rendszernek, azért mert ezáltal a későbbi vizsgálatkérés és leletezés folyamata felgyorsul. 6. Dinamikus interoperabilitás (Dynamic Interoperability) Akkor beszélünk erről a magas szintű együttműködésről, ha az összekapcsolt rendszerek az egymás közti adatcserében figyelembe veszik az egyes nyilvántartott adatoknak, dokumentumoknak az állapot-változásait. 7. Koncepcionális interoperabilitás (Conceptual Interoperability) Az interoperabilitás legmagasabb szintjén nem csak a rendszerek közti adatcsere tartalma, a feldolgozó eljárások, az életciklus fázisai, de a rendszerek koncepcionális tervei és adatmodelljei is egyeztetésre kerülnek és kialakításra kerül egy végrehajtás függetelen adatmodell ( fully specified, but implementation independent model ). Másként is lehet kategorizálni az interoperabilitás szintjeit 1. Integrálható (Integratability ) Azt jelenti, hogy igazából csak fizikai/technikai infrastruktúra áll rendelkezésre egy adott rendszernél, de a tényleges interoperabilitás nincs megvalósítva. A Technikai és a Szintaktikus interoperabilitás kritériumait teljesítő rendszerek tartoznak ide. 2. Interoperábilis (Interoperability) Az ilyen rendszerek képesek egy bizonyos keretek közt egymással interoperábilis módon kommunikálni, de maximum csak a Szemantikus interoperabilitás kritériumait teljesítik. Ide tartozik a Pragmatikus és a Dinamikust interoperabilitás is). 3. Kompatibilis (Composability) Az ilyen rendszerek képesek minden tekintetben egymással csereszabatosan kommunikálni. A kompatibilis rendszerek minimális szintje a Koncepcionális interoperabilitás. 87 HL7 v3 PRPA_TE201301UV02: Patient registry record added (triggers a PRPA_IN201301UV02 message). 57

63 Adattípusok interoperabilitása Az Interoperabilitás szintjei Az európai és amerikai szabványosítási folyamatok konvergenciájának egyik eredménye a MSZ CEN/TS néven a Magyar Szabványügyi Testület által is átvett CEN technikai specifikáció, mely az egészségügyi informatikában alkalmazandó egységes adattípusokat definiálja. Az ebben a TS-ben (technikai specifikációban) meghatározott adattípusok az amerikai HL7 és az európai alapú szabványok és ajánlások által közösen használt típusok, melyek egységes használata megteremti a különböző megközelítésű rendszerek és alkalmazások közti interoperabilitás alapjait. EHR egységesítése és publikációja 88 Az ellátási dokumentáció standardizálásának kérdésköre két nagy, logikailag egymásra épülő területre bontható: a tartalmi és a formai egységesítés kérdéskörére. A szemantikusan interoperábilis kommunikáció alapvető követelménye a továbbításra kerülő adatstruktúrák formai és tartalmi egységesítése. A szabványokon alapuló megoldások esetében a két szint az implementációban is élesen elkülönítésre kerül: a funkcionális interoperabilitást egy megfelelően kialakított adatmodell biztosítja, mely lehetővé teszi tetszőleges tartalmú és bonyolultságú egészségügyi információ ábrázolását anélkül, hogy az adatmodellen változtatni kellene. a szemantikus interoperabilitást a referencia modell elemeire vonatkozó, formálisan is megfogalmazható tartalmi megállapodások, szabályok biztosítják. Az egészségügyi kommunikációs szabványok esetében a funkcionális interoperabilitást az adatmodellt leíró, ún. referencia modell biztosítja. Ugyanakkor a szabványos üzeneteket alkalmazó kommunikáció önmagában még nem biztosítja az interoperabilitás magasabb, szemantikai szintjét ehhez további, a szabvány elemeire épülő fogalmi és tartalmi egységesítés is szükséges. Ennek eszközei az archetípusok, amelyek a referencia modell építőkövei összerendeződésének egy magasabb szintű előírását biztosítják. 88 Ágazati adatkommunikációs ajánlásgyűjtemény (ESKI) 58

64 B B B B B B B 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 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, proxykkal és behatolásvédelmi, megoldásokkal Legalább peer-to-peer kapcsolat létrehozása a rendszerhez csatlakozott egészségügyi intézmények között A rendszer intézményeinek internetes összeköttetése, az egyes végpontok szélessávú 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, 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 Adatkommunikációs ajánlásgyűjteményben szereplő formátumok (valamelyikének) alkalmazása az MSZ szabvány az irányadó. 59

65 B.1.5 A telemedicina alkalmazásának helyzete Magyarországon, a telemedicina rendszerkövetelményei A telemedicina definíciója sokféle, amely mutatja, hogy a telemedicinával kapcsolatos képzetünk kialakulóban van. Az Egészségtudományi Fogalomtár a következőket mondja: A telemedicina olyan egészségügyi szolgáltatás, amelynek során az ellátásban részesülő és az ellátó személy közvetlenül nem találkozik, a kapcsolat valamilyen távoli adatátviteli rendszeren keresztül jön létre. Máshol a fentieket még általánosabban fogalmazzák meg: minden olyan egészségügyi tevékenység telemedicinának minősül, amelyet nem a beteg jelenlétében végzünk, de kapcsolatba hozható a gyógyítással. 90 A telemedicina tehát alapvetően két rendező ismérvvel jellemezhető: a beteg (vagy mintája) és a vele gyógyító/gondozó/felügyelő tevékenységet ellátó főleg egészségügyi személy(zet) fizikai kapcsolatának hiánya, illetve a fent említett tevékenység biztosítására az info-kommunikációs technológia alkalmazása. A fentiek alapján a telemedicina alkalmazása kettős követelmény-rendszer betartásával lehetséges: a gyógyító/gondozó/felügyelő folyamatok olyan a szakma által elfogadott leírásának megléte, amely során meghatározásra kerülnek azok a rész-folyamatok azon belül is tevékenységek amelyek során az beteggel (mintájával) való fizikai kontaktus elkerülhető, mert létezik, és elfogadott az az info-kommunikációs megoldás, amely az egészségügyi folyamatok által megkövetelt biztonság és bizalmasság feltételeinek megfelelően biztosítja a távoli folyamatok során a gyógyító/gondozó/felügyelő tevékenységek elvégezhetőségét. A jelen pillanatban olyan fejlesztéseknek és alkalmazásoknak vagyunk tanúi, amelyek a fenti követelmény-rendszernek csak részben felelnek meg, mert az orvos-szakmai megalapozó munkát még senki nem végezte el a területen, másrészt a fejlesztések csupán olyan részfolyamatokat fednek le az info-kommunikációs technológiák alkalmazásával, amelyek nem integrálódnak egy-egy komplex egészségügyi folyamatba, mint például a krónikus betegellátási rendszerekbe. Ismert még egy a telemedicina természetéből fakadó bonyodalom is: az ilyen rendszerek sokkal több szereplőt involválnak, mint a hagyományos gyógyító/gondozó/felügyelő tevékenységek esetén. Plasztikus példaként azzal jellemezhetnénk ezt, mintha egy hagyományos ernyőkép felvétel elkészítésekor a tevékenységben részt vennének a röntgen készülék gyártói, a hálózati feszültségért felelős közmű cég emberei is. Látszik, hogy a hagyományos orvos-beteg találkozásnál ezek a szereplők kiesnek bár jelentősen hozzájárulnak a tevékenységhez mert a szerepüket a röntgen-orvos (asszisztens) veszi át. Mindez egy távoli vérnyomás mérések sorozatán alapuló megfigyelő rendszernél sokkal bonyolultabb, hiszen a betegen elhelyezett vérnyomásmérő, a lakásban található hálózati 90 Fekete Judit, Domján Péter, Fekete Tibor: Telemedicina korszerű gyógyítás vagy technikai útvesztő; IME VII. ÉVFOLYAM 3. SZÁM ÁPRILIS alapján 60

66 adatgyűjtő, a kommunikációért felelős szolgáltató, és a központi adatfogadó-feldolgozó elemek mögött olyan szereplők állnak (és szolgáltatnak), akik(amelyek) összehangolt munkát végeznek, és a felelősségi körüket jól meghatározó megállapodás-rendszer biztosítja. B Telekonzultáció, teledignosztika A jelen dolgozatban a telemedicina olyan ágait, ahol az orvosi diagnosztikai és/vagy terápiás tevékenységek történnek meg az infó-kommunikáció segítségével, külön választjuk mindattól az alkalmazástól, amikor a telemedicina a betegre, mint természetes személyre terjed ki. Ezek a telekonzultáció és telediganosztika alkalmazásai, amelyek esetén csak a tevékenység orvos-szakmai megbízhatóságát és bizalmasságát kell biztosítani. A tele-konzultáció a hagyományos orvosi gyakorlatban is régóta alkalmazott eljárás, hiszen orvosok egy-egy esettel kapcsolatosan korábban is folytattak eszmecserét telefonon keresztül. Ma ennek egy jóval kifinomultabb módja is lehetséges, amikor a telekonzultáció során olyan információk is rendelkezésre állnak a konzulensek számára, amelyek korábban nem, pl. képi elemek, hanganyagok stb. amelyeket az infó-kommunikáció biztosítja. Ezekre a rendszerekre vonatkozóan a következő általános követelményeket fogalmazhatunk meg: B B B B B B B B B B A tele-konzultáció során a konzulensek azonosíthatóak legyenek A tele-konzultáció során csak olyan tartalmak használhatóak fel, amelyeket valamennyi konzulens el tud érni. A tele-konzultációról hangfelvétel készüljön A tele-konzultációról készült hangfelvételről írásos dokumentum készüljön, amely a betegdokumentáció részét kell, hogy képezze A tele-diagnosztikát végző orvos azonosítható legyen A tele-diagnosztikánál alkalmazott táv-eljárás a szakma számára elfogadott kell, hogy legyen A tele-diagnosztikai dokumentáció részét kell, hogy képezze a diagnosztika alapját képező beteg-adat (kép, hang stb.) ugyanúgy, mint a diagnosztika szöveges dokumentuma A tele-diagnosztika dokumentációját digitális aláírás és időbélyeg hitelesítse Az üzemszerűen alkalmazott tele-diagnosztikai rendszerek rendelkezésre állása 7/24 kell, hogy legyen Az üzemszerűen alkalmazott tele-diagnosztikai rendszereknél alkalmazott orvosok speciális képzettséggel kell, hogy rendelkezzenek 61

67 B B B B A tele-diagnosztikai rendszerek esetén a beteg-adatok kezelését a hatályos jogszabályoknak megfelelően kell elvégezni A tele-diagnosztikai rendszerek a szakmai területen előforduló szabványos fájl-formátumokat kell kezelniük A tele-diagnosztikai rendszerek az általuk kezelt, dokumentált esetek adatait a hagyományos orvosi eljárásban alkalmazott jogszabályi előírás szerinti ideig meg kell őrizniük, és vissza kell tudni keresniük igény esetén A tele-diagnosztikai rendszer megfelelőségi teszten kell keresztülmennie, és a működéshez szükséges engedélyekkel kell rendelkeznie. B Telemedicina a beteg környezetében A beteggel kapcsolatos telemedicina valamennyi szereplője résztvevője a folyamatnak, vagyis velük szemben követelményeket kell megfogalmaznunk. Mielőtt ezeket összefoglalnánk, meg kell említenünk az orvos-szakma számára megfogalmazandó megkerülhetetlen követelményt: a gyógyító-megelőző tevékenységek protokolljának kidolgozását a lehetséges telemedicinális alkalmazások helyének és szerepének meghatározásával. E nélkül a munka nélkül a telemedicina továbbra is marginális helyet foglal majd el egészségügyi rendszerünkben. B A telemedicina folyamatainak a szakterület orvos-szakmai kollégiuma által elfogadott módon kell az ellátási protokollba beépülnie 62

68 A beteg-közeli telemedicina szereplői és követelményeik Az ábrán szemléltetjük az általános telemedicina szolgáltatás struktúráját szerepkörönként, azt az összefüggés rendszert, amely a hagyományos egészségügyi ellátás kétszereplős modelljét (beteg egészségügyi ellátó) kiegészíti egy többszereplős (négy vagy több) struktúrával, miközben a hagyományos ellátási protokoll egy részlet tevékenységét (folyamatát) valósítja meg. Azt kell nyomatékosítanunk, hogy a telemedicina modell bár bonyolultabb, mint amit megszoktunk az ellátásban mégis a betegellátás egy jól definiált részletét írja le, és a hagyományos ellátási tevékenységet nem fogja sohasem helyettesíteni, szükségtelenné tenni. A betegellátás döntési pontjain továbbra is orvosok állnak, a telemedicina CSAK megalapozottabbá, adekvátabbá teszi döntésüket. A következő részben az egyes szereplőket tárgyaljuk, a velük szemben támasztott követelményeket foglaljuk össze. 63