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

Az ege szse gü gyi informá cio s rendszerek ko vetelme nyei (verzió: C1.0)

Összeállította: a GYEMSZI szakértői munkacsoportja 2013. augusztus

Tartalomjegyzék

TARTALOMJEGYZÉK BEVEZETŐ

1

Előszó

1

Szószedet

4

I. A

EGÉSZSÉGÜGYI INFORMATIKAI PÁLYÁZATOK ÉS PROJEKTEK

10

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.1.1.1 A fejlesztés elhelyezése az intézmény működésében 13 A.1.1.2 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.1.2.1 Beszállítói követelmények 16 A.1.2.2 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.1.3.1 A fejlesztés előkészítésének tervezési feladatai és módszerei 18 A.1.3.2 A Projekt Alapító Dokumentum követelményei 19 A.1.3.3 A fejlesztéssel kapcsolatos szerződés(háló) kialakításának követelményei 20 A.1.3.4 Szoftverszerződésekkel kapcsolatos elvárások 21 A.1.3.5 A fejlesztés megvalósítása követésének követelményei 21 A.1.3.6 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.2.1.1 A fejlesztés elhelyezése az intézmény működésében 23 A.2.1.2 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.2.2.1 Beszállítói követelmények 24 A.2.2.2 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.2.3.1 A fejlesztés előkészítésének tervezési feladatai és módszerei 26 A.2.3.2 A Projekt Alapító Dokumentum követelményei 26 A.2.3.3 A fejlesztéssel kapcsolatos szerződés(háló) kialakításának követelményei 26 A.2.3.4 Szoftverszerződésekkel kapcsolatos elvárások 26 A.2.3.5 A fejlesztés megvalósítása követésének követelményei 28 A.2.3.6 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.3.1.1 A fejlesztés elhelyezése az intézmény működésében 28 A.3.1.2 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.3.2.1 Beszállítói követelmények 28 A.3.2.2 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.3.3.1 A fejlesztés előkészítésének tervezési feladatai és módszerei 28 A.3.3.2 A Projekt Alapító Dokumentum követelményei 29 A.3.3.3 A fejlesztéssel kapcsolatos szerződés(háló) kialakításának követelményei 29 A.3.3.4 Szoftverszerződésekkel kapcsolatos elvárások 29 A.3.3.5 A fejlesztés megvalósítása követésének követelményei 29

i

Tartalomjegyzék

A.3.3.6

A fejlesztés eredményének követelményei

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

29

30

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.1.1.1 Bevezetés 31 B.1.1.2 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.1.1.3 Általános architekturális követelmények 34 B.1.1.4 Infrastruktúrális követelmények 36 B.1.1.5 Mentési, archiválási, visszatöltési követelmények 37 B.1.1.6 Biztonságos működéssel-működtetéssel kapcsolatos követelmények 39 B.1.1.7 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.1.2.1 A Kooperatív Tér 47 B.1.2.2 A Kooperatív tér kialakításával kapcsolatos általános követelmények 51 B.1.2.3 A Kooperatív téren belül megvalósuló alkalmazásokkal kapcsolatos követelmények 53 B.1.3 Üzenetkezelés 55 B.1.3.1 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.1.4.1 Interoperabilitás 55 B.1.5 A telemedicina alkalmazásának helyzete Magyarországon, a telemedicina rendszerkövetelményei 60 B.1.5.1 Telekonzultáció, teledignosztika 61 B.1.5.2 Telemedicina a beteg környezetében 62 B.1.5.3 Betegállapotot (életfunkciót, egészségügyi paramétereket) mérő eszközök 65 B.1.5.4 Szabványosítás. 67 B.1.5.5 Adatátviteli – hálózati technológiák 68 B.1.5.6 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.2.1.1 Tranzakció és eseménynaplózás a HIS rendszerekben 72 B.2.1.2 Az egészségügyi dokumentumok adatvédelmével kapcsolatos adatvédelmi elvárások 73 B.2.1.3 Az alkalmazásokkal kapcsolatos jogosultság kezelés 75 B.2.1.4 ISO OID (Object IDentifier – egyedi azonosító) rendszer használata 76 B.2.1.5 Kódok, kódszótárak, nyilvántartások, szabályok 77 B.2.1.6 Betegadminisztrációs rendszer 78 B.2.1.7 Alapvető járó és fekvőbeteg ellátási funkciók 80 B.2.1.8 Megrendelésekkel kapcsolatos általános elvárások 81 B.2.1.9 Labor kommunikációval kapcsolatos alapvető elvárások 82 B.2.1.10 Dokumentum kezelés (szerkesztés és nyomtatás) 84 B.2.1.11 Statikus és dinamikus űrlapok 88 B.2.1.12 Recept 89 B.2.1.13 Erőforrás ütemezés 91 B.2.1.14 Lekérdező modul 93 B.2.2 A betegfelvétel során elvárt minimális funkcionalitás 94 B.2.2.1 Páciens adatkezeléssel kapcsolatos funkciók 94 B.2.2.2 Előjegyzés, ellátás ütemezés 94 B.2.2.3 Biztosítás, finanszírozás 94 B.2.2.4 Dokumentumszerkesztés 94 B.2.3 A Járóbeteg szakellátás során elvárt minimális funkcionalitás 95

ii

Tartalomjegyzék

B.2.3.1 Páciens adatkezeléssel kapcsolatos alapvető funkciók B.2.3.2 Előjegyzés, ellátás ütemezés B.2.3.3 Biztosítás, finanszírozás B.2.3.4 Ambuláns dokumentumok kezelése (szerkesztés és nyomtatás) B.2.3.5 PACS illesztés B.2.4 A fekvőbeteg szakellátás során elvárt minimális funkcionalitás B.2.4.1 Páciens adatkezeléssel kapcsolatos alapvető funkciók : B.2.4.2 Felvételtervezés, várólista kezelés B.2.4.3 Biztosítás, finanszírozás B.2.4.4 Fekvőbeteg dokumentumok kezelése (szerkesztés és nyomtatás) B.2.4.5 PACS illesztés B.2.5 Az elektronikus kórlaptól és lázlaptól elvárt minimális funkcionalitás B.2.6 Az ápolási dokumentációtól elvárt minimális funkcionalitás B.3 A szakellátás jövőképe B.3.1 Múlt és jövő folyamatai B.3.1.1 Az informatikai rendszerek fejlődése B.3.1.2 Az egészségügyi folyamatok fejlődése B.3.2 Várható fő kimenetek B.3.2.1 Online hálózatok hatása B.3.2.2 Hálózati input pontok bővülésének hatása B.3.2.3 Információ hiányból információ áradatra váltás B.3.2.4 Epizód kezelésből gondozási folyamat kezelésre váltás B.3.2.5 Életmód támogató informatikai rendszerek

III. KÖVETELMÉNYEK AZ EGÉSZSÉGÜGYI SZAKELLÁTÁSI INFORMÁCIÓS RENDSZEREK ÜZEMELTETÉSÉHEZ C

Egészségügyi szakellátási információs rendszerek üzemeltetési követelményei C.1 Üzemeltetési alapkövetelmények C.1.1 Szolgáltatás tervezés C.1.1.1 Szolgáltatás szint menedzsment C.1.1.2 Rendelkezésre állás és a szolgáltatások folytonosságának biztosítása C.1.1.3 Informatikai biztonság menedzsment C.1.2 Szolgáltatás bevezetés C.1.2.1 Változáskezelés C.1.2.2 Kiadás és üzembe állítás C.1.2.3 Konfigurálás C.1.3 Kiadás elfogadása C.1.3.1 Telepítés tervezése C.1.3.2 Ismeret menedzsment C.1.4 Szolgáltatás üzemeltetés C.1.4.1 Incidens menedzsment C.1.4.2 Ügyfélszolgálat C.1.4.3 Probléma menedzsment C.1.4.4 Kérésteljesítés menedzsment C.1.4.5 Hozzáférés menedzsment C.1.4.6 Folyamatos szolgáltatásfejlesztés C.1.4.7 Üzemeltetési szerződésmenedzsment C.2 A szakellátási rendszerek üzemeltetésének ajánlott követelményei C.2.1 Szolgáltatás tervezés C.2.1.1 Szolgáltatás katalógus menedzsment C.2.1.2 Szolgáltatás szint menedzsment C.2.1.3 Kapacitás menedzsment C.2.1.4 Rendelkezésre állás és a szolgáltatások folytonosságának biztosítása

iii

95 95 96 96 96 96 96 97 97 98 98 98 99 101 101 101 101 102 102 103 104 105 106

107 108 108 108 108 110 111 117 117 117 118 118 118 118 118 118 119 119 120 120 121 121 122 122 122 122 124 124

Tartalomjegyzék

C.2.1.5 Informatikai biztonság menedzsment C.2.1.6 A hozzáférés ellenőrzése C.2.2 Szolgáltatás bevezetés C.2.2.1 Szolgáltatási eszköz és konfiguráció menedzsment C.2.2.2 Változáskezelés C.2.2.3 Kiadás és üzembe állítás C.2.2.4 Konfigurálás C.2.2.5 Kiadás elfogadása C.2.2.6 Ismeret menedzsment C.2.2.7 Szolgáltatás validálás és tesztelés C.2.3 Szolgáltatás üzemeltetés C.2.3.1 Eseménymenedzsment C.2.3.2 Incidens menedzsment C.2.3.3 Probléma menedzsment C.2.3.4 Kérésteljesítés menedzsment C.2.3.5 Hozzáférés menedzsment C.2.3.6 Folyamatos szolgáltatásfejlesztés C.2.3.7 Üzemeltetési szerződésmenedzsment

iv

126 129 130 130 130 131 131 131 132 132 132 132 133 134 134 135 135 135

Bevezető

B EVEZETŐ Előszó 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

Egészségügyi információs rendszerek pályázatai és projektjei

Kötelező követelmények

1

Kötelező/ajánlott követelmény, amennyiben specifikus1

Ajánlott megoldás, illetve „best practice”

A projekt, illetve A projektgazdára, a pályázat A projekt pályázati dokumentációra szakterületére lebonyolításának „best és projekt szervezetre vonatkozóan practice” megoldásai kötelező érvényűek specifikus kötelező követelmények

A követelmények specifikus területenként.

1

Bevezető

Kötelező követelmények

Kötelező/ajánlott követelmény, amennyiben specifikus1

B-implementációja

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 egy-egy alkalmazási területen történő implementációnál relevánsak, és kötelezőek

C-üzemeltetése

Egészségügyi információs rendszerek

Normatív követelmények

Olyan követelmények, amelyek valamennyi informatikai rendszer üzemeltetésénél kötelezőek

Olyan követelmények, amelyek valamennyi Nem értelmezett informatikai rendszer üzemeltetésénél ajánlottak

Ajánlott megoldás, illetve „best practice”

Olyan követelmények, amelyek a legjobb megoldásokat eredményezik, illetve ajánlottak az implementáció esetén

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.1B.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

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

Bevezető

Szószedet Adatbázis2: 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ása3 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.

2 3

http://www.nhit-it3.hu/it3-cd/FOGALOMTAR.pdf 223/2009. (X. 14.) Korm. rendelet

4

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

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 finanszírozással kapcsolatban álló szervezet.

a

betegellátással,

népegészségüggyel

és

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ényeknek4 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ények5 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. 4

223/2009. (X. 14.) Korm. rendelet

5

223/2009. (X. 14.) Korm. rendelet

6

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 beavatkozásokhoz kapcsolódó német pontszámon alapuló teljesítményfinanszírozás.

szerint,

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 jelenti6. 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. Middleware7: (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: 2013.3.22.-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

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. XML8 (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

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

Egészségügyi informatikai pályázatok és projektek

I.

E GÉSZSÉGÜGYI

INFORMATIKAI PÁLYÁZATOK

ÉS PROJEKTEK

10


A Követelmények az egészségügyi pályázatokhoz és projektekhez

informatikai

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


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


 é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ényes9 állapotával. A.1.1 Az intézmény felkészültségének követelményei

A.1.1.1 A fejlesztés elhelyezése az intézmény működésében

9

A.1-1-001

A fejlesztést megelőzően készült Megvalósíthatósági tanulmány.

A.1-1-002

A fejlesztési specifikáció rendszerelemzési és tervezési módszertan szerint készült

A.1-1-003

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.1-1-004

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.1-1-005

A fejlesztés kapcsán meghatározásra kerültek a prioritások (szakmai, intézményi, informatikai stb.)

A.1-1-006

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.

1999. évi LXXVI. törvény a szerzői jogról

13


A.1-1-007

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.1-1-008

A fejlesztési specifikáció tartalmaz összefoglaló, vezetői oldalt

A.1-1-009

A fejlesztési specifikáció tartalmazza a jelenlegi helyzet pontos leírását.

A.1-1-010

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.1-1-011

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.1-1-012

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.1-1-013

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

A.1-1-014

Készült logikai rendszerspecifikáció.

A.1-1-015

A rendszer által kezelendő információknak ismert a szerkezete (logikai adatszerkezet), és ez megfelelő a későbbi modellezéshez.

A.1-1-016

Készült magas szintű adatfolyam leírás/ábra.

A.1-1-017

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.1-1-018

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.1-1-019

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.1-1-020

A fejlesztést megelőzően készült Fenntarthatósági tanulmány.

A.1-1-021

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é.

A.1-1-022

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.1-1-023

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.1-1-024

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


kerültek. A.1-1-025

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.1-1-026

A fejlesztésben részt vevő (kulcs)szakemberek száma elegendő.

A.1-1-027

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.)

A.1-1-028

Az intézmény/kedvezményezett szakemberei hatékony segítségre képesek a fejlesztés/fizikai rendszertervezés szakaszában is.

A.1.1.2 Intézményi követelmények a fejlesztés előkészítésére A.1-2-001

A fejlesztés kedvezményezettje kulcsfelhasználókkal.

A.1-2-002

Az intézményi menedzsment elkötelezett az IKT megoldások mellett, az új fejlesztések előnyeit, kedvező hatásait ismeri.

A.1-2-003

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.1-2-004

A felső vezetés információs igényei pontosan meghatározottak, és ezeket a fejlesztendő rendszer ki fogja szolgálni.

A.1-2-005

Az információ-menedzselés szerkezete pontosan megtervezett, ismert.

A.1-2-006

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.1-2-007

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.

A.1-2-009

Az intézményi folyamatok informatikai támogatottsága pontosan ismert, felmért és követhető.

A.1-2-010

Az informatikai fejlesztést megelőzően történt szervezetfejlesztési felmérés.

A.1-2-011

A szervezetfejlesztési lépések informatikailag is megalapozottak, tervezettek.

A.1-2-012

A fejlesztések, alkalmazások támogatják az alapvető orvosi/egészségügyi tevékenységeket.

A.1-2-013

A tervezett fejlesztés ismert és elfogadott a felhasználói/orvosi körökben.

A.1-2-014

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.1-2-015

A bevezetendő informatikai rendszerek követése, támogatása biztosított.

A.1-2-016

Kellő számú és rendelkezésre állású informatikai rendszergazda segíti a felhasználók munkáját.

A.1-2-017

Az intézmény rendelkezik magasan képzett, mind az orvosi szakmában, mind az informatikában elfogadott IT vezetővel. 15

rendelkezik

informatikailag

képzett


A.1-2-018

Az intézmény rendelkezik megfelelő számú és megfelelően képzett szakértői munkatárssal (informatikai kulcsfelhasználók)

A.1-2-019

Az informatikai rendszerek felhasználóbarát módon segítik a felhasználók tevékenységét.

A.1-2-020

A felhasználók részesültek, illetve részesülnek célirányos, megfelelő informatikai (tovább)képzésekben.

A.1-2-021

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.1.2.1 Beszállítói követelmények A.1-3-001 A.1-3-002 A.1-3-003

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.1-3-004

A beszállító szervezeti és személyi szerepkörei, kompetenciái világosak, azok kapcsolódása a meglevő szervezethez tisztázott.

A.1-3-005

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.1-3-006

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.1-3-007

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.1-3-008

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.1-3-009

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.1-3-010

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.1-3-011

A beszállító megfelel a műszaki-technikai alkalmasságára, felszereltségére a 16


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.1-3-012

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.1-3-013

A beszállító által a minőség biztosítása érdekében tett intézkedések megfelelők.

A.1-3-014

A beszállító termelési képességei, illetőleg vizsgálati és kutatási eszközei megfelelők.

A.1-3-015

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.1-3-016

A beszállító által a megvalósítás időütemezésében a belső, logikai kapcsolatok egyértelműek, indokoltak.

A.1-3-017

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.1-3-018

A beszállító által a megvalósítással kapcsolatos lehetséges kockázatok bemutatottak, a kockázatkezelés módja megfelelő.

A.1.2.2 Az ajánlott megoldás illeszkedése a kiíráshoz A.1-4-001

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.)

A.1-4-002

Az ajánlat tartalmazza az ajánlattevő fő tevékenységeinek, szervezetének rövid bemutatását.

A.1-4-003

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.

A.1-4-004

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.

A.1-4-005

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.)

A.1-4-006

Az ajánlat tartalmazza az ajánlott megoldás üzleti koncepcióját.

A.1-4-007

Az ajánlat tartalmazza az ajánlott megoldás részletes leírását.

A.1-4-008

Az ajánlat tartalmazza a fejlesztendő rendszer - beleértve annak szolgáltatásait is - részletezett, fontosabb üzleti funkcionalitásait.

A.1-4-009

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.

A.1-4-010

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


A.1-4-011

Az ajánlat részletesen bemutatja a tesztelés folyamatát, dokumentálását.

A.1-4-012

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.).

A.1-4-013

Az ajánlat kitér a változáskezelés folyamatára.

A.1.3 A fejlesztés előkészítésének, követésének követelményei

megvalósításának

és

eredményének,

A.1.3.1 A fejlesztés előkészítésének tervezési feladatai és módszerei A.1-5-001

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.1-5-002

A célok meghatározása megtörtént (eszközök és célok rendszere, „cél-fa” elkészítése)

A.1-5-003

A stratégiaelemzés megtörtént (beavatkozások, megoldási lehetőségek, módszerek megvalósíthatósága)

A.1-5-004

Készült logikai keretmátrix.

A.1-5-005

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.1-5-006

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.1-5-007

A fejlesztés eredményei (a fejlesztés keretében végrehajtott tevékenységek „termékei” - outputok) meghatározásra kerültek.

A.1-5-008

Az eredmények elérése érdekében végzendő tevékenységek meghatározása megtörtént.

A.1-5-009

Előre definiálásra kerültek azok a folyamatok, amelyeket a fejlesztés érint.

A.1-5-010

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.1-5-011

A tevékenységekhez tartozó erőforrás és időbecslések elkészültek.

A.1-5-012

Készült kommunikációs terv.

A.1-5-013

Objektíven ellenőrizhető mutatók (indikátorok) kerültek meghatározásra.

A.1-5-014

Az átfogó célok mérésére definiáltak a hatásindikátorok.

A.1-5-015

A konkrét cél mérésére definiáltak az eredmény indikátorok.

A.1-5-016

A fejlesztés eredményének mérésére definiáltak az output indikátorok.

A.1-5-017

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.1-5-018

A mutatók mérésére megfelelő ellenőrzési, információgyűjtési eszközrendszer került kialakításra.

18


A.1.3.2 A Projekt Alapító Dokumentum követelményei A.1-6-001

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.1-6-002

A PAD tartalmazza a fejlesztés főbb adatait, besorolását, célját, helyszínét.

A.1-6-003

A PAD bemutatja a fejlesztés időtartamát, ütemezését, logikai hálóját.

A.1-6-004

A PAD tartalmazza a fejlesztés költségtervét (költségvetését), tervezett beszerzéseit.

A.1-6-005

A PAD kellő részletességgel ismerteti a fejlesztés szereplőit és szervezetét.

A.1-6-006

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.1-6-007

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.1-6-008

A projektigazgató személye (szakmai és emberi képességek) megfelelő.

A.1-6-009

A projektmenedzser(ek) megfelelő(ek).

A.1-6-010

A fejlesztés minőségbiztosítása kialakításra került.

A.1-6-011

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.1-6-012

A fejlesztést támogató projekt titkárság felállításra került.

A.1-6-013

Az iratok kezelése, megőrzése szabályozott.

A.1-6-014

Meghatározásra került a fejlesztés „környezete”: kapcsolódás programokhoz, projektekhez; a tevékenységek függőségei.

A.1-6-015

Kialakításra kerültek a beszállító részéről is a projektszervezet elemei.

A.1-6-016

A PAD számba veszi a kezdeti kockázatokat, feltételezéseket és ismert korlátozó tényezőket

A.1-6-017

A PAD-ban részletesen szabályozott a fejlesztés pénzügyi eljárásrendje.

A.1-6-018

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.1-6-019

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.1-6-020

A PAD-ban szabályozásra került a jelentési rend (heti, havi, előrehaladási, záró stb.).

A.1-6-021

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.1-6-022

A PAD tartalmazza a fejlesztés leírását.

A.1-6-023

A PAD tartalmazza az alkalmazás szint ismertetését.

A.1-6-024

A PAD tartalmazza a megosztott, közös erőforrások és szolgáltatások szint

személye

19

(szakmai

és

emberi

képességek)

más


ismertetését. A.1-6-025

A PAD tartalmazza az infrastruktúra közmű (IT és kommunikációs) ismertetését.

A.1.3.3 A fejlesztéssel követelményei

kapcsolatos

szerződés(háló)

kialakításának

A.1-7-001

A beszállítói szerződés összhangban van a megvalósítás ütemezésével, szakaszaival, belső összefüggéseivel.

A.1-7-002

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.

A.1-7-003

Egyértelműen definiált a szerződés tárgya.

A.1-7-004

A beszállítói szerződés egyértelműen rögzíti a szerződéses árat (nettó és áfa tartalom).

A.1-7-005

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.1-7-006

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.1-7-007

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)

A.1-7-008

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.1-7-009

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.1-7-010

A beszállítói szerződés egyértelműen szabályozza, hogy a vállalási ár mit tartalmaz.

A.1-7-011

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.1-7-012

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.1-7-013

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.1-7-014

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.1-7-015

A beszállítói szerződés egyértelműen szabályozza az eredménytermék 20


(szállítandó eszközök, fejlesztendő alkalmazások, szolgáltatások) tartalmát, paramétereit. A.1-7-016

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.1-7-017

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.1-7-018

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.1-7-019

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.1-7-020

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.1-7-021

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.1-7-022

A beszállítói szerződés egyértelműen szabályozza a szavatossági feltételeket.

A.1-7-023

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.1-7-024

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.1-7-025

A beszállítói szerződés (pl. mellékleteiben) tartalmazza azokat jogszabályokat, amelyekre a szerződő feleknek tekintettel kell lenni.

a

A.1.3.4 Szoftverszerződésekkel kapcsolatos elvárások A.1-8-001

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énnyel10.

A.1.3.5 A fejlesztés megvalósítása követésének követelményei

10

A.1-9-001

A projekt/fejlesztés minőségbiztosítása (szervezetileg, felelős stb.) biztosított

A.1-9-002

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.1-9-003

A kockázatok (célok, költségek, határidők, támogatottság stb.) folyamatos kezelése biztosított.

A.1-9-004

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

1999. évi LXXVI. törvény a szerzői jogról

21

erőforrások,

minőség,


adminisztrációja biztosított. A.1-9-005

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.1-9-006

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.

A.1-9-007

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.1-9-008

A fejlesztés során a különböző nyilvántartások vezetése tervezett (vezetői, szakmai, minőségi).

A.1-9-009

Vezetői nyilvántartás (a fejlesztés irányításával kapcsolatos összes termék) rendelkezésre áll és aktualizált.

A.1-9-010

Szakmai nyilvántartás (az összes szakmai termék) rendelkezésre áll és aktualizált.

A.1-9-011

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.1-9-012

A fejlesztés termékeinek megfelelően dokumentált.

minőségbiztosítási

rendszere

működik

és

A.1.3.6 A fejlesztés eredményének követelményei A.1-10-001

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.1-10-002

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.1-10-003

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.1-10-004

A fejlesztett rendszer átvétele az előzetesen jóváhagyott átvételi terv alapján történt, és annak megfelelt.

A.1-10-005

A fejlesztett rendszer átvétele az előzetesen jóváhagyott átvételi terv alapján történt, és annak megfelelt.

A.1-10-006

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.1-10-007

A beszállító átadta a fejlesztett rendszer legutolsó változatának forráskódját.

A.1-10-008

A beszállító átadta a fejlesztett rendszer leírását, dokumentációját.

A.1-10-009

A beszállító átadta a fejlesztett rendszer felhasználói kézikönyvét.

A.1-10-010

A beszállító – amennyiben ez a kiírásban szerepelt – működtet Help Desket, támogató ügyfélszolgálatot.

A.1-10-011

Az átadott rendszer garanciális időszakára vonatkozóan hibakövetési rendszer működik.

A.1-10-012

A garanciális időszak alatt a felmerült hibák javítása biztosított.

22


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.2.1.1 A fejlesztés elhelyezése az intézmény működésében A.2-1-001

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.2-1-002

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

A.2-1-003

Rendszerszervezési alternatívák felállításra kerültek.

A.2-1-004

Az egyes fejlesztési alternatívákat megalapozó/megerősítő tanulmányok/állásfoglalások rendelkezésre állnak (szakmai, menedzsment, informatikai stb.)

A.2-1-005

A fejlesztés környezeti hatásvizsgálata megtörtént.

A.2-1-006

A fejlesztés társadalmi-gazdasági hatásainak felmérésére megtörtént.

A.2-1-007

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.2-1-008

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.2-1-009

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.2.1.2 Intézményi követelmények a fejlesztés előkészítésére A.2-2-001

A fejlesztés kedvezményezettje felhasználókkal.

A.2-2-002

Az informatikai eszközök használata megtalálható az intézmény – fejlesztésben érintett – egységeinél.

A.2-2-003

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

A.2-2-004

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.

A.2-2-005

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

rendelkezik

informatikailag

képzett


A.2-2-006

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

A.2-2-007

Az intézmény – fejlesztésben érintett – dolgozói képesek a fejlesztési igényeiket informatika közeli szemléletmódban megfogalmazni.

A.2-2-010

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.

A.2-2-011

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.1 Beszállítói követelmények A.2-3-001

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.2.2.2 Az ajánlott megoldás illeszkedése a kiíráshoz A.2-4-001

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).

A.2-4-002

Az ajánlat tartalmazza az ajánlott megoldás magas szintű üzleti koncepcióját.

A.2-4-003

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.2-4-004

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.2-4-005

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.2-4-006

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.2-4-007

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.2-4-008

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.2-4-009

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


11 12

A.2-4-010

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.2-4-011

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.2-4-012

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ét11, paramétereit.

A.2-4-013

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.2-4-014

A műszaki leírás megfelelő részletességgel mutatja be a felhasználói (kliens) oldali követelményeket.

A.2-4-015

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.2-4-016

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.2-4-017

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.2-4-018

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.2-4-019

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.2-4-020

A műszaki leírás megfelelő részletességgel mutatja az adatkezelés rendszerét12 (archiválás, adat-elérhetőség, adatmentés, adatbiztonság, adatvédelem stb.)

A.2-4-021

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.2-4-022

A műszaki leírás megfelelő részletességgel telepítendő/fejlesztendő szoftverekre a licencezést.

Eurorec: GS002253.01 Eurorec: GS002252.01

25

mutatja

be

a




és

eredményének,

A.2.3.1 A fejlesztés előkészítésének tervezési feladatai és módszerei A.2-5-001

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.2-5-002

Megtörtént a fejlesztés részfolyamatokra bontása, a részfeladatokhoz tartozó elvégzendő tevékenységek meghatározása, a közöttük levő összefüggések megtervezése.

A.2-5-003

Az előfeltételek, feltételezések (kockázatkezelési terv).

A.2-5-004

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.2-5-005

A (rész)folyamatok felhasználói és a felhasználás helyei pontosan ismertek, feltérképezettek

A.2-5-006

A (rész)folyamatok során kezelt adatok (adatcsoportok, adatelemek) számossága és összefüggései pontosan meghatározottak.

A.2-5-007

A feladatok kivitelezőinek meghatározása megtörtént.

A.2-5-008

A mérföldkövek meghatározásra kerültek.

A.2-5-009

A kritikus út meghatározásra került.

A.2-5-010

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)

A.2-5-011

Készült a befektetés – amennyiben ilyen van - megtérülését alátámasztó pénzügyi elemzés (business case).

és

kockázatok

(kompetenciák

és

elemzése

felelősségek

megtörtént

mátrixa)

A.2.3.2 A Projekt Alapító Dokumentum követelményei


kapcsolatos

szerződés(háló)

kialakításának

A.2.3.4 Szoftverszerződésekkel kapcsolatos elvárások A.2-8-001

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.2-8-002

A szerződés(ek)ben - a szerzői, illetve felhasználási jogokkal kapcsolatban 26


az alábbiak rögzítése elvárt: A.2-8-002-1

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.

A.2-8-002-2

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.

A.2-8-002-3

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.

A.2-8-002-4

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.

A.2-8-002-5

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.

A.2-8-002-6

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.

A.2-8-002-7

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.)

A.2-8-002-8

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.

A.2-8-002-9

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


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.2-8-002-10

A.2.3.5 A fejlesztés megvalósítása követésének követelményei -

A.2.3.6 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.3.1.1 A fejlesztés elhelyezése az intézmény működésében -

A.3.1.2 Intézményi követelmények a fejlesztés előkészítésére -


A.3.2.1 Beszállítói követelmények -

A.3.2.2 Az ajánlott megoldás illeszkedése a kiíráshoz -



és

eredményének,

A.3.3.1 A fejlesztés előkészítésének tervezési feladatai és módszerei 28


A.3.3.2 A Projekt Alapító Dokumentum követelményei -


kapcsolatos

szerződés(háló)

-

A.3.3.4 Szoftverszerződésekkel kapcsolatos elvárások -

A.3.3.5 A fejlesztés megvalósítása követésének követelményei -

A.3.3.6 A fejlesztés eredményének követelményei -

29

kialakításának

Egészségügyi információs rendszerek felépítése

II.

K ÖVETELMÉNYEK SZAKELLÁTÁSI FELÉPÍTÉSÉHEZ

AZ EGÉSZSÉGÜGYI INFORMÁCIÓS RENDSZEREK

30


B Egészségügyi szakellátási információs implementációs követelményei

rendszerek

B.1 Az informatikai rendszerek alapkövetelményei B.1.1 Az informatikai infrastruktúra architektúrális követelményei

B.1.1.1 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. 2. 3. 4. 5. 6. 7. 8.

Az ágazati adat-áramlás és intézményközi interoperabilitás Üzemelési és kommunikációs sztenderdek, Szolgáltatási színvonal és szintek egységesedése, a színvonal emelkedése. Az ágazat stratégiai fejlesztési projektjeivel való összhang biztosítása informatikai képességek szintjén. Ágazati szereplők (intézmények, kórházak, stb.) közpénzzel támogatott informatikai fejlesztéseinek kötelező tartalmi elemei Ágazati szoftver / informatikai rendszer fejlesztés Ágazati szoftver / informatikai rendszer akkreditáció bírálati szempontjai 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.1.1.2 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


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


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


B.1.1.3 Á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 ESB14 és a SOA15 típusú megoldások alkalmazása. A megfelelő fejlesztési technológia kiválasztásával időtálló16, fenntartható B.1-1-001 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.1-1-002 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úra17: a megvalósításra kerülő alkalmazás kettő (kliens- szerver), B.1-1-003 vagy több rétegű (multi-tiered) architektúrára18 é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.1-1-004 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.1-1-005 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át19. Meg kell határozni, hogy mely eszközök szolgálnak egymás tartalékaiként, illetve az egyes tagok B.1-1-006 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 technológiák virtualizált szoftveres környezetben történő megvalósítása B.1-1-007 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 1997. é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


B.1-1-008

B.1-1-009

B.1-1-009-1

B.1-1-009-2

B.1-1-009-3 B.1-1-009-4

B.1-1-009-5

B.1-1-009-6

B.1-1-010

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 Keretrendszerek20 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


elérhetőségét az általánosan elterjedt, kereskedelmi rendelkezésre álló hálózati kapcsolatokon keresztül21.

forgalomban

B.1-1-011 B.1-1-012 B.1-1-013

A tükrözés22 vagy a megfelelő szintű RAID23 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 kell24.

B.1.1.4 Infrastruktúrális követelmények B.1-2-001 B.1-2-001-1 B.1-2-001-2 B.1-2-001-3 B.1-2-001-4

B.1-2-001-5

B.1-2-001-6

B.1-2-001-7 B.1-2-001-8 B.1-2-001-81

A környezeti hibaforrásokat minimálisra kell csökkenteni. Az alkalmazásokat futtató hardver környezetet minimálisan a következő paraméterekkel rendelkező gépteremben25 kell elhelyezni ahol biztosított: 26 o a gépek hőtermelésének megfelelő légkondicionálás; o az eszközök illetéktelen személyek általi hozzáférése elleni védelme; 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 alkalmazásoknak megfelelően27 méretezett sávszélességű primer és szekunder betáplálású hálózati28 csatlakozás; 29 o az alkalmazások által kezelt adatok üzemszerű működéséhez 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 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 által kezelt adatok rendszeres archiválásához30 szükséges eszköz, archiváló szoftver, kellő számú licence és tároló kapacitás; o a gépek teljesítmény felvételének megfelelő, szünetmentes áramellátást biztosító szünetmentes táp rendszer31; o A szerver számítógépek és a szünetmentes áramforrásoknak rendelkezniük kell távmenedzsment32 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: GS002244.01 + GS002248.01 30 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


B.1-2-001-82

o

B.1-2-001-9

B.1-2-001-91 B.1-2-001-92 B.1-2-001-93 B.1-2-001-94

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 szintek33 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ő, e-mail, sms, stb.)

B.1.1.5 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. Biztosítani kell az adatok és rendszerek időszakos napi, heti, havi, éves B.1-3-001 mentését a vállalt szolgáltatási szinthez illeszkedő mentési rend alapján34. 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.1-3-002  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ét35 33

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


B.1-3-003

B.1-3-004

B.1-3-005

B.1-3-006

B.1-3-007

B.1-3-008

B.1-3-009

B.1-3-0010

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őtartamig36 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égezni37. A rendszer minimálisan az alábbi mentésekre legyen felkészítve: o Teljes mentés 38 o Inkrementális mentés39  kumulatív mentés (növekményes)40  differenciális mentés (különbségi)41

36

Lásd 1997. é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


B.1-3-011

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.1.1.6 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. 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 B.1-4-001 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ó B.1-4-001-1 utasításokkal és előírásokkal43, 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 B.1-4-001-2 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ítja44, 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ó B.1-4-001-3 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 B.1-4-001-4 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 B.1-4-001-5 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é teszik45, o jogszabályban meghatározott nyilvántartás ismételt előhívására B.1-4-001-6 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


B.1-4-001-7 B.1-4-002 B.1-4-002-1 B.1-4-002-2

B.1-4-002-3

B.1-4-002-4

B.1-4-002-5 B.1-4-002-6 B.1-4-002-7

B.1-4-002-8

B.1-4-003 B.1-4-003-1 B.1-4-003-2 B.1-4-003-3 B.1-4-003-4

anyagokat a jogszabályokban meghatározott ideig, bármikor visszakereshetően, helyreállíthatóan megőrizzék46, 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ítani47. 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ól48, 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ől49, 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: GS003630. 01 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: GS002243.02 49 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. 47

40


B.1-4-003-5

o az adatokhoz történő hozzáférési rend meghatározásának,

B.1-4-003-6

o az adatgazda és a rendszergazda kijelölését tartalmazó iratnak,

B.1-4-003-7

B.1-4-003-8

B.1-4-003-9

B.1-4-004

B.1-4-005

B.1-4-006

B.1-4-007

B.1-4-008 B.1-4-009

B.1-4-010

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, e-mail)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ások51 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.1.1.6.1 Időszinkronizálás

50 51

Lásd az üzemeltetési és hibaelhárítási nyomvonalak Az előírásokat a 195/2005. (IX. 22.) Korm. rendelet változásának megfelelően módosítani szükséges.

41


A 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 HIS53 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.1-4-012 B.1-4-013 B.1-4-014 B.1-4-015 B.1-4-016

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.1.1.6.2 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 meg. Alapértelmezésben minden esetben magyar nyelvű kezelői felültetet B.1-5-001 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. névsorba rendezés) és a magyar ékezetes karaktereket mind a képernyőn B.1-5-002 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.1-5-003 (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.1-5-004 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.1-5-005 nyelveken történő oktatást előzetesen egyeztetni szükséges.

52 53

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. Heltcare Information System – Egészségügyi Informatikai rendszer

42


B.1-5-006 B.1-5-007

B.1-5-008

B.1-5-009 B.1-5-010

A felhasználói dokumentációk nyelve magyar. A rendszergazdai dokumentációknál is törekedni kell a magyar nyelvű 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 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 A megajánlott rendszer felhasználói felületének a nyelve legyen állítható. A megajánlott rendszer nyelvi beállítottsága egyes felhasználóhoz, vagy felhasználó csoporthoz55 legyen kapcsolható.

B.1.1.6.3 A hazai törvényi előírásoknak való megfelelés (jogszabályi megfelelés) B.1-6-001 B.1-6-002 B.1-6-002-1

B.1-6-002-2

B.1-6-002-3 B.1-6-002-4

Az informatikai szállítónak be kell mutatnia, hogy a megajánlott rendszer teljes körűen megfelel a megajánlott egészségügyi munkahelyre56 vonatkozó magyar jogszabályi előírásoknak és az aszerinti működésnek. A szoftvernek alkalmasnak kell lennie a működési és finanszírozási gyakorlatnak megfelelő: 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 o finanszírozással kapcsolatos kódtörzek o ráépülő nyilvántartások o intézet és szakmaspecifikus kódtörzsek. o „Ellátás biztosító személyek” személyes és szakmai adatainak rendszerbe történő rögzíthetősége idősorosan. o „Páciens törzsadatok” rögzíthetősége. „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 . o Szabványos regionális és ágazati szintű működés és kommunikáció kialakíthatósága57. o Az ellátás folyamata során a magyar szakmai, működési és 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). o

B.1-6-002-5

B.1-6-002-6 B.1-6-002-7

54

Részletesen lásd „A fejlesztés előkészítésének tervezési feladatai és módszerei „ Eurorec: GS001511.03 56 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. 55

43


B.1-6-002-8 B.1-6-003

B.1-6-004

B.1-6-005

B.1-6-006

B.1-6-007

B.1-6-008

o Működéssel kapcsolatos automatikus lekérdezések definiálhatósága és ütemezhetőségeAz 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 adni59.

58

53/2007 (XII: 7.) EüM rendelet a gyógyszerrendeléshez használandó számítógépes program minősítésének szabályairól, 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


B.1.1.7 Működtetéssel kapcsolatos dokumentáció

B.1-7-001 B.1-7-001-1

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átni60: o Logikai rendszerterv

B.1-7-001-2

o Fizikai rendszerterv

B.1-7-001-3

o Működési folyamat és kommunikációs leírások

B.1-7-001-4

o Adatbázis szerkezet leírás61

B.1-7-001-5

o Interfész specifikációk62

B.1-7-001-6

o Funkcionális tesztelési terv és annak eredménye

B.1-7-001-7

o Terheléses tesztelési terv és annak eredménye

B.1-7-001-8

o Mentési visszaállítási terv63

B.1-7-001-9

o Telepítési és paraméteresési útmutatók64

B.1-7-001-10 B.1-7-001-11 B.1-7-001-12

o o o o

B.1-7-001-13

B.1-7-001-14 B.1-7-001-15 B.1-7-001-16 B.1-7-001-17 B.1-7-001-18 B.1-7-001-19 B.1-7-001-20 B.1-7-001-21 B.1-7-001-22

o o o o o o o o o

Felhasználói kézikönyvek Üzemeltetési kézikönyv és szolgáltatási szint leírás Informatikai biztonsági szabályzat Migráció leírás (Mely adatok és dokumentumok milyen kiegészítő 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.) A Megrendelő szervezet installációs és konfigurációs tevékenységeire vonatkozó kézikönyv Az illesztett rendszerek illesztési protokolljának leírása65, a működés elképzelt folyamatleírása. 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 ) Felhasználói kézikönyv (modulonként) Vészhelyzeti működési szabályzat Az üzemeltetési szabályzat feladatlistájának részletes összeállítása66 Minőségellenőrzési jegyzőkönyvek Megvalósítási dokumentáció67 Változáskezelést rögzítő dokumentáció mely a projekt teljes életszakaszában vezetendő dokumentum68

60

Eurorec: GS002248.01+ GS002246.02 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 61

A.1

63

A.2

64

Részletesen lásd – Architekturális követekmények - Mentési, archiválási, visszatöltési követelmények

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


B.1-7-002 B.1-7-003

68 69

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égezni69. 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 dokumentumok70.

Ez az egészségügyi intézmény és az Ajánlattevő közös feladata. Eurorec: GS002246.02+

A.3

70

Az elvárásokat lásd az oktatási elvárások megfogalmazásánál

46


B.1.2 Intézményközi rendszerszolgáltatások általános és specifikus követelményei

B.1.2.1 A Kooperatív Tér A Kooperatív Tér71 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 Publikus tér P tér

Kooperatív tér - B tér

Ellátás tere - C tér B.1.2.1.1 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


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űveletek72, í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


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.1.2.1.2 A Kooperatív tér egyszerűsített felépítése

Ágazatspecifikus szolgáltatások

Üzenet kezelés

Á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


• •

Á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. 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. 74

50


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.1.2.2 A Kooperatív követelmények

B.1-8-001

B.1-8-002

B.1-8-003 B.1-8-004 B.1-8-005 B.1-8-006

tér

kialakításával

kapcsolatos

általános

Törekedni kell arra, hogy a Kooperatív térben a egészségügyi ágazat 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 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 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 mérvadók. A Tér szolgáltatásai igen gyors válaszidőt kell, hogy biztosítsanak. A térben tárolt információk kereséséhez biztosítson gyors válaszidőt (a 51


B.1-8-007 B.1-8-008 B.1-8-009 B.1-8-010

B.1-8-011

B.1-8-012

B.1-8-013

B.1-8-014 B.1-8-015 B.1-8-016

B.1-8-017

B.1-8-018

B.1-8-019 B.1-8-020 B.1-8-021 B.1-8-022

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


B.1-8-023 B.1-8-024 B.1-8-025 B.1-8-026 B.1-8-027

B.1-8-028

B.1-8-029

B.1-8-030

B.1-8-031

B.1-8-032

többszörös azonosítással is75. 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ében76. 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 (AMPC77) 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.1.2.3 A Kooperatív téren belül megvalósuló alkalmazásokkal kapcsolatos követelmények B.1-8-033

B.1-8-034 B.1-8-035

Az üzenetek küldésére és fogadására vonatkozó képességek megteremtésével 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 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. 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


B.1-8-036

B.1-8-037

B.1-8-038 B.1-8-039 B.1-8-040 B.1-8-041 B.1-8-042 B.1-8-043 B.1-8-044 B.1-8-045 B.1-8-046 B.1-8-047 B.1-8-048 B.1-8-049 B.1-8-050 B.1-8-051 B.1-8-052

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


B.1.3 Üzenetkezelés

B.1.3.1 A Kooperatív követelmények B.1-9-001 B.1-9-002 B.1-9-003 B.1-9-004 B.1-9-005 B.1-9-006 B.1-9-007 B.1-9-008 B.1-9-009 B.1-9-010 B.1-9-011

B.1-9-012

Tér

üzenetkezelésével

kapcsolatos

általános

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ódhatnak78 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és79  két szintű tartalom leíró metaadatok o a külső leírók80. o belső metainformációk81

B.1.4 Intézményközi technológiai protokollok követelményei

B.1.4.1 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óval82 78

Pl. logok formájában tárolódhatnak 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 79

55


 kompatibilitással83  adaptálhatósággal84 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 szintjei85 1. 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 HL786 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. (http://en.wikipedia.org/wiki/Conceptual_interoperability)

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


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ét87 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


Az Interoperabilitás szintjei Adattípusok interoperabilitása Az európai és amerikai szabványosítási folyamatok konvergenciájának egyik eredménye a MSZ CEN/TS 14796 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 13606 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ója88 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


B.1-10-001 B.1-10-002 B.1-10-003 B.1-10-004 B.1-10-005 B.1-10-006 B.1-10-007

89

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ő 89 formátumok (valamelyikének) alkalmazása

az MSZ 22800 szabvány az irányadó.

59


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 2008. ÁPRILIS alapján

60


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.1.5.1 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.1-11-001

A tele-konzultáció során a konzulensek azonosíthatóak legyenek

B.1-11-002

A tele-konzultáció során csak olyan tartalmak használhatóak fel, amelyeket valamennyi konzulens el tud érni.

B.1-11-003

A tele-konzultációról hangfelvétel készüljön

B.1-11-004

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

B.1-11-005

A tele-diagnosztikát végző orvos azonosítható legyen

B.1-11-006

A tele-diagnosztikánál alkalmazott táv-eljárás a szakma számára elfogadott kell, hogy legyen

B.1-11-007

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

B.1-11-008

A tele-diagnosztika dokumentációját digitális aláírás és időbélyeg hitelesítse

B.1-11-009

Az üzemszerűen alkalmazott tele-diagnosztikai rendszerek rendelkezésre állása 7/24 kell, hogy legyen

B.1-11-010

Az üzemszerűen alkalmazott tele-diagnosztikai rendszereknél alkalmazott orvosok speciális képzettséggel kell, hogy rendelkezzenek

61


B.1-11-011

A tele-diagnosztikai rendszerek esetén a beteg-adatok kezelését a hatályos jogszabályoknak megfelelően kell elvégezni

B.1-11-012

A tele-diagnosztikai rendszerek a szakmai területen előforduló szabványos fájl-formátumokat kell kezelniük

B.1-11-013

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

B.1-11-014

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.1.5.2 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.1-11-015

A telemedicina folyamatainak a szakterület orvos-szakmai kollégiuma által elfogadott módon kell az ellátási protokollba beépülnie

62


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


B.1.5.2.1 Rendszer integrátor Az az egészség-ipari szereplő, amely a telemedicina alkalmazást létrehozta, a benne szereplő közreműködőket kiválasztotta és működő rendszerbe integrálta. A rendszer integrátor felelős a telemedicina alkalmazás működtetéséért. A rendszer integrátor áll szerződéses viszonyban (ha áttételesen is) a telemedicina rendszer igénybevevőjével (beteg, felügyelt stb.) B.1-11-016

A rendszer integrátor teljes felelősséggel tartozik az általa üzemeltetett rendszer biztonságáért, előírt rendelkezésre állásáért, amelyet a szolgáltatást finanszírozóval (pl. OEP, magánszemély stb.) kötött szolgáltatási szerződés írja le

B.1-11-017

A rendszer integrátor rendelkezik a rendszere klinikai tesztjének dokumentációjával

B.1-11-018

A rendszer integrátor rendelkezik a vonatkozó szakmai kollégium elfogadó nyilatkozatával

B.1-11-019

A rendszer integrátor rendelkezik a rendszer által involvált összes partnerrel érvényes szerződéssel, amely meghatározza a partnere által biztosítandó rendelkezésre állást és biztonsági előírást

B.1-11-020

A rendszer integrátor nem adatkezelő, csak adat-feldolgozó funkciót tölthet be

B.1-11-021

A rendszer integrátor rendelkezik a beteg hozzájárulási nyilatkozatával a személyes és egészségügyi adatainak feldolgozását illetően

B.1-11-022

A rendszer integrátor a telemedicina rendszerből kivált betegre vonatkozóan a kiválást követően adatfeldolgozó tevékenységet nem folytathat

B.1-11-023

A rendszer integrátor köteles a beteget a rendszer használatára megfelelően betanítani, számára a szükséges on-line vevőszolgálati tevékenységet biztosítani

B.1-11-024

B.1.5.2.2 Rendszer komponens/résztvevő szolgáltató A rendszer integrátor által a telemedicina alkalmazás működtetésébe bevont szolgáltató, amely a rendszer rész-feladataiért felelős. A rész-feladatok ellátását ez a szereplő a rendszerintegrátorának partnereként biztosítja, a szolgáltatási szerződésben előírt rendelkezésre állás mellett. A rendszer integrátor lehet egyszersmind rendszer komponens / résztvevő szolgáltató is. Ebben az esetben rá a részterületen ugyanolyan szolgáltatási szint kötelezettség vonatkozik, mint a többi partnerre. B.1-11-025

A résztvevő szolgáltató biztosítja a szerződésében vállalt szolgáltatási szintet 64


a beteg tartózkodási helyén B.1-11-026

A résztvevő szolgáltató nem találkozhat a beteg személyes és egészségügyi adataival

B.1.5.2.3 Rendszer orvos-szakmai szolgáltatója A telemedicina rendszer orvos-szakmai ellátási protokollja által meghatározott funkciójának biztosítását végző egészségügyi szolgáltató. A feladata a protokoll betartása a telemedicina rendszer működése során. Ez főleg a beteg egészségügyi adatainak interpretálását jelenti az ellátási folyamatban, illetve a protokoll által meghatározott beavatkozások megtételét jelenti. B.1-11-027

A rendszer orvos-szakmai szolgáltatója a beteg adatainak kezelését csak a telemedicina rendszer használata idejére végezheti a rendszer integrátor által beszerzett beteg felhatalmazási szerződés alapján

B.1-11-028

A rendszer orvos szakmai szolgáltatója biztosítja a betegtől származó információ értékelésével a telemedicina rendszer szakmai bekapcsolását az ellátási környezetbe, beleértve a sürgősségi- és a fekvő- járó ellátást.

B.1-11-029

A rendszer orvos-szakmai szolgáltatója az előállott beteg dokumentációt a beteg a rendszerből való kilépésekor megküldi a betegnek papír alapon és a háziorvosának a megfelelő felhatalmazás birtokában

B.1-11-030

A rendszer orvos-szakmai szolgáltatója a szükségessé vált egyéb beavatkozásokat (tele-konzílium, sürgősségi riasztás stb.) dokumentálja, azt a betegdokumentáció részeként kezeli.

B.1-11-031

A rendszer orvos-szakmai szolgáltatója kapcsolatot tart a beteggel (annak hozzátartozóival) a távoli ellátás minőségének emelése, a rendszer elfogadottságának emelése érdekében

B.1-11-032

A rendszer orvos-szakmai szolgáltatója a szakmai kollégium álta elfogadott protokoll előírt dokumentációját vezeti, azt a protokollban résztvevő kapcsolódó szolgáltatónak átadja.

B.1.5.3 Betegállapotot (életfunkciót, egészségügyi paramétereket) mérő eszközök Azok a – közvetlenül a beteggel fizikai kontaktusban is lévő – eszközök és berendezések, amelyek a telemedicina alkalmazás által célzott információkat szolgáltatják a betegről. A mérőkészülékek lehetnek  közvetlenül viselt eszközök  távolról monitorozó eszközök

B.1.5.3.1 Közvetlenül viselt eszközök 65


A beteg életfunkcióit, fiziológiás paramétereit mérhetjük olyan készülékekkel, amelyek a testre helyezve kapcsolatba lépnek a test elektromos jeleivel, nyomásértékeivel, és ezen keresztül – a készülék leképző algoritmusa segítségével – mérnek olyan fizikai jellemzőket, mint a vérnyomás, a pulzusszám, vagy a több érzékelős EKG vagy EEG mérő készülék. Vannak olyan készülékek, amelyek a levett vérmintát analizálják, vércukor szintet kimutatva, vagy egyéb invazív és non-invazív módszerrel más jellemzőt mérnek.

B.1.5.3.2

Távolról monitorozó eszközök

Megint mások a mozgást, a gyorsulást mérik, ezáltal közvetett vizsgálatot végeznek a személy mozgásával, esetleges elesésével kapcsolatosan. Ezek a jellemzők felhasználhatóak az életjel regisztrálására, vagy az eszméletlen állapot meghatározására. Ide tartoznak – bár nem közvetlenül egészségügyi alkalmazásúak – a vagyonvédelmi eszközök is. Egy ajtónyitást érzékelő jelezhet a vizsgált személyre vonatkozó olyan állapotot (pl. elhagyta a tartózkodási helyét), amely a rendszer szempontjából lényeges. Valamennyi ilyen készülék a mért jellemzőt továbbítja egy távoli adatbázisba egy kommunikációs közegen keresztül. Ez a kommunikációs közeg helyi és távoli hálózati elemekből áll, és az infó-kommunikációs adatátviteli protokollok alapján működik. A távoli végpontok közötti adatátvitel már most szabványokon alapul, a mérőkészülékek és a helyi kapcsoló (router) közötti adatátvitel szabványai manapság alakulnak ki. A jelen dokumentum nem kíván a fizikai kapcsolat szintjén követelményeket megfogalmazni, viszont funkcionális követelményeket fel kíván állítani ezen a szinten: B.1-11-033

A beteggel fizikai kontaktusba kerülő eszköz nem zavarhatja a viselőjét a normális életvitelben, nem követelhet extrém vagy kényelmetlen testhelyzetet folyamatosan a viselőjétől

B.1-11-034

A készülék nem bocsáthat ki zavaró hang és fényjelenséget, ijesztő körülményeket nem teremthet

B.1-11-035

A készülék a kereskedelemben forgalomba hozott egyéb háztartási készülékekre előírt érintésvédelmi szabványnak megfelelőnek kell lennie, ezt műbizonylattal igazolni kell

B.1-11-036

A készüléken egyértelműen megállapítható kell, legyen a működésre jellemző állapot, a kikapcsolt, bekapcsolt üzemképes és hibás működésű állapot.

B.1-11-037

A készülékben alkalmazott tápforrás (elem, akkumulátor) töltöttségét meg kell tudni állapítani, az elemcserét könnyen el lehessen végezni, a készülék feltöltését – amennyiben ez lehetséges – a szokásos módon lehessen elvégezni

B.1-11-038

A készülék – illetve a tartózkodási helyen implementált lokális hálózat – hatósugara a teljes körletet fedje le, amely körlet a vizsgált/megfigyelt személy életvitelszerű mozgását foglalja magában. A rendszer betanítása során ennek a körletnek a kiterjedését a vizsgált/megfigyelt személy tudomására kell hozni 66


B.1-11-039

Az alkalmazott lokális hálózat jele nem zavarhatja a helyben működő elektromos berendezéseket és szórakoztató elektronikai eszközöket, ugyanúgy ahogyan nem lehet érzékeny ezen berendezések által keltett ismert mértékű sugárzásra sem. Amennyiben ilyen helyzet fennáll, a szükséges árnyékolás a rendszerintegrátor szolgáltató feladata.

B.1-11-040

A mérőkészülékek által mért jellemzők a telemedicina rendszer számára meghatározott személyhez kapcsolódik minden esetben. A rendszerben eltárolt információk a telemedicina rendszerbe történt bekapcsolástól a kiléptetésig tartoznak az adott személyhez

B.1-11-041

Minden esetben biztosítani kell a rendszerben egy vészjelzési lehetőséget, amely során vagy hangkapcsolat jön létre, vagy azonnali sürgősségi helyszíni kivonulás történik

B.1-11-042

A helyszíni kivonulásnak a sürgősségi ellátás (mentés) jogszabályban rögzített időintervallumában kell megtörténni.

B.1-11-043

A kommunikációban megtörtént forgalmazás logolását meg kell tenni, azt … ideig meg kell őrizni.

B.1-11-044

A személyre rögzített készüléknek fröccsenő víznek ellen kell állni

B.1-11-045

Valamennyi telepített eszköz rendelkezzen műbizonylattal, amely a klinikai teszt alapján lett kiállítva

B.1-11-046

A helyi rendszer rendelkezésre állása az alkalmazás függvénye. Lehet csak időszakosan működésbe hozott rendszer is, de a működési intervallumon belül 999-es rendelkezésre állás biztosítandó

B.1-11-047

Amennyiben a rendszer bizonyos elemének jelzése valószínűségi számításon alapul, a számításnak legalább 98%-os eredményt kell adni az aktiváláshoz.

B.1-11-048

Amennyiben a készülék működéséhez segédanyag(ok)ra van szükség, a megfelelő mennyiséget biztosítani kell – akár ellenérték fejében – a beteg számára (pl. tesztcsík a vércukor mérőhöz)

B.1-11-049

A mérőkészüléket egyszerű módon lehessen kalibrálni, az erre vonatkozó leírást a betegnek biztosítani kell, arra ki kell képezni (a családtagját is szükség esetén)

B.1.5.4 Szabványosítás. A szabványosítás egyik szerepe az európai gyakorlathoz igazodó szabványos (CENT 13606 és MSZ 22800 szerinti) kommunikációs struktúra kialakítása és a szemantikus interoperabilitás megvalósítása ezen szakterületeken. A szabványosítási törekvéseket jogi eszközökkel is támogatni szükséges. A kommunikáció rétegeinek, a csatlakozó eszközök, szolgáltatások párbeszédének – már korábban más alkalmazások gyakorlatához hasonlóan – 67


egységes, lehetőleg nemzetközi standardjainak (pl: DICOM3) rögzítése és alkalmazási követelménye az első feladat.

B.1.5.5 Adatátviteli – hálózati technológiák A lokális hálózat szempontjából a következő technológiák jöhetnek szóba:

B.1.5.5.1 WiFi (IEEE 802.11) A WiFi az IEEE által kifejlesztett vezeték nélküli mikrohullámú kommunikációt (WLAN) megvalósító, széleskörűen elterjedt szabvány (IEEE 802.11)népszerű neve. A WiFi az angol Wireless Frendly kifejezésnek a rövidítése. Az elnevezést egy marketing-cég találta ki játékosan utalva a Hi-Fi/hifi szóra, és csak később és átmenetileg igyekeztek rövidítésként feloldani és úgy reklámozni. A 802.11 fontosabb szabványai: távolság

max. adatátviteli

szabvány

megjelenési év

frekvenciatartomány

max. kültéren

802.11a

1999

5 GHz

~120m

54 Mb/s

802.11b

1999

2,4 GHz

~140m

11 Mb/s

802.11g

2003

2,4 GHz

~140m

54 Mb/s

802.11n

2009

2,4 GHz / 5 GHz

~250m

150 Mb/s csatornánként

802.11y

2008

3,7 GHz

~5000m

54 MB/s

802.11ac

2013

5 GHz

~350m

max 1,3 Gb/s (max 500 Mb/s csatornánként

802.11ad „WiGig”

2014

60 GHz

?

max. 7 Gb/s

sebesség

Ma már igen széles körben elterjedt, a munkahelyek, az otthonok és közösségi terek hálózati elérését biztosító technológia. A kezdeti bizonytalanságot leküzdve, manapság – nem túl nagy végberendezés esetén – elég biztonságosnak és robosztusnak tekinthetjük. A széleskörű elterjedtségét kihasználva igen gyakori a WiFi feltörésének kísérlete, ami miatt minősített hálózatok kialakításánál kerülik az alkalmazását. A WEP egyszerűen feltörhető titkosítási eljárása után a VPA- VPA2 technológiákat használják. A WPA (Wi-Fi® Protected Access), egy adattitkosítási protokoll. A protokoll nagyobb biztonságot nyújt a WEP hálózattal szemben az Extensible Authentication Protocol használatával (EAP - bővíthető hitelesítési protokoll), hogy biztonságossá tegye a hálózat elérését és a titkosítási módot az adatok továbbításakor. A WPA 802.1X hitelesítési szerverrel együttműködik, amely különböző kulcsokat oszt ki. Azonban a kevésbé biztonságos PSK (Pre-Shared Key) módban is használható. A PSK otthon és kisirodákban használt hálózati összeköttetésben alkalmazható, ahol minden felhasználónak ugyanaz az átjárási útja van. A WPA-PSK-t WPA-Personal-nak is nevezik. 68


Titkosítási módok VPA-nál: A TKIP (Temporal Key Integrity Protocol) egy titkosítási mód. A TKIP rendelkezik egy újrakulcsoló mechanizmussal, ami biztosítja, hogy minden adatcsomag egy egyedülálló titkosító kulccsal legyen elküldve. Az AES (Advanced Encryption Standard) a WiFi® által azonosított, erős titkosítási szabvány. A WPA-PSK/ WPA2-PSK és TKIP vagy AES PSK/ kulcsot használ, amely 8 vagy több karakter hosszúságú, és maximum 63 karakterig terjed.

B.1.5.5.2 Bluetooth A kilencvenes évek vége felé egyre gyakrabban felmerült elméleti síkon, hogy mennyire praktikus is lenne egy olyan adatátviteli szabvány létrehozása, amelynek segítségével különböző mobil és nem mobil eszközök összekapcsolása vezeték nélkül jöhetne létre. A megvalósítás felé az első lépés 1998 elején történt, mikor a Ericsson, az IBM, az Intel, a Nokia és a Toshiba létrehozta Special Internest Group (SIG) nevű csoportosulást, amely első ténykedéseként megalkotta a Bluetooth szabványt. Nevét egy békességszerző, kapcsolatteremtő viking királyról, Kékfogú Haraldról kapta. Az első Bluetooth eszközök 1999 májusában indultak hódító útjukra, a mobiltelefonok között az elsők között az Ericsson T68-as rendelkezett ezzel a szabvánnyal. A Bluetooth kis hatósugarú rádiós összeköttetés, amely a 2,402 GHz és 2,480 GHz közötti frekvenciasávban működik. Hatótávolsága mintegy 10-15 méterre tehető szabad területen. Az egy helyen létrejövő ún. pico-hálózatok nyolc Bluetooth egységet tartalmazhatnak, de ezek a hálózatok kapcsolódhatnak egymáshoz, így akár 80 ilyen eszköz is működhet együtt. Egyelőre nehéz azonban elképzelni, hogy egy 10-15 méter sugarú körön belül nyolcvan Bluetooth képes eszköz legyen jelen. Egy ilyen pico-hálózaton belül az adatátviteli sebesség 1 Mbit/s lehet, ezt a sebességet azonban felosztják. Beszédre három 64 Kbit/s-es csatornát jelölnek ki (ez jelenleg tipikusan a Bluetooth fejhallgatók által használt csatorna), a fennmaradó rész pedig adattovábbításra használható. Az adattovábbítás csatornája az eszközöktől és alkalmazásoktól függően lehet aszinkron is (pl. egyik irányban 721 kbit/s, másik irányban 57,6 kbit/s), de szimmetrikus is, így mindkét irányban 432,6 kbit/s az átviteli sebesség. A Bluetooth az IEEE 802.15 szabványon alapszik, amely olyan vezeték nélküli személyi hálózat működését specifikálja. Bluetooth 1.0-tól a Bluetooth 4.0-ig: Verzió

megjelenés éve

hatósugár

egyéb

1994-1998

adatátviteli sebesség 1 MBps

BT 1.0 és 1.0B

10m

BT 1.1 BT 1.2 BT 2.0

2002 2003 2004

1 MBps 2 MBps 2,1 Mbps (3MBps)

15m 15m 15m

bizonytalan és nem biztonságos IEEE 802.15.1-2002 IEEE 802.15.1-2005 fefelé kompatibilis

BT 2.1 BT 3.0

2007 2009

3 MBps 480 MBps-ig

20m 100m

BT 4.0 Bluetooth Smart

2011-2012

?

20m

91

https://www.bluetooth.org/en-us/training-resources/white-papers (2013)

69

volt

EDR EIR, EFR, SSP, NFC nagy adatforgalomnál WiFire vált energiatakarékos, új eszközök bekapcsolhatósága, pl. egészségügyi eszközök91


A legutolsó verziójú Bluetooth újra reális alternatíva az alacsony energiaigényű eszközök személyi hálózatba kapcsolására, amelyre a korai verziók nem voltak alkalmasak.

B.1.5.5.3 Zigbee A ZigBee adatátvitel az IEEE 802.15.4 vezeték nélküli szabványon alapszik. Ez a szabvány a WPAN92 hálózatokat definiálja. A ZigBee az ISM rádió sávon (2,4GHz) működik, és egy adhoc önszervező hálózatot képez. Ez a hálózat nagy átviteli kapacitással bír szenzorok alkalmazásakor. A protokollja a hand-shakel, az adatbiztonságot a AES-128 bites kódolás adja és kb. 100 méter a hatótávolsága. A korai Bluetooth-al ellentétben a kis fogyasztás, és a többféle hálózati topológia (csillag, szövevényes hálózat, klaszter-fa) jellemzi. Alkalmazása az ipari vezérlés, az automatizálás, az intelligens otthonok, a medikai adatgyűjtés és a biztonságtechnika területén honosodott meg.

B.1.5.5.4 Body Area Network (BAN vagy WBAN) – IEEE 802.15.6 Az IEEE 802.15 munkacsoport dolgozik a vezetéknélküli személyi területi hálózatok (WPAN - Wireless Personal Area Network) szabványainak kidolgozásán. Ide tartozik a Bluetooth (IEEE 802.15.1), a ZigBee (IEEE 802.15.4) és a legújabb, a IEEE 802.15.6, amely az emberi testre, a testen belülre épített szenzorokkal foglalkozik. Az erre vonatkozó szabványok kidolgozására 2007 novemberében alakult 6. Task Group. A világszerte rohamosan fejlődő alacsony fogyasztású, miniatűr érzékelők akár egy viselhető test-közeli hálózatban, akár a testen belül, implantátum formájában, érzékelik az ember fiziológiás állapotát, egy külső koncentrátoron keresztül az interneten küldik a valós idejű mérési adatokat a feldolgozó központba, amely képes a szükséges beavatkozásokat, értesítéseket generálni a feldolgozás eredményeképpen. A tipikus test-közeli hálózat (BAN) a következő elemeket tartalmazza: (i) fiziológiás paramétereket mérő érzékelőket; (ii) mozgás detektorokat, pl. gyorsulásmérőket, amelyekkel a megfigyelt személy tartózkodását és mozgását követhetik, (iii) adatátviteli eszközöket, amelyek az előbbi kettő által gyűjtött adatokat eljuttatja a kívánt feldolgozási helyre. Megoldandó feladatok a BAN alkalmazásával kapcsolatosan: 1. Interoperabilitás az eszközök (plug-and-play) és az adatátviteli technológiák (Bluetooth, ZigBee) területén 2. Eszköz kialakítás fontos szempontjai a egyszerűség, kicsinység, kis energiaigény, egyszerű használat és rekonfigurálhatóság (átruházhatóság) 3. Adatvédelem és adatbiztonság az alkalmazás során, vagyis a mért adatok és a beteg összekapcsolása, valamint az egészségügyi adatok korlátozott és ellenőrzött hozzáférhetősége. 4. A személyes szabadság érzetének megőrzése egy ilyen alkalmazás mellett 5. Érzékelők validálása, kalibrálása a biztonságos alkalmazás, a fals riasztások elkerülésére 6. Nem elegendő a BAN által szolgáltatott információ, a feldolgozás egyéb – a betegre vonatkozó – egészségügyi információra is igényt tart. A BAN-on alapuló ellátás/monitorozás/felügyelet az egyéb ellátások integráns részét kell képezze. 92

Wireless Personal Access Network (vezeték nélküli személyi hálózat)

70


7. A zavarok kiszűrése, amely a környezetben működő egyéb hálózatok interferenciájából adódik. 8. A BAN-on alapuló megoldás ára reális alternatívája kell, hogy legyen a hagyományos megoldásoknak. 9. A rendelkezésre állás az alkalmazási időszakra 9999 legyen. 10. A BAN viselhető, elfogadható és nem zavaró kell legyen , amely a viselője napi tevékenységét nem akadályozza. 11. A BAN rendszernek konzisztensnek és robosztusnak kell lennie, a ki- és bekapcsolást követően. A bekapcsoláskor az érzékelőknek kalibráltaknak kell lenni, a hálózati kapcsolatnak minden esetben újra kell élednie.

B.1.5.6 Finanszírozás. A telemedicina alkalmazások tipikusan olyan szolgáltatási modellt alkotnak, amelyben egyaránt megtalálhatóak a közfinanszírozandó és a piaci értékesítésre számot tartó elemek. Nem gondolhatjuk, hogy a beteg kényelmét szolgáló, nem feltétlenül a szükséges ellátások kategóriájába sorolható szolgáltatások közfinanszírozottak lehetnek. Meggyőződésünk viszont az, hogy a közfinanszírozási rendszerbe való befogadás nélkül a telemedicina nem tud tömegesen elterjedni, legalábbis a hazai piac méretét figyelembe véve nem lehet rentábilis a működtetése. Tehát, a finanszírozási modellt ennek figyelembevételével – vegyes modell építésével – kell kialakítani. A finanszírozás pontos meghatározásához alkalmazni kell azokat a pilot-projekteket, amelyek során a szolgáltatás pontos költség elemei kialakulnak.

71


B.2 Az egészségügyi szakellátási szintek specifikus követelményei B.2.1 A szakellátás specifikumai

B.2.1.1 Tranzakció és eseménynaplózás a HIS rendszerekben A felhasználók az adatbázis kezelés és az operációs rendszeren végzett módosítások tevékenységeit naplófájlban kell rögzíteni. Ebből idősorosan megtudhatjuk mikor ki jelentkezett be és mit csinált a szakellátás rendszereiben. A naplózást lehetőség szerint úgy kell beállítani, hogy minél szélesebb körű legyen a tevékenységek naplózása. A napló állományos rendszeres időközönként történő mentéséről gondoskodni kell. B.2-1-00193

B.2-1-002

B.2-1-003

B.2-1-004 B.2-1-005 B.2-1-006 B.2-1-007 B.2-1-008 B.2-1-009 B.2-1-010 B.2-1-011 B.2-1-012

A HIS rendszer működtetésével kapcsolatos eseményeket és az ehhez kapcsolódó információkat tárolni kell (bejelentkezés időpontja, felhasználó név,használt szoftver képernyő azonosító, tevékenység (új adat bevitel, törlés, módosítás, stb.). Az üzemeltetésével kapcsolatos eseményeket egy külön állományban naplózni kell (pl. új verzió betöltés, új adatszótárak betöltése, hibabejelentés és hibaelhárítással kapcsolatos tudnivalók, rendszer újra indítás, tesztelés, stb.). A rendszer részletes (ki, hol, mit, mikor) és könnyen lekérdezhető tranzakciós és eseménynaplózással rendelkezzen minden tranzakcióról (pl: új adat bevitel, adat módosítás, megtekintés, nyomtatás, törlés, adat továbbítás, adat leválogatás stb.) Minden páciens egyedileg és maradandóan legyen az HIS rendszerben azonosítva94. Minden felhasználó egyedileg és maradandóan és idősorosan visszakereshetően legyen a HIS rendszerben azonosítva. Az egészségügyi rendszerbe rögzített minden adatelem minden verziója egyedileg, visszakeseshetően és maradandóan legyen azonosítva a HIS rendszerben. Minden egészségügyi adatelem maradandóan kapcsolódjon össze egy azonosított pácienssel a HIS rendszerben95. Egy egészségügyi adatelem minden változása az elem új verzióját eredményezze a HIS rendszerben96. Az egészségügyi adatelemek verziók idő megjelöléssel (bejegyzés dátumával és idejével) és a módosításért felelős személy azonosítójával ellátva listázhatók legyenek. Az egészségügyi adatelemek verziókövetését úgy kell megvalósítani, hogy a módosított adat eredeti tartalmát is meg kell őrizni. Az egészségügyi adatelem minden verziója érvényességi idővel rendelkezzen. Az egészségügyi adatelemek minden verziója rendelkezzen egy tevékenységi állapottal, státusszal97 (pl.aktív, inaktív, feladott, érkeztetett, teljesített, lezárt, megtörtént vagy elmúlt, befejeződött, megszakadt, archivált, visszautasított,

93

EuroRec: GS002663.02 A rendszert fel kell arra készíteni, hogy a páciens bármely kűlső azonosítóinak megváltozása esetén is a rendszerben az azonosítás, megfeleltetés egyértelműen megadható legyen 95 Lehetőséget kell biztosítani paciens adatok összefűzésére és szétválasztására (lásd a késöbbiekben) 96 Törlés nem megengedett ! 97 A státuszok megnevezése rendszerenként változhat 94

72


B.2-1-013 B.2-1-014 B.2-1-015 B.2-1-016 B.2-1-017 B.2-1-018

stb.) Egy egészségügyi adatelem minden verziója mellett kerüljön tárolásra az adat, amely azonosítja azt az aktor-t (személyt vagy automatát) aki ténylegesen rögzítette az adatot, adatokat. Az egészségügyi adatelemek változtatásainak teljes története legyen prezentálható 98. A rendszer tegye lehetővé a felhasználó számára az egyes egészségügyi adatelemek bizalmas kezelésének jelölését. A rendszerben törlésre jelölt adatok fizikálisan ne törlődjenek a rendszerből. Egy egészségügyi adatelem törlésének eredménye egy új változata legyen ennek az egészségügyi adatelemnek, "törölve" státusszal. A rendszerbe szerkesztett dokumentumok, dokumentum elemek (szekciók, bekezdések) előző verziói is megtekinthetők legyenek.

B.2.1.2 Az egészségügyi dokumentumok adatvédelmi elvárások

adatvédelmével

kapcsolatos

Az egészségügyi informatikai rendszerek, a páciensek egészségi állapotra vonatkozó személyes adatokat és az azokhoz kapcsolódó klinikai vizsgálati és finanszírozási adatokat, egészségügyi dokumentumokat, képi információkat, terápiás és gazdasági adatokat tartalmaznak. Az egészségügyi informatikai rendszerekben tárolt adatok védelme érdekében folyamatosan karbantartott tűzfal és folyamatosan frissített vírusvédelmi rendszerrel (a szervereken, klienseken)99 kell az adatkezelőnek rendelkeznie. A vékony kliensek vírusvédelmével is foglalkozni kell!

98 99

B.2-2-001

Minden egészségügyi dokumentumot és annak minden verzióját egyedi azonosítóval és a létrehozás időpontának a megjelöléssel kell ellátni.

B.2-2-002

Minden egészségügyi dokumentumnál egyértelműen azonosítani kell tudni a rögzítésének helyét (orvosi munkahely kódja) és a rögzítés idejét.

B.2-2-003

Meg kell jelölni az adat rögzítőjét és a tartalomért felelős személyt (lehet azonos). A két felelősnek a rendszerben azonosíthatónak kell lennie.

B.2-2-004

Az egészségügyi dokumentumokat a kezelő/adatrögzítő szerint is le kell tudni lekérdezni.

B.2-2-005

Az egészségügyi dokumentumoknak az alábbi státuszok valamelyikével kell rendelkezni: aktív, jóváhagyott, törölt, előző verzió. A státuszt minden esetben meg kell jeleníteni.

B.2-2-006

Az egészségügyi rendszerekben a dokumentumokhoz opcionálisan biztosítani kell a hitelesítés és időpecsét szolgáltatás használatának lehetőségét.

B.2-2-007

A rendszer minden adatbeviteli képernyőn minimálisan a következő adatokat

EuroRec: GS001598.02 A tűzfalak és a vírusvédelem specifikációjával és minimális elvárásaival ez az anyag nem foglalkozik.

73


kell ki jelezni:   

a páciens intézményen belüli egyedi azonosítóját az adott kezeléshez tartozó egyedi megrendelés azonosítót a páciens nevét.

B.2-2-008

A HIS rendszernek lehetővé kell tennie, hogy rendszergazda joggal rendelkező személy – és csak ő – erre a célra kialakított felületen teljes körűen menedzselje a jogosultságokat (felhasználói profilt hozzon létre, függesszen fel és töröljön, illetve módosítsa egy felhasználó jogosultságait).

B.2-2-009

A HIS rendszer rendszergazdai tevékenységeket megváltoztathatatlan módon naplózni kell.

B.2-2-010

A HIS rendszer felhasználóinak és adminisztrátorainak olyan szintű képzést kell kapniuk100, hogy a feladataikat önállóan el tudják végezni.

B.2-2-011

A páciens egészségügyi adataihoz való hozzáférést minden esetben meg kell előznie a előírás szerinti HIS felhasználói azonosításnak.

B.2-2-012

A felhasználó orvos/szakdolgozó a HIS rendszerekben csak azokhoz a páciensekhez és páciens adatokhoz férhet hozzá, amelyekhez jogosultsága van.

B.2-2-013

A rendszernek biztosítania kell a törvény szerinti páciens adatokhoz történő hozzáférés beállíthatóságát a szerepkörhöz kötött működést és beállításokat (pl.kezelőorvosi, háziorvosi szerepkör)101

B.2-2-014

A HIS rendszernek biztosítania kell, hogy az arra jogosultsággal rendelkező felhasználó megváltoztasson, vagy töröljön egészségügyi, vagy adminisztratív adatokat. A módosított/törölt adatokat tárolni kell a módosítás/törlés indoklásával, a módosító személy nevével és a változtatás időponttal együtt. Ezeket az adatokat különösen indokolt (kiemelt rendszergazdai jogosultsággal) esetekben meg kell tudni jeleníteni102.

B.2-2-015

A rendszernek biztosítania kell, hogy a páciens vagy az ő általa meghatalmazott egészségügyi személy hozzáférhessen az elektronikus betegdokumentumokhoz vagy azok egy részéhez. A hozzáférés módját a helyi informatikai biztonsági szabályzatban kell meghatározni. Az autorizáció és az autentikáció szintjét és az elérhető adatok körét a rendszerben rögzíteni kell. A meghatalmazott személy páciens adatokhoz való hozzáférését naplózni kell biztonsági és audit célokra, ugyanígy a szolgáltatást nyújtó adatelérését is naplózni kell.

B.2-2-016

A HIS rendszernek meg kell felelni a vonatkozó hazai adatvédelmi és adatkezelési jogszabályoknak.

100

Részletesen lásd az oktatásoknál. A jogosultságot még idő és hozzáférési hely szerint is lehet paraméterezni. 102 Törvény által szabályozott esetekben. 101

74


B.2-2-017

A rendszer biztosítania kell, hogy azonosítsa, tárolja és listázni tudja a személyzet minden tagját, akik hozzáférhetnek és hozzáfértek a páciens dokumentumaihoz és klinikai vizsgálati adataihoz 103.

B.2.1.3 Az alkalmazásokkal kapcsolatos jogosultság kezelés

B.2-3-001

A rendszer tegye lehetővé a Megrendelő hozzáférési és jogosultsági policyének implementálását. A megajánlott rendszer legyen az SSO-ra felkészítve (a rendszerbe való belépéskor a felhasználónak mindössze csak egyszer kelljen azonosítania magát és ezután a rendszer minden erőforrásához és szolgáltatásához további autentikáció nélkül engedjen hozzáférést).

B.2-3-002

A rendszer támogassa az intézmény biztonsági politikájának megfelelő jelszókezelést. Ha az intézmény nem rendelkezik biztonsági politikával/szabályzattal, akkor az alábbi jelszókezelési szabályokat kell alkalmazni:

B.2-3-002-1 B.2-3-002-2 B.2-3-002-3

B.2-3-002-4

B.2-3-002-5 B.2-3-002-6 B.2-3-002-7 B.2-3-002-8 B.2-3-003 B.2-3-003-1 B.2-3-003-2 B.2-3-003-3

o A felhasználók egyszerű felületen saját maguk tudják a jelszavukat megváltoztatni. o A jelszó legalább 8 karakterből áll, melyben kisbetű, nagybetű és szám is van. o A jelszavát minden felhasználónak magának meg kell tudni változtatni. o A jelszót 1-3 havonta104 legyen kötelező megváltoztatni, a változtatásra a rendszernek a lejárat előtt XX105 nappal és ezután minden hozzáférésnél újra figyelmeztetnie kell a felhasználót. A rendszer figyelje az előző jelszavakat és ne engedjen előzőleg már használt jelszót használni a felhasználónak. o Amennyiben a jelszó lejár, új, egyszer használatos jelszót kell kérni a rendszeradminisztrátortól, amelyet azonnal meg kell változtatni. o A jelszavakat csak vissza nem fejthető formában szabad tárolni. o Jelszót tilos telefonban, e-mailben, sms-ben vagy bármely más nem titkosított csatornán átadni, erre figyelmeztetni kell minden felhasználót. o Sürgősségi esetre ki kell dolgozni a rendszer hozzáférés-kontroll felülbírálatának lehetőségét. A jogosultság alapja a személy ellátásban betöltött szerepe kell, hogy legyen. o A felhasználó csoportok jogosultságát lehessen egyszerűen egy-egy106 személyhez hozzákapcsolni vagy elvenni o Legyen mód szerepkörökhöz kötődő másolható sémák létrehozására, amelyet az adott felhasználó adatainak beállításával lehessen személyre szabni. o A felhasználók HIS alkalmazáshoz történő hozzáférési jogosultságát személyre és szerepkörre szabottan (egy természetes személy több

103

Eurorec: GS005466.02 Legyen a rendszerben szabadon paraméterezhető. 105 Legyen a rendszerben szabadon paraméterezhető. 106 Eurorec: GS001512.01 104

75


szerepkörben is lehet és az adatvédelmi törvény miatt ehhez különböző jogosultságok tartozhatnak) lehessen megadni. B.2-3-004

Időszakos és csökkentett funkcionalitású jogosultságot lehessen kialakítani107.

B.2-3-005

A rendszerben felhasználóként rögzített személyek adatait és a hozzájuk kapcsolódó naplóbejegyzéseket ne lehessen törölni csak a hozzáférés jogosultságát felfüggeszteni.

B.2-3-006

A rendszer használatára jogosult felhasználók paraméterezhető napló állományt kell tudni készíteni.

B.2-3-007

A HIS rendszer rendelkezzen olyan jogosultságmátrix kezelő rendszerrel, amelyben legyen mód egy-egy felhasználó hozzáférési jogosultság beállításával kapcsolatos összes funkció és opciós beállítást, tevékenységek végzésével kapcsolatos minden jogosultságot lehetőség szerint egy funkción belül beállítani (új felvétel, megtekintés, megnyitás, szerkesztés, módosítás, jóváhagyás, nyomtatás, átemelés, validálás, stb.). A rendszernek a jogosultság beállításokat naplózni kell.

B.2-3-008

A nevesített HIS felhasználók listája legyen nyomtatható.

tevékenységéről

B.2.1.3.1 Digitális aláírás, hitelesítés A rendszer legyen felkészítve az egészségügyi üzenetek digitális aláírásának megvalósítására és a finanszírozó által támogatott elektronikus hitelesítési eljárásokra. A rendszernek támogatnia kell az finanszírozó által támogatott elektronikus B.2-4-001 orvosi-, és szakdolgozói hitelesítési és azonosítási módokat A megajánlott rendszer legyen képes digitális aláírással és időpecséttel ellátott B.2-4-002 beérkező dokumentumok fogadására és a HIS rendszerben történő tárolására. A megajánlott rendszer legyen felkészítve digitális aláírás modul használatára annak érdekében, hogy az aláírásra kijelölt végpontokon és folyamatlépésekben lehetőség legyen az ezt elváró rendszerek felé küldendő B.2-4-003 dokumentumok megjelenítésére és aláírására valamint időpecséttel való ellátására.

B.2.1.4 ISO OID (Object IDentifier – egyedi azonosító) rendszer használata

B.2-5-001

Az ISO OID-k (Object IDentifier – egyedi azonosítók) rendszerének formális definícióját az X.208 (ASN.1), míg az OID-k kódolására vonatkozó ajánlást az X.209 ITU-T ajánlás tartalmazza. Mivel a hazai és nemzetközi egészségügyi szabványok kötelező attribútumaikban alapvetően építenek az OID-k rendszerére 108, a szabványos kommunikáció és dokumentumok kialakításához szükséges az egészségügyi informatika területéhez kapcsolódó OID-rendszer használata.

107

Például konzíliárusok számára. A HL7 közösség – saját használatára – 2001. óta mintegy 4800 OID-t regisztrált a 2.16.840.1.113883 (joint-iso-itut.country.us.organization.hl7) node alatt. http://www.hl7.org/oid/index.cfm 108

76


B.2-5-002

Az egészségügyi informatikai rendszerek legyen felkészítve az egységes ágazati portálon publikált az ágazatban használt közhiteles és közcélú adatok, illetve az egyes rendszerek működtetéséhez kapcsolódó nyilvános adatok, eljárásrendek, fogalomtárak, jelentések specifikációi, szolgáltatások specifikációi, metamodellek, validálási szabályok, kódszótárak, nyilvántartások, szabályok, kommunikációs előírások és protokollok automatikus letöltésére és a rendszerbe integrálására.

B.2-5-003

Az egészségügyi megoldásszállító legyen regisztrálva a magyar ISO OID rendszerben, legyen hozzáférése a rendszerek működtetéséhez szükséges OID szótárakhoz.

B.2-5-004

Az egységes ágazati kommunikáció érdekében a HIS rendszerekben használni kell a közhitelesen publikált magyar ISO OID rendszerben közzétett kódszótárakat és nyilvántartásokat.

B.2.1.5 Kódok, kódszótárak, nyilvántartások, szabályok Az egészségügyi -ágazat szervezeti felépítése, bonyolult intézményrendszere, a gyógyítás szakterületi sokasága, a mindig egyedi volta sok adat- és kódszótárat feltételez. Az egészségügyi informatikai rendszerek sok egyedi kódszótárat használnak. A kódszótárak rendszeres időközönkénti frissítése, verziókövetése, rendszerbe integrálása a hibátlan szakmai működés egyik legalapvetőbb feltétele.

B.2-6-001

B.2-6-002 B.2-6-003

B.2-6-004

B.2-6-005

109 110

Az egészségügyi informatikai rendszer idősorosan verziózva tartalmazza a korrekt működés szempontjából elengedhetetlenül fontos kódszótárakat. Például o az egészségügyben az orvosi, ápolási és a finanszírozási adatok leírásához szükséges kódszótárakat (BNO, WHO, OENO, HBCS, stb.), o a működtetéshez szükséges közhiteles kódszótárakat (pl: orvoskódok, OEP kódok,stb.) o a beküldő egészségügyi intézményekkel kapcsolatos azonosítókat (pl. háziorvosok azonosítói, stb.) A megajánlott rendszer tartalmazza és kezelje az vonatkozó aktuális törzsadatokat és szabályzatokat109 A kódrendszerek idősorosan visszakereshető verziókövetését támogatni kell a rendszernek. A megajánlott rendszerbe az egészségügyi intézet kérésére szakmaspecifikus és egyéb (pl: Európai szakmai társaságok kódrendszerei) és intézet specifikus kódszótárak valamint marker kódok legyenek illeszthetők kialakíthatók.110 A megajánlott rendszerben legyen mód dátumhoz kötött idősoros nyilvántartásra, amely a kódszótárakat verzió szerint tudja kezelni (érvényesség kezdete, érvényesség vége) úgy, hogy a megjelenítéskor mindig az adott időpontnak megfelelő adattartalom kerüljön kijelzésre illetve kinyomtatásra.

pl: HBCS besorolási szabályok, járó szabálykönyv,stb. Amennyiben az egészségügyi intézmény egyedi adatok rendszerbe integrálását kéri abban az esetben meg kell adni az adat forrását.

77


B.2-6-006 B.2-6-007 B.2-6-008

B.2-6-009

B.2-6-010 B.2-6-011

A kódszótárakban lehessen kódra és/vagy szótöredékre keresni. Lehessen a szótárban előforduló mezőkre növekvő illetve csökkenő sorrendbe rendezni. Amelyik szótár egyedi egyéb rendszerezési móddal is rendelkezik annál azt a módot is meg kell tudni jeleníteni111 (pl. BNO). Az egészségügyi informatikai rendszerekben használt közhiteles kódszótárakat és a velük kapcsolatos használati útmutatókat legyenek mindig szinkronban a közhiteles publikáció szerintivel. Az egészségügyi informatikai rendszer legyen felkészítve arra, hogy meghatározott időközönként (mely legyen kódszótáranként vagy nyilvántartásonként egyedileg beállítható) ellenőrizze, letöltse és a rendszerbe integrálja lehetőség szerint minden olyan kódszótárat, nyilvántartást, szabályrendszert, stb. amely a rendszer használatához szükséges. A rendszer legyen felkészítve a Kooperatív térrel történő kapcsolat felépítésére és kétirányú, naplózott adatkommunikációra. A rendszer legyen felkészítve a Kooperatív térben publikált elemek (kódok, nyilvántartások, eljárások, adatküldési rekordképek, stb.) letöltésére és rendszerbe integrálására.

B.2.1.6 Betegadminisztrációs rendszer A HIS rendszerek működésének legalapvetőbb modulja a betegadminisztrációs rendszer. Ezen modulban tárolt adatok struktúrája sajnálatos módon nem egységes ezért nem könnyű a rendszerek közötti páciens megfeleltetés. A modul adatmezői nagyon sok „„ és „különleges” adatot112 tartalmaznak, ezért adatvédelmi szempontból is kiemelt figyelmet kell rá fordítani. Az anyag mellékletében összefoglaljuk az ezen modultól elvárt minimális funkcionalitást. B.2-7-001 B.2-7-002 B.2-7-003 B.2-7-004 B.2-7-005 B.2-7-006

A rendszerben minden egyes páciens számára külön rekord legyen létrehozható113. A rendszer alkalmas legyen a személyi adatok idősoros követésére114 (pl. névváltozás115, igazolvány szám változás, lakcím megváltozása116, telefonszám változás, stb.) A rendszer akadályozza meg, hogy több páciens rekordja ugyanahhoz a társadalombiztosítási azonosítóhoz legyen rögzítve117. A rendszer tegye lehetővé mindazon demográfiai adatok gyűjtését, amelyeket jogszabály vagy egyéb szabályzat előír118. A demográfiai információt mint diszkrét adatot tárolja az EHR-be. A rendszernek tárolnia kell tudni igény alapján legalább egy kapcsolattartó személyt a kapcsolattartó információval. (telefon, e-mail)119 Minél több természetes azonosító120 alapján lehessen keresni (minimális elvárás: vezetéknév, keresztnév, anyja neve, születési dátum, nem, lakhely,

111

(pl. fejezetek szerinti tagozódás, fogalmi hierarchia, kereszthivatkozások, külső hivatkozások stb.) Lásd: 1992. évi LXIII. Törvény 1. fejezet 2. § 1-2 pont 113 Eurorec: GS001513.03 114 Eurorec: GS002875. 01+GS003961.01+GS003961.01+ GS003962.01+GS003963.01 (A rendszer nyomon tudja követni a beteggel kapcsolatos demográfiai, családi állapot, nemi, személyes és adminisztratív adatváltozásokat). A log állományokból megtekinthetők legyenek az előző verziók a módosító személye és a módosítás dátuma. 115 Eurorec: GS001521.02 116 Eurorec: GS001522.01 117 Eurorec: GS005620.01+ GS005621.01 118 Eurorec: GS001523.03+ GS001525.02+ GS001526.03 119 Eurorec: GS002875. 01 112

78


B.2-7-007

B.2-7-008 B.2-7-009 B.2-7-010 B.2-7-011 B.2-7-012 B.2-7-013 B.2-7-014

B.2-7-015 B.2-7-016

B.2-7-017

B.2-7-018 B.2-7-019

lakcím)121 Minél több nem természetes azonosítót lehessen a rendszerbe rögzíteni és a rögzített azonosítók alapján keresni122: o központilag generált egyedi azonosítók, pl. TAJ szám, o a rendszer által generált egyedi azonosító, esetazonosító, megrendelés azonosító, vonalkódos azonosító stb. o intézeti egyedi azonosítók, pl.: karton szám, felvétel azonosító, média azonosító stb. A pácienshez kapcsolódó biztosítással és a majdani finanszírozással kapcsolatos adatok idősoros nyilvántartása (biztosítottság, biztosító(k), stb.) Az On-line jogviszony ellenőrzésre legalább két független módon legyen lehetőség (pl: Interneten és mobil net). Műszaki hiba esetén a rendszer automatikusan váltson át a tartalék megoldásra123. On-line jogviszony és jogosultság ellenőrzés124 biztosítása mindenhol ahol a törvényi előírások elvárják. A megvalósított rendszerben meg kell oldani, hogy naponta egynél többször ne legyen egy betegnél TAJ szám ellenőrzés (TAJ szám proxy kialakítása). Betegmozgás adatok naplózása125 (felvétel, távozás, áthelyezés, elbocsátás, más intézetbe helyezés, átvétel más intézettől, elhalálozás, adaptációs szabadság stb.) Legyen mód beteg adatok összefűzésére126 és szétválasztására127. Sürgős esetben legyen egyszerűsített felvételre lehetőség128 Paciensek közötti kapcsolat lehessen idősorosan naplózott módon rögzíteni129 és eltávolítani (pl:anya-gyerek(ek), gyámság stb.). A betegadminisztrációs rendszer folyamatosan bővíthető dokumentumsablon130 tárat tudjon kezelni (új beillesztése, módosítás131, törlés stb.). A dokumentumsablon tárba lehessen a törvények, jogszabályok és az egészségügyi intézmény által előírt dokumentumsablonokat, formanyomtatványokat beilleszteni melyeknek a kinyomtathatóságát és a példányszámát lehessen funkciókhoz rendelni (pl. egy páciens felvételekor automatikusan nyomtatódjon ki a személyi adatok kezelésével kapcsolatos beleegyező nyilatkozat, betegazonosító karszalag, stb.) A páciens rendelkezése szerint a HIS rendszerben tárolt adatok adathozzáférését lehessen korlátozni, titkosítani A betegadminisztrációs rendszerhez illeszthetők legyenek(lehetőleg szabványos módon) egyedi külső rendszerek és eszközök 132

120

Természetes azonosító : valamely személy azonosítására használható adat, amelyet nem valamilyen mesterségesen rendelünk az adott egyénhez. 121 Eurorec: GS001519.05 122 Eurorec: GS001518.01 123 Ennek a követelménynek a technikai megvalósítása nem az Betegadminisztrációs rendszer feladata. 124 Műszaki hiba esetén a törvényi előírásoknak megfelelő időszakon belüli automatikus ellenőrzés. 125 pl: intézet, telephely, rendelő, osztály, nővérpult, szobaszám, ágy, … 126 Eurorec: GS001514.02 127 EuroRec: GS003587. 02 128 A sürgősségi műveleteket nevesíteni és naplózni kell. 129 EuroRec: GS002876. 01+ GS002877. 01+ GS002878. 01 130 EuroRec: GS004030.01+ GS001624.01+ GS001627.01 131 Eurorec: GS001625.0+ GS001626.01 132 pl: beteg behívó rendszer

79


B.2-7-020

A betegadminisztrációs rendszernek támogatnia kell az „egy ellátási esemény” megközelítést. Meg kell tudni jeleníteni az adott egészségügyi ellátáshoz kapcsolható összes szolgáltatást és dokumentációt ( elektronikus kórlap funkció).

B.2-7-021

A rendszerben lehetővé kell tenni, hogy amennyiben a páciens egy kutatásban vagy kutatásokban (pl: gyógyszerkiróbálás) vesz részt akkor rögzíteni lehessen a kutatások egyedi azonosítóját oly módon, hogy a kutatást végző orvosokat lehessen azonosítani133.

B.2.1.7 Alapvető járó és fekvőbeteg ellátási funkciók A következő táblázatban összefoglaljuk az alapvető ellátási funkciókat. Az anyag mellékletében összefoglaljuk az ezen moduloktól elvárt minimálisan funkcionalitást. B.2-8-001 B.2-8-002 B.2-8-003 B.2-8-004 B.2-8-005 B.2-8-006 B.2-8-007 B.2-8-008 B.2-8-009 B.2-8-010 B.2-8-011 B.2-8-012 B.2-8-013

Legyen mód ellátási mód változtatására az ellátás ideje alatt (járó-fekvőbe, fekvőből-járóba való átminősítés). Személyhez (pácienshez) köthető orvosi adatok rögzítésére legyen lehetőség (pl: rizikófaktorok, allergia, gyógyszerérzékenység, igazolvány számok és érzékenység, stb.). A rendszerben egyértelműen megkülönböztethető legyen az adott beteggel kapcsolatos fennálló (kurrens) és korábbi problémák134. A rendszer legyen felkészítve arra, hogy a pácienssel kapcsolatos valamennyi aktuális egészségügyi ellátáshoz tartozó problémát megmutatja135. A rendszer tegye hetővé a pácienssel kapcsolatos egy vagy több több klinikai bejegyzéshez kapcsolását (probléma, diagnózis,gyógyszerelés,stb)136 A rendszer lehetővé teszi gyógyszerelési tételek bevitelét és új gyógyszerkészítmény felírását137 A rendszer tegye egyértelművé ha egy gészségügyi adatelemhez pontos szabad szöveget vagy strukturált adatot kell rögzíteni138. Egy tulajdonság hiánya is lehet egészségügyi adat egy adott páciens esetében. A rendszer egy orvos-beteg találkozás alkalmával az adott betegre vonatkozó minden információt képes legyen rögzíteni és megjeleníteni139. Az adott orvosi szakterület által használt és a finanszírozáshoz szükséges kódszótárak biztosításséval támogassa a rendszer használata során a gyors adatbevitelt140. A kódszótárak használatát verziókezeléssel kell ellátni141 Szűkített BNO és OENO törzs definiálhatósága csoportra (pl. osztály) és orvosra, ezek másolhatósága csoportok és orvosok között. Egyedi szakmai kódszótárak lehessen definiálni142 és megjeleníteni a dokumentáció készítés (szerkesztés) kapcsán. Egyedi kódszótárak esetén is biztosítani kell a verzió figyelést (Az adatok lekérdezésekor, megjelenítésekor mindig az adott időszakhoz tartozó érvényes

133

EuroRec: GS005481.02+ GS005516.01 Eurorec: GS001530.01 135 Eurorec: GS001531.02 136 Eurorec: GS001541.02+GS001542.02+GS001543.01 137 Eurorec: GS001549.04+GS001550.06+GS001551.03+GS001554.01-GS001595.01 138 Eurorec: GS001601.04+GS001602.04+ 139 Eurorec: GS001610.03+GS001611.02 140 Eurorec: GS001544.04 141 Az adatok lekérdezésekor, megjelenítésekor mindig az adott időszakhoz tartozó érvényes kódokat kell megjeleníteni! 142 Pl: szakmai kollégiumok vagy nemzetközi társaságok által kiadott kódszótárak. 134

80


B.2-8-014

B.2-8-015

B.2-8-016 B.2-8-017 B.2-8-018 B.2-8-019

B.2-8-020

B.2-8-021 B.2-8-022 B.2-8-023 B.2-8-024 B.2-8-025 B.2-8-026

kódokat kell megjeleníteni!). A legsűrűbben használt laboratóriumi, diagnosztikai, konziliáris kéréseket és terápiákat lehessen osztályhoz illetve orvoshoz rendelni amelyen előre űrlapszerűen megadhatók a kitöltendő adatok. A legsűrűbben rendelt gyógyszerek és magisztrális készítmények rendelése érdekében lehessen osztályhoz illetve orvoshoz recept makrókat és szakorvosi javaslatokat definiálni, amelyen előre megadhatók a kitöltendő adatok (kiszerelés, mennyiség, dózis, megjegyzés, felírás jogcíme, recept típusa, diagnózis). Nyomtatás előtt lehessen az adatokon módosítani. A kitöltött illetve a kinyomtatott receptek és szakorvosi javaslatok verziózva, egyedi azonosítóval ellátva reprodukálható módon tárolódjanak el a rendszerben.

A rendszer sablonokkal támogassa a gyógyszereléssel kapcsolatos adatbevitelt strukturált. Legyen mód a napi szintű adagolást másolására és az irreguláris gyógyszerelés adatbevitelére. A rendszer tárolja és jelezze (rendszeresen frissített és auditált adatbázisból) a használt gyógyszerek mellékhatásait, kontraindikációit. A rendszernek dokumentálnia kell a gyógyszerezés elrendelését, módosítását vagy megszüntetését illetve annak az okát, valamint az rendelő személyét és dátumát és adagolását. A leggyakrabban használt funkciókat (lehetőleg felhasználónként) lehessen csoportba szervezni. A mindennapi működéssel és finanszírozással kapcsolatos ellenőrző listák legyenek definiálhatók a felhasználók által munkahelyenként és összesített formában (pl. nem lezárt események, nem kódolt események, duplikált adatfelvétel, stb.). Az ellátással kapcsolatos adatlapok és naplók kezelése (pl: ambuláns lap, ambuláns napló, adatlap, stb.) A kitöltött illetve a kinyomtatott adatlapok és naplők verziózva, egyedi azonosítóval ellátva reprodukálható módon tárolódjanak el a rendszerben. Beavatkozások közötti időfigyelés lehessen beállítani (előjegyzéseknél is). Finanszírozási adatok egy képernyőn történő rögzítési lehetősége legyen megvalósítva. Onkológiai adatok rögzíthetősége egy képernyőn történő rögzítési lehetősége legyen megvalósítva. A eseteket lehessen markerekkel ellátni a későbbi tudományos munkák legyűjtésének céljára Marker kóddal ellátott esetek könnyű lekérdezési lehetősége legyen megvalósítva a felhasználók számára.

B.2.1.8 Megrendelésekkel kapcsolatos általános elvárások

B.2-9-001

A rendszer legyen felkészítve az alábbi elektronikus (mind belső mind külső szolgáltatótól) szakmaspecifikus struktúrának megfelelő kérő és eredmény beviteli lapok kialakítására:  labor-kérés és eredmény fogadás  diagnosztikai-kérés és eredmény fogadás  konzílium-kérés és eredmény fogadás

81


B.2-9-002

B.2-9-003

B.2-9-004 B.2-9-005

B.2-9-006

B.2-9-007

B.2-9-008

B.2-10-009

B.2-10-010 B.2-10-011 B.2-10-012

Az elektronikus kérőlapok űrlapként143 szabadon létrehozhatók, specifikálhatók, szerkeszthetők (adatbeviteli képernyőn szereplő adatbeviteli mezők és nyomtatási kép), módosíthatók valamint verziózhatók legyenek a végfelhasználó által144. A kitöltött kérőlapok legyenek nyomtathatók az adott időszaknak (idősoros működés elvárt) megfelelő nyomtatási elrendezéssel. A nyomtatás megjelenése a felhasználó által szabadon legyen szerkeszthető (fejléc, kép beemelés (pl. UH kép), adatelemenkénti elhelyezés definiálása, tabulálás, adatbeviteli mező üres karaktereinek levágása, pozícionálás, táblázatos megjelenítés, egyéb a rendszerben tárolt információ egyedi azonosító nyomtatás, betűtípus, betűméret, üres adatmezők elnyomása). A kitöltött illetve a kinyomtatott kérőlapok verziózva, egyedi azonosítóval ellátva reprodukálható módon tárolódjanak el a rendszerben. A rendszerbe rögzített elektronikus vizsgálatok és diagnosztikai kérések mindegyikéből automatikusan lehessen szabványos HL7 v2 és v3 verziójú munkalistát előállítani és kétirányú adatkommunikációt megvalósítani. Képi vizsgálatkérések esetén a képtároló és archiváló rendszerben tárolt (PACS) DICOM szabvány szerinti álló és mozgóképet lehessen egy direkt URL-el megcímezni és a rendszerből való kilépés nélkül egy külön ablakban megjeleníteni vagy egy ingyenes megjelenítő szoftverrel vagy az Megrendelőnél erre a célra alkalmazott speciális képmegjelenítő szoftverével. A képi vizsgálatkéréseket lehessen úgy definiálni, hogy a megrendelés feladásakor a megrendelést feladó rendszerben automatikusan generálódjanak ki és kerüljenek átadásra azok az azonosító(k) amely alapján a későbbiekben mind a feladó rendszerben mind a fogadó szakmai rendszerben egyértelműen azonosítani lehet a vizsgálatot és a hozzá tartoző kapcsolódó állományokat. Amennyiben a képi vizsgálatkérések közül megtekintésére kijelölt képek (álló és vagy mozgó) már archívumban vannak a HIS rendszernek alkalmasnak kell lennie az archívumból történő visszatöltés automatikus elindítására. Modalitásonkéni paraméterezéssel be kell tudni állítani az automatikus prefetching (előbeolvasás) funkciót. A paraméterezés során be lehessen állítani azt, hogy a visszatöltés modalitás típusonként hány vizsgálatra vonatkozzon. A prefetching funkciót elindító tevékenység (pl. vizsgálatkérés feladása a HIS rendszerben) legyen a rendszerben definiálható. A megrendelés feladásával egy időben megfelelő jogosultsági szint esetén a rendszer tegye lehetővé a hozzáférést a korábban a képalkotó vizsgálatokhoz145. A rendszer figyelmeztesse a felhasználót, ha egy megrendelt képalkotó vizsgálatot végeztek a közelmúltban146.

B.2.1.9 Labor kommunikációval kapcsolatos alapvető elvárások A következő táblázatban összefoglaljuk a HIS labor kommunikációval kapcsolatos alapvető elvárásokat. Az anyag mellékletében összefoglaljuk az ezen modul(ok)tól elvárt minimálisan 143

Az űrlapokkal kapcsolatos elvárások ezen anyag részét képezik. A felhasználó tudjon az adatmodellben létrehozni új kulcs érték párokat melyeket elhelyezhet az űrlapon illetve a nyomtatáson. 145 EuroRec: GS005762.01 146 EuroRec: GS005763.01 144

82


funkcionalitást.

B.2-11-006

Az „Orvosi Laboratóriumi Vizsgálatok Szakmai Kollégiuma” és az egészségügyi intézmény szakmai igényeknek előírásainak és a laboratórium struktúrájának megfelelő kérőlapok legyenek kialakíthatók a rendszerben. Az egészségügyi intézmény szabadon definiálhasson kéréscsoportokat működési egységenként.147 A kéréscsoport feladásakor  ne legyen kötelező a csoport minden elemét megrendelni,  lehessen annak megrendelendő elemeit szabadon kiválasztani,  legyen mód egy darab vizsgálat feladására,  legyen mód a kéréscsoport kiegészítésére is. A rendszer legyen felkészítve különböző típusú és rendszerű vonalkódok használatára a minta egyedi azonosításához (vonalkód nyomtatás, címke felhelyezés, vonalkód és minta összerendelés, minta érkeztetés, adatbevitel vonalkód olvasóval). A rendszer automatikusan naplózza a kéréshez tartozó kiegészítő adatokat (kérés dátuma, OENO kód, megrendelő orvos, berögzítő személy, stb.) Legyen mód a labor átvétel előtt a kérés törlésére.

B.2-11-007

Legyen mód a már feladott rendeléshez kapcsolódó utánrendelésre.

B.2-11-008

A kéréseket lehessen sürgősségés prioritás szerint osztályozni148.

B.2-11-001 B.2-11-002

B.2-11-003

B.2-11-004

B.2-11-005

B.2-11-009

B.2-11-010 B.2-11-011 B.2-11-012 B.2-11-013

B.2-11-014

B.2-11-015

B.2-11-016 B.2-11-017 147 148

Legyen mód a laboratóriumba beékezett (érkeztetett) kéréscsoportot plusz kérésekkel kiegészíteni a labor részéről amennyiben az elvégzett vizsgálatok eredményeként a szakma szabályai szerint kiegészítő vizsgálatok indokoltak. A labor által kért vizsgálatok az eredeti kérés eredményeivel együtt (ne új rendelésszámon) kerüljenek vissza a kérő egészségügyi alkalmazásba. Speciális szakmaspecifikus kérések kezelése, a mérési eredmények megjelenítése és nyomtatása (pl: protrombin lista) ütemezhető időpontban. A kérésekhez társíthatók legyenek a mintavételi edények. Az osztályos vérvételi munkalistán és a labor számára készülő anyagátvételi listán egységenlént választható módon kerüljön feltüntetésre a mintavételi edény típusa. Egyes vizsgálatkérések megrendelését lehessen jogosultsághoz (a jogosultság kötődhet például személyhez, végzettséghez, stb. ) kötni. Minden vizsgálatnál lehessen beállítani figyelést, amely figyelmeztetést küld akkor, ha egy vizsgálatot egy határnap előtt újra kíván a felhasználó megrendelni. (A határnapot egészségügyi intézmény szabadon tudja definiálni). Lehessen mátrix és laser nyomtatóval is osztályonként szabadon paraméterezhető (a listán szereplő elemek, azok sorrendje, hossza, rendezettsége,stb) mintavételi listát nyomtatni, amely egyben anyag „átadásátvételi” kísérő listaként is funkcionál. A kérések és a validált eredmények automatikusan töltődjönek át a rendszerek között (HIS - Labor). Legyen mód vizsgálatokat időben előre megrendelni.

Pl: osztályonként, nővérpultonként, ambulanciánként, stb. EuroRec: GS003711. 01+ GS003712. 01

83


B.2-11-018 B.2-11-019 B.2-11-020 B.2-11-021 B.2-11-022 B.2-11-023 B.2-11-024 B.2-11-025 B.2-11-026 B.2-11-027 B.2-11-028 B.2-11-029 B.2-11-030 B.2-11-031 B.2-11-032 B.2-11-033 B.2-11-034

B.2.1.10

A finanszírozási adatok automatikusan kerüljenek át a labor rendszerből az HIS rendszerbe. Legyen mód a labor vizsgálatok eredményét a páciens dokumentumaiba beemelni149. A vizsgálatok eredményének beszúrása legyen automatizálható (pl. tevékenységhez köthető, funkcióhoz köthető, stb.) A visszaérkezett labor leleteket lehessen akár többször is mátrix és laser nyomtatón is kinyomtatni az intézet és az intézeten belüli szervezeti egység által meghatározott formátumokban és gyakorisággal. Legyen mód egy páciens több megjelenésen átívelő egyes vizsgálati elemeinek idősoros nyomtatására (esetleg grafikus megjelenítésére). Lehessen összesítőt nyomtatni az osztály adott időszakra vonatkoztatott megrendeléseiről a megrendelő lapon szereplő adatok mindegyikére vonatkoztatva(pl:vizsgálatonként, beküldő orvosra és szervezetre bontva ). Legyen mód egyes vizsgálatok elvégzését ütemezni. (pl: TSH csak 2 hetente kerül elvégzésre). A labor eredményekkel együtt kerüljön át a labor programból a HIS rendszerbe az adott betegnek (kor, nem) megfelelő referencia tartomány150. Legyen lehetőség a kóros eredmények figyelemfelkeltő jelölésére. (pl.*) A HIS rendszerbe átkerült labor leleten jelenjen meg a leletet validáló személy neve, beosztása. Megfelelő tagolással lehessen megjeleníteni a több frakciós vizsgálatok eredményeit. Minden vizsgálati eredménynek lehessen számszerű és szöveges eredménye is. Külső labor eredményeit manuálisan is lehessen a rendszerbe rögzíteni. A HIS rendszer automatikusan figyelmeztesse a felhasználót a beérkező rendellenes laboratóriumi eredményekre151. Legyen mód összehasonlító és összegző listák készítésére a kért és elvégzett vizsgálatokról. A megajánlott rendszer rendelkezzen szabványos (pl: HL7) külső labor illesztéséhez kidolgozott szabványos illesztési felülettel152. A laboratóriumi leletek tartalmazzák a beérkező kérés regisztrálásának dátumát és idejét153. A laboratóriumi leletek tartalmazzák a Minta állapotával kapcsolatos megjegyzéseket154.

Dokumentum kezelés (szerkesztés és nyomtatás)

A következő táblázatban ismertetjük a HIS rendszer egészségügyi dokumentum kezelésével és kommunikációval kapcsolatos alapvető elvárásokat. Az anyag mellékletében (X.X fejezet) összefoglaljuk az ezen modultól elvárt minimálisan funkcionalitást.

149

Részleteket a dokumentumszerkesztésnél EuroRec: GS003704. 02 151 EuroRec: GS003703. 02 152 EuroRec: GS003705. 01 153 EuroRec: GS005944.01 154 EuroRec: GS005945.01 150

84


B.2-12-001 B.2-12-002 B.2-12-003 B.2-12-004 B.2-12-005 B.2-12-006

B.2-12-007

B.2-12-008

B.2-12-009 B.2-12-010 B.2-12-011 B.2-12-012 B.2-12-013

B.2-12-014 B.2-12-015 B.2-12-016

A dokumentum szerkesztő szoftver az irodai alkalmazások piacán megszokott grafikus kezelői felülettel rendelkezzen. Az ikonok használata egyértelműen feleljen meg az ipari standardoknak155. Az alkalmazásokban használt betűtípusok legyenek következetesek és könnyen olvashatók156. A rendszer szabványos szerkesztési funkciókat használjon a dokumentumok szerkesztésekor (pl. beszúrás, másolás, törlés, keres, cserél,stb)157. A dokumentum szerkesztő ablak legyen átméretezhető annak érdekében, hogy jól áttekinthető legyen szerkesztés közben a dokumentum. Az egészségügyi informatikai rendszer minden modulja egységes szövegszerkesztőt használjon dokumentumok szerkesztésére158. Az egészségügyi informatikai rendszer tegye lehetővé, hogy bármely egészségügyi dokumentumhoz, szöveges megjegyzést lehessen fűzni. Az egészségügyi informatikai rendszerben a szakma szabályai szerint megszokott „bekezdések” legyenek szabadon kialakíthatók (anamnézis, státusz, stb.) a rendszerben. Tetszés szerintiszámú új „bekezdést” tudjon a Megrendelő definiálni. A „bekezdések” kívánt sorrendben történő megjelenítésével szabadon definiálható legyen egy-egy szakterület lefedő dokumentumok összessége. Egy típusú dokumentumot (pl. ambuláns lelet, zárójelentés,stb.) más-más szakterület különféle képpen tudjon összeállítani. A rendszerben a jogosult felhasználó a folyamatban lévő bejegyzéseket, dokumentumokat is tudja szerkeszteni159. A dokumentum mintákat lehessen kötni intézethez, osztályhoz, részleghez, ambulanciához, személyhez. A nyomtatási kép összeállítása szabadon definiálható legyen (csak azok a bekezdések és űrlapok kerüljenek nyomtatásra, amit a felhasználó definiál). A nyomtatandó dokumentumot lehessen kétoldalasan nyomtatni és megadható legyen a példányszám160. A rendszer rendelkezzen olyan időtúllépési (timeout) funkcióval, amely lezárja és elmenti a nyitott munkamenet-t egy beállítható időn túli inaktivitás esetén161 A rendszer lehetővé teszi, hogy ugyanazon beteg egy vagy több Elektronikus Egészségügyi Rekordjai egyetlen Elektronikus Egészségügyi Rekordban legyen egyesíthető162 A páciens minden Elektronikus Egészségügyi Rekordja egyedileg és maradandóan azonosítható a rendszeren belül163 A megszerkesztett dokumentumok verzió kezelése legyen a rendszerben egységesen megoldva. A dokumentumok minden módosított verzióját tárolni kell.

155

EuroRec: GS003753.01 EuroRec: GS003754.01 157 EuroRec: GS002619.01 158 EuroRec: GS003611. 01 159 Eurorec: GS001614.03 160 Eurorec: GS001607.03 161 EuroRec: GS002655.02 162 Eurorec: GS001516.03 163 Eurorec: GS002307.02 156

85


B.2-12-030

A megszerkesztett dokumentumok nyomtatási verzió kezelése legyen a rendszerben megoldva. A dokumentumok minden nyomtatott egyedi azonosítóval kell ellátni és minden verzióját tárolni kell. A dokumentum szerkesztésével kapcsolatos jogosultságok legyenek személyhez kötötten beállíthatók164 (minimális elvárt jogok: olvasás, új dokumentum létrehozása, módosítás, jóváhagyás, nyomtatás, törlés). A dokumentum szerkesztésével kapcsolatos események legyenek követhetők, verziózottak. Dokumentumszerkesztés közben (a szerkesztésből való kilépés nélkül) a pácienssel kapcsolatos a rendszerben tárolt adatok, dokumentumok, képek, leletek, kódolt információk, előjegyzési adatok, stb. legyenek megtekinthetők. A megtekintés során, egyszerű módon legyen lehetőség a megtekintett leletek, kijelölt szövegrészek és képek átemelésére. Legyen mód -munkahelyenként eltérő módon - a rendszerben tárolt leletek és eredmények automatikus, de rendszerezett módon történő csoportos beemelésére165. A leleteket az egészségügyi intézménnyel egyeztetett csoportosításban és rendezettségi módon kell tudni a dokumentumokba beemelni. Legyen mód – munkahelyenként eltérő módon - a rendszerben tárolt eredmények táblázatos módon történő megjelenítésére. Kiválasztható legyen a táblázatosan megjelenített adatok köre. Legyen mód munkahelyenként és lelettípusonként különböző leletbeemelési módot kiválasztani. A diagnosztikus munkahelyek vizsgálati eredményeit diagnosztikák szerinti csoportosításban (időrendi sorrendben) lehessen beemelni a szerkesztett dokumentumba). Legyen mód a dokumentált gyógyszeres terápia részletes és hatóanyag szerinti leírására és a dokumentációba történő automatikus beemelésre. A rendszer tegye lehetővé a gyógyszerkészítmények felírását a hatóanyag (ok) nevének megadásával is166. A rendszerből kinyomtatandó dokumentumokban lehessen grafikus elemket167 is elhelyezni.168 Lehessen elhelyezni olyan rajzokat, amelyeken színezni vagy jelölni lehet a dokumentumból történő kilépés nélkül. Ezek a rajzok kerüljenek a dokumentumhoz kötötten verzióval ellátva tárolásra. A jogszabályok által előírt dokumentumokat és a jelenleg használt dokumentumokat lehessen létrehozni.169 A létrehozott elektronikus dokumentumok legyenek validálhatók.

B.2-12-031

A dokumentum szerkesztés legyen szöveges makrók definiálásával segítve.

B.2-12-032

A makrók különböző csoportjai legyenek képezhetők (intézeti, osztályos és orvosonként egyedi).

B.2-12-017

B.2-12-018 B.2-12-019

B.2-12-020

B.2-12-021

B.2-12-022 B.2-12-023 B.2-12-024 B.2-12-025 B.2-12-026 B.2-12-027 B.2-12-028 B.2-12-029

164

EuroRec: GS002618.01 pl. az összes kémiai labor leletet lehessen vizsgálat típusonként csoportosan dátum szerint emelkedő sorrendbe beemelni EuroRec: GS003126. 02 167 A beillesztett grafikus elem felbontása meghatározza, hogy milyen felbontású és technikájú nyomtató szükséges a beillesztett elem megfelelő minőségű kinyomtatásához. 168 pl: fejlécben embléma, ultrahangos kép, rajz, stb. 169 beutalók, kérőlapok, igazolások, nyilatkozatok, stb 165 166

86


B.2-12-033 B.2-12-034 B.2-12-035 B.2-12-036 B.2-12-037 B.2-12-038 B.2-12-039 B.2-12-040 B.2-12-041 B.2-12-042

B.2-12-043 B.2-12-044 B.2-12-045 B.2-12-046 B.2-12-047 B.2-12-048

B.2-12-049

B.2-12-050 B.2-12-051

Makrókat az intézet megfelelő jogosultságú (jellemzően adminisztrátor) felhasználói maguk is tudjanak létrehozni. A makrókat egy rövid névvel vagy más egyéb egyszerű módon lehessen a szerkesztés közben beilleszteni. A rendszerben legyen lehetőség statikus és dinamikus űrlapok kialakítására170. Bármilyen szabványosan illesztett nyomtatón ki lehessen nyomtatni a dokumentumot. Nyomtatáskor lehessen választani az alapértelmezett és egyéb alternatív nyomtatók között. Nyomtatás előtt lehessen a kész dokumentumot megtekinteni és módosítani. Nyomtatás előtt lehessen a kész dokumentumot megtekinteni (nyomtatási kép). A megajánlott rendszer legyen felkészítve az egészségügyben használatos szokásos171 és speciális nyomtatásra172. A nyomtatási funckó legyen rugalmas papírméret, nyomtatási terület beállíthatósága tekintetében pl: legyen mód nyomdai úton előre nyomtatott fejléces papírra nyomtatni. A dokumentumokat lehessen file-ba nyomtatni. Utólagos dokumentum nyomtatás esetén az eredeti dokumentum elkészítésének időszakában érvényes adatok és kódok kerüljenek a dokumentumra. A dokumentum nyomtatási képe feleljen meg az eredeti dokumentum készítés időszakának. A dokumentumokhoz beállítható legyen, hogy mikor tekintjük őket véglegesnek. A végleges dokumentumokat lehessen egy erre a célra kialakított tárházba (repository-ba) exportálni. Az exportálás szerkezetét lehessen beállítani. Az exportált repozitoriban arra jogosultsággal rendelkező személyek tudjanak keresni és nyomtatni. A repository-ban a dokumentumhoz csatolva kerüljenek exportálásra (pl: HL7 formátomban) a dokumentum keletkezéséhez kapcsolódó, valamint az ellátási adatok is. A dokumentumok nyomtatási képei idősorosan (tól-ig érvényességgel) tárolódjanak a HIS rendszerben. A rendszer legyen felkészítve arra, hogy a végleges dokumentumokat (egy előre definiált formátumban) alkalmas legyen a Kooperatív tér számára továbbítani. A rendszer legyen felkészítve arra, hogy a Kooperatív tér számára továbbítandó dokumentum formátumok leíró állományait a tér egy jól meghatározott részéről rendszeres időközönként letöltse. A rendszer legyen felkészítve arra, hogy különböző EHR exract kéréseket tudjon szabályos (szabványos) formátumban fogadni és küldeni a Kooperatív téren keresztül. A rendszer legyen felkészítve arra, hogy különböző a Kooperatív téren keresztül érkező EHR exract kéréseket tudjon értelmezni és szabályos

170

Az űrlapokkal kapcsolatos elvárások ezen anyag részét képezik. leporelló, A4, A5 172 Új és régi recept,egyedi etikett, csuklópánt, karton nyomtatás, CD lemez feliratozás 171

87


(szabványos) formátumban tudjon EHR extract-ot automatikusan összeállítani és küldeni a térbe.

B.2.1.11

Statikus és dinamikus űrlapok173

A statikus űrlapok és dinamikus űrlapok használatával az eddig papír alapon rögzített űrlap adatok elektronikus úton történő előállítását, kinyomtatását, mentését és az űrlapokon rögzített információk azonnal a rendszer adatbázisába kerülését kívánjuk megvalósítani. Az űrlapokat önálló dokumentumokként is lehessen használni (dokumentum B.2-13-001 típusokhoz rendelni vagy dokumentumokba beágyazni) és tárolni. 174 B.2-13-002 A rendszer tegye lehetővé az űrlapok használatát adatok export céljára . Előre meghatározott módon, már adatbázisban tárolt adatok automatikusan B.2-13-003 megjeleníthetők legyenek egy új űrlap szerkesztésének kezdetekor. Az űrlapok egyes előre meghatározott mezőit lehessen paraméterezhető B.2-13-004 módon default értékkel feltölteni. Az űrlapok mezőihez lenyíló menüs választásban kódszótárakat lehessen B.2-13-005 rögzíteni. Az űrlapokra minden olyan adat „elhelyezhető” legyen, amely a HIS rendszer B.2-13-006 egészségügyi adatbázisában szerepel. Az adatlap kitöltése során bevitt adatok felhasználásával előre definiált B.2-13-007 matematikai képlet(ek) alapján számítási műveletek végződjenek el (pl. testfelszín számítás). A számított értéket tartalmazó mezőben a számításban résztvevő adatok B.2-13-008 kitöltése után azonnal jelenjen meg a számított érték. A képernyőn el kell helyezni egy „számol” gombot melynek segítségével a B.2-13-009 számolást bármikor újra el lehet végezni. A rendszert fel kell készíteni arra ha az űrlap egy előre definiált mezője, ha B.2-13-010 egy meghatározott értéket vesz fel abban az esetben automatikusan kerüljön meghívásra egy másik űrlap (pl:fertőző beteg bejelentése). Lehessen elhelyezni olyan rajzokat, amelyeken színezni vagy jelölni lehet az B.2-13-011 űrlapból történő kilépés nélkül (pl. ápolási lapon a decubitusok helyét). Ezek a rajzok kerüljenek a dokumentumhoz kötötten verzióval ellátva tárolásra. B.2-13-012 Az űrlapba lehessen képet beemelni. Az űrlapszerkesztés közben (kilépés nélkül) legyenek elérhetők és megjeleníthetők az intézeti PACS rendszerben tárolt álló és mozgóképek. Ez a B.2-13-013 szolgáltatás feltételezi egy DICOM konverter vagy egy gateway szolgáltatást nyújtását, lehetővé téve ezáltal licenszdíj nélküli megtekintő használatát. Az informatikai szállító feladata a megvalósítás kezdeti fázisában a szervezeti működési struktúrában szereplő összes egység statikus és dinamikus űrlap B.2-13-014 igényét felmérni. A felmérés során kapott eredmények alapján az informatikai szállító feladata az adatbázis bővítés elkészítése és a szükséges űrlapok kialakítása. A rendszert fel kell arra készíteni, hogy egyedi űrlapokat lehessen (regiszter B.2-13-015 űrlapok) definiálni melyek a kitöltés után automatikusan a Kooperatív térbe továbbítódnak (például: regiszter adatok).

173 174

Az űrlap olyan adatbázis-objektum, amelyet az adatbázis-alkalmazások felhasználói felületének létrehozására lehet használni. EuroRec: GS003734. 01+ GS003735. 01

88


B.2.1.12

Recept

A recept írás az egészségügyi alkalmazások sajátossága. A recept író szoftvereket auditáltatni kell a jelenleg érvényes törvények értelmében. A jelenlegi törvényi előírások ki fognak bővülni az e-recept kialakításával kapcsolatba. A recept író szoftverek újbóli auditja szükséges. B.2-14-001 B.2-14-002 B.2-14-003 B.2-14-004 B.2-14-005 B.2-14-006 B.2-14-007 B.2-14-008 B.2-14-009 B.2-14-010 B.2-14-011 B.2-14-012 B.2-14-013 B.2-14-014 B.2-14-015 B.2-14-016

A receptíró szoftver megajánlott verziója rendelkezzen a törvény által előírt szervezet auditjával. A receptíró szoftver működése során sem a választható gyógyszerkészítmények körét, sem azok sorrendjét nem befolyásolják promóciós szempontok175. Lehessen a nemzeti, jogszabályi előírásoknak megfelelő receptet nyomtatni (formai és tartalmi megfelelőség, extra vonalkód, stb.)176. A szoftver által használt gyógyszertörzs frissítési technológiája és folyamata biztosítsa az OEP által közzétett gyógyszertörzzsel való tartalmi egyezőséget177. A szoftver által használt gyógyszertörzs frissítési úgy legyen megvalósítva, hogy a gyógyszertörzs frissítéséhez ne kelljen a HIS rendszerrel leállni. Recept készítés közben egyértelműen jelezni kell a felhasználónak a képernyőn amennyiben a rendszerben lévő gyógyszertörzs lejárt178. A rendszer tegye lehetővé a vényekkel kapcsolatos felügyeleti szolgáltatások aktiválását és deaktiválását179. Az Ajánlattevő feladata a mindenkor aktuális és hatályos gyógyszer adatbázis határidőre történő beimportálása a rendszerbe. A rendszer képes egy adott betegnek egy adott gyógyszerkészítmény szabálytalan adagolási sémájának beáállítására is180. A rendszer az adagolásra vonatkozó szöveges utasításokat (pozológiát) tartalmazó adatokat is tartalmazza (az elektronikus recept esetében is)181. A szoftver a megszokott színek alkalmazásával segítse a helyes gyógyszerválasztást A gyógyszerkészítmények kódolt listája tegye lehetővé az ATC osztályok szerinti gyógyszer keresést182. A rendszer kezeljen minden jogcím szerinti gyógyszert (normatív, emelt indikációhoz kötött, kiemelt indikációhoz kötött, stb.). A rendszer a gyógyszerfelíráskor mutassa a gyógyszerkészítmény jogi kategóriáját, azaz hogy az adott készítmény vényköteles-e vagy sem183. A különböző betegség csoportokhoz tartozó referencia készítmények az előírás szerint jelölve legyenek a rendszerben A recept készítő program tudjon kezelni magisztrális készítményeket és gyógyászati segédeszközöket is.

175

EuroRec: GS004793.01 EuroRec: GS004698.02 177 EuroRec: GS004753.01 178 EuroRec: GS004790.01+ GS004853.01 179 EuroRec: GS004869.02 180 EuroRec: GS004947.01 181 EuroRec: GS004563.02+ GS004592.02 182 EuroRec: GS004796.01 183 EuroRec: GS004994.01 176

89


B.2-14-019

Lehessen az Ajánlatkérőre jellemző specifikus magisztrális készítményeket rögzíteni. A vények felírása során a magisztrális készítményekkel kapcsolatos finanszírozási információkat tegye elérhetővé184. A kitöltött illetve a kinyomtatott receptek szakorvosi javaslatok és azok tartalmi elemei (név, adagolás, stb.) verziózva, egyedi azonosítóval ellátva reprodukálható, másolható módon tárolódjanak el a rendszerben185. A receptírás legyen sablonokkal támogatott.

B.2-14-020

A receptíró sablonokat lehessen szerepkörhöz kötni.

B.2-14-021

A felírt gyógyszerkészítmények számát egyértelműen jelzik a recepten 186.

B.2-14-017

B.2-14-018

B.2-14-022 B.2-14-023 B.2-14-024 B.2-14-025 B.2-14-026 B.2-14-027

B.2-14-028

B.2-14-029

B.2-14-030

B.2-14-031

B.2-14-032 B.2-14-033

A rendszer tegye lehetővé új vények felírását korábbi vény vagy kezelés módosításával, az összes adat újbóli bevitele nélkül187. A gyógyszerkészítmény-lista megjelenítésekor a rendszer megjeleníti az információ-forrás eredetét és dátumát188. A rendszer minden gyógyszer felírásnál jelezze a gyógyszer teljes árát és a páciens által fizetendő árat. Egy gyógyszer felírásánál a rendszer ellenőrizze és jelezze ki a felíró jogosultságát az adott szer felírására, a páciens jogosultságát a gyógyszer igénybevételére és az esetleges költség limiteket. A rendszer figyelmeztesse a felhasználót amennyiben a jogosultságokat, ill. a limiteket nem tudta ellenőrizni189. A gyógyszer adatbázist meghatározott időközönként (jelenlegi jogszabályi előírás szerint minimum havonta egyszer) frissíteni kell. Ha az adatbázis nincs frisstíve, akkor a felhasználó kapjon figyelmeztető jelzést erről. A rendszernek lehetővé kell tennie, hogy egy receptet szabványos kommunikáció során elektronikus úton továbbítsanak az OEP e-recept központjába, vagy egy gyógyszer kiadhatóságát a központon keresztül elektronikusan visszavonják. A rendszernek lehetővé kell tennie, hogy egy receptre felírt gyógyszer kiadhatóságát a központon keresztül elektronikusan visszavonják. A rendszer a recept felírásakor figyelmeztesse a felhasználót a páciens előző egészségügyi rekordjaiban szereplő allergiából, intoleranciából, hatástalanságból, vagy nem kívánt reakciókból következtethető potenciális allergiás reakciókra, intoleranciára, hatástalanságra, vagy nem kívánt reakciókra. A rendszer tegye lehetővé a társadalombiztosítással kapcsolatos járulékos információk megjelenítését a gyógyszerkészítmények listázásakor pl. ATC osztály vagy indikáció szerint190. A rendszer automatikusan tegyen javaslatot a páciens-specifikus adagolásra, súly, kor, nem, vese és májfunkciók alapján. A nem megfelelő adagolásról a rendszer figyelmeztesse a gyógyszer felíróját. A rendszer képes dokumentálni és tárolni az elektronikusan feírt vényeken

184

EuroRec: GS004648.01 EuroRec: GS004876.01 EuroRec: GS004872.01 187 Eurorec: GS004849.01 188 EuroRec: GS004801.01 189 EuroRec: GS004990.01 GS004991.01+ GS004992.01+ GS004993.01 190 EuroRec: GS004800.03 185 186

90


B.2-14-034 B.2-14-035 B.2-14-036 B.2-14-037

B.2-14-038

B.2-14-039 B.2-14-040 B.2-14-041

B.2-14-042 B.2-14-043 B.2-14-044 B.2-14-045

B.2.1.13

történt változtatásokat illetve megszüntetéseket és azok okát. Az előzőekben felírt gyógyszerkészítmények (a vényfelírási előzmény) ATC osztályok szerint legyenek rendezhetők191. A rendszer lehetővé teszi a gyógyszerkészítmények indikációk szerinti kiválasztását192. A rendszer lehetővé teszi a felhasználónak, hogy a listázott gyógyszerkészítményeket betűrend szerint rendezze193. A rendszer lehetővé teszi a gyógyszerkészítmény-lista alapértelmezett rendezési módjának kiválasztását194. A rendszer tegye lehetővé a vények felírása során a gyógyszerkészítmények finanszírozási szükséges űrlapok (szakorvosi vélemények) elkészítését, szerkesztését, nyomtatását és szükség esetén elektronikus formában történő elküldését a finanszírozó felé195. A gyógyszeradatbázis tudományosan megalapozott információkat szolgáltasson az interakciós figyelmeztetések esetén követendő eljárással kapcsolatban196. A rendszer a vények felírása során opcionális módon a készítmények külföldi megfelelőivel kapcsolatos információkat is tegye elérhetővé197. Gyógyszerkészítmény felírása közben a rendszer figyelmeztessen, ha a felírt dózis meghaladja a bármilyen indikációnál megadott legmagasabb ajánlott dózist198. Gyógyszerkészítmény felírása közben a rendszer figyelmeztesse a felhasználót, ha a felírt dózis kevesebb, mint a bármilyen indikációnál megadott legkisebb ajánlott dózist199. A rendszer a ténylegesen kiadott gyógyszerkészítményről kiegészítő azonosítót is tárol, amennyiben az különbözik a felírttól200. Kábítószer vagy doppingszer felírásakor a rendszer figyelmezteti a felhasználót201. A rendszer legyen felkészítve az Elektronikus vények szabványos üzenetküldő rendszereken valo továbbítására202.

Erőforrás ütemezés

Az erőforrás ütemező rendszer az egészségügyi intézmény azon logisztikai eleme amelynek segítségével a szervezet működését optimalizálni lehet. Természetesen nem csak az intézet hanem a páciensek és a beutaló intézmények érdekeit is szem előtt kell tartani az erőforrás ütemezés során. Az erőforrás ütemező fontos paramétere a törvényben is előírt web-es kétirányú kapcsolattartás.

191

EuroRec: GS004792.01 EuroRec: GS004797.02 193 Eurorec: GS004798.01 194 Eurorec: GS004799.01 195 Eurorec: GS004731.01 196 Eurorec: GS004852.02 197 Eurorec: GS004649.02 198 Eurorec: GS004863.01+GS004861.01 199 Eurorec: GS004862.02 200 Eurorec: GS004984.01 201 Eurorec: GS004085.02+ GS004086.01 202 Eurorec: GS003706. 01 192

91


B.2-15-001 B.2-15-002 B.2-15-003 B.2-15-004

B.2-15-005 B.2-15-006 B.2-15-007

B.2-15-008

B.2-15-009 B.2-15-010 B.2-15-011 B.2-15-012 B.2-15-013 B.2-15-014

B.2-15-015

Legyenek erőforrás ütemező modul(ok) a HIS rendszerbe integrálva (közös adatbázisok, kódszótárak). Az erőforrás ütemezést egy interoperábilis külső alkalmazáson keresztül is el lehessen érni203. A rendszer tegye lehetővé, hogy az erőforrás ütemező rendszer automatikusan küldjön és fogadjon ütemezési adatokat204 Az erőforrás foglaláshoz lehessen automatikus humán erőforrás rendelést (orvos, szakápoló, beteghordó), anyagrendelést (pl. kontrasztanyag) és egyéb speciális rendelést (pl. betegszállítás) hozzákötni. Az erőforrás rendeléshez kapcsolt minden rendelésről egyedileg és összesítetten is lehessen paraméterezhető formában kimutatást kérni képernyőre és nyomtatásba. Legyen lehetőség az erőforrások időbeni és kapacitásbeli feltérképezésére és az erőforrás ütemezéséhez szükséges adatok rögzítésére. A vizsgálat típusától függően lehessen több típusú időrést kialakítani és foglalni. Minden olyan eszközre, vizsgálatra, konzíliumra, műtétre, diagnosztikai vizsgálatra, helységre illetve személyre lehessen kialakítani olyan házon belüli ütemező rendszert, amely lehetségessé teszi:  a rendelkezésre álló kapacitások rögzítését  a rendelkezésre álló erőforrás kvótázását  foglalást  foglalás törlését205  foglalás átütemezését  a foglalás átütemezése esetén a foglaláshoz kapcsolódó egyéb vizsgálatok és diagnosztikai kérések átütemezését Az erőforrás ütemező modulnak legyen webes kapcsolata (erőforrás kiajánlás, erőforráskérés fogadás, erőforrás kérés visszaigazolás, erőforrás kérés átütemezés, törlés). Az erőforrás ütemező rendelkezzen önálló jogosultság kezelő rendszerrel. Az erőforrás ütemező modul egy-egy erőforrásra vonatkozóan rendelkezzen több (minimum 4) kvótázási lehetőséggel. A kvótákat különböző jogosultsággal lehessen elérni. Az erőforrás ütemező modul rendelkezzen olyan outputtal, amely segítségével az adott erőforráshoz ütemezett adatok megjeleníthetők és kinyomtathatók206. Az erőforrás ütemezőbe rögzített adatok alapján lehessen kiértesítő levelet és borítékot nyomtatni vagy e-mailt generálni. Az erőforrás ütemező modul rendelkezzen olyan képernyővel, amelynek segítségével az adott erőforrás egy-egy napjára, időszakára ütemezett betegek könnyedén207 átütemezhetők legyenek egy másik időpontra. Az erőforrás ütemező modul rendelkezzen olyan módon paraméterezhető felülettel amelynek a segítségével a felhasználók munkahelyenként egyedileg tetszőleges módon beállíthassák a képernyőn a nyomtatásban megjelenítendő

203

Eurorec: GS001876.02 Eurorec: GS002163.01 205 Foglalás törlése esetén automatikusan szabaduljon fel a lefoglalt időkeret 206 A megjelenítés és a nyomtatási képen megjelenő adatok legyenek felhasználó által szabadon változtathatók, paraméterezhetők. 207 A képernyő elhagyása nélkül felugró ablakok és egér segítségével lehessen az átütemezést elvégezni. 204

92


B.2-15-016 B.2-15-017

B.2.1.14

adatokat (az adatelemeket, az adatok sorrendjét, a megjelenítés pozícióját és hosszát, rendezés módját). Az erőforrás ütemező modult úgy lehessen meghívni (egy új ablakba) a HIS rendszerből, hogy ne kelljen az éppen aktuális munkafolyamatból kilépni. A rendszer figyelje a várólistákat és az ezzel kapcsolatos törvény által előírt várakozási időket208.

Lekérdező modul

A HIS rendszerben tárolt adatok tetszés szerinti feltétel rendszer szerinti lekérdezhetősége, elengedhetetlenül fontos az egészségügyi ellátó napi szakmai munkájának áttekintése, tudományos jellegű munkák adatgyűjtése és az egészségügyi intézmény menedzsmentje, számára. A lekérdezett adatokat tudni kell egyedi elvárások szerint kiexportálni a továbbfeldolgozás és a rendszerek közötti adatkommunikáció érdekében. B.2-16-001 B.2-16-002 B.2-16-003

B.2-16-004 B.2-16-005 B.2-16-006 B.2-16-007 B.2-16-008 B.2-16-009 B.2-16-010 B.2-16-011 B.2-16-012

A megajánlott eszköz tegye lehetővé az Ajánlatkérő HIS adattárában szereplő információk adatbázison belül történő feldolgozását209. Az adatok lekérdezése során ne legyen szükség az adatok mozgatására a különböző adattároló eszközök között. Legyen lehetőség a felhasználó vagy azok egy csoportjának számára időzített és ütemezett lekérdezések konfigurálására. Az időzített adatlekérdezések adatait lehessen egy előre definiált vagy egy egyedi formátumban, azonos vagy változó állomámánynéven más rendszerben készült feldolgozó program számára kiajánlani, elérhetővé tenni210. Legyen lehetőség a lekérdezések grafikus megjelenítésére. A lekérdezés során előállt adatok szabványos adatformátumban211 legyenek kimenthetők további feldolgozás céljából. Az Ajánlattevő alakítsa ki az egészségügyi intézmény specifikus lekérdezéseit biztosító képernyő felületeket melyen a különféle szűréseket biztosító mezők definiálva legyenek. A szűrő mezőket lehessen default értékre beállítani. Az Ajánlattevő alakítsa ki az egészségügyi intézmény specifikus lekérdezéseit biztosító nyomtatási felületeket. A lekérdezést lehetővé kell tenni minden rendszerben tárolt adatra. Legyen lehetőség az időzített lekérdezési eredmények történő továbbítására (pl: levélben vagy elektronikus üzenet formájában. Amennyiben az adatbáziskezelőhöz illeszkedő lekérdező vagy adatbányászati eszköz létezik, úgy lehetőség szerint ezt kell a felhasználó rendelkezésére bocsátani aszülséges licensszámban. A Megrendelő szakembereit fel kell készíteni arra, hogy önállóan új lekérdezéseket tudjanak definiálni a rendszerben.

208

Eurorec: GS002617.01 A hozzáférések számát az adott intézet határozza meg. A hardvereszközök méretezésénél az általános lekérdező modul teljesítményigényével is kalkulálni kell. 210 dinamikus és automatikus riport export funkciók. 211 pl: txt, csv, xls 209

93


B.2.2 A betegfelvétel során elvárt minimális funkcionalitás

B.2.2.1 Páciens adatkezeléssel kapcsolatos funkciók 1. Új beteg adatainak regisztrálása 2. Beteg felvétel 3. Betegkapcsolatok megadása (szülő, gyerek, férj, feleség,stb.) és megszüntetése 4. Visszarendelés(ek) követése 5. Járó és fekvőbeteg felvételi és finanszírozási adatok felvétele 6. Felvétel sztornózás212 7. Páciens törzsadat bevitel 8. Paciens törzsadat lista 9. Áthelyezés intézeten belül másik osztályra 10. Költöztetés 11. Távozás (elbocsátás az intézetből) 12. Távozás sztornózás 13. Páciens törzsadatainak törlése 14. Más intézetbe való áthelyezés, átvétel 15. Áthelyezés sztornózás 16. Előfelvétel (tervezett befekvéseknél használandó funkció. A várólistára vétel is ide tartozik) 17. Előjegyzésből történő felvétel 18. Nővérpult betegnyilvántartás 19. Gyors felvétel213 újszülöttek). 20. Osztályos betegkeresés 21. Betegrekordok összefűzése (duplán vagy hibásan felvett betegek adatainak összefűzése) 22. Betegek intézeten belüli mozgásának követése (felvétel, osztályos áthelyezés, költöztetés (osztályon belül másik épületbe, emeletre, szobába vagy ágyra ) 23. Férőhelyek megjelenítése. 24. Beteg felvilágosítás 25. Adatok titkosítása a páciens kérésére

B.2.2.2 Előjegyzés, ellátás ütemezés 26. Előjegyzés kezelésre (finanszírozási kódonként, szakrendelésenként és orvosonkénti bontásban) 27. Várólista kezelés (intézeten belül és az OEP rendszerében szinkronizáltan) 28. Kétirányú kommunikáció a Kooperatív tér és a finanszírozó központi rendszerével,

B.2.2.3 Biztosítás, finanszírozás 29. Biztosítási adatok bevitele, ellenőrzése 30. Jogviszony és jogosultság on-line ellenőrzési lehetőség (OJOTE kontroll) 31. Finanszírozási adatok bevitelének lehetősége és a bevitel ellenőrzése. Előbesorolás.

B.2.2.4 Dokumentumszerkesztés 32. Járó és fekvőbetegekkel kapcsolatos dokumentumok nyomtatása (beleegyező 212 213

Eurorec: GS004008.01 A legalapvetőbb adatok hiánya (pl: név,TAJ szám nélküli is)nélküli felvétel pl. eszméletlen beteg.

94


nyilatkozatok, kórlap, adatlap, E-adatlap, stb.) 33. Adatlap nyomtatás 34. Adatlapok kitöltése és nyomtatása (pl: patológiai) 35. Várólistával és betegfogadási listával kapcsolatos nyomtatási feladatok 36. Beteg behívással kapcsolatos feladatok 37. Speciális nyomtatványok elkészítése (nyomtatás tasakra, etikett nyomtatás, stb.) 38. Munkalisták nyomtatása. Pl:  Bennfekvő betegek listája  Nővérpult betegnyilvántartás, ágytérkép  Gyorsfelvételek listája  Nem ellenőrzött TAJ számú páciensek listája, stb. 39. Ellenőrző és hibalisták nyomtatása (pl: betegek összefűzésekhez, ambuláns napló) 40. A megajánlott rendszernek rendelkeznie kell portai funkcióval. A portai funkció segítségével információt kell tudni szolgáltatni az egészségügyi intézményben benn lévő és a nemrég távozott betegekről amennyiben a páciens az információ megadását nem tiltotta meg. B.2.3 A Járóbeteg szakellátás során elvárt minimális funkcionalitás

B.2.3.1 Páciens adatkezeléssel kapcsolatos alapvető funkciók 1. Rendelésenkénti napi behívási lista kezelése (listára vétel, listáról levétel, behívás, törlés a listáról, visszatétel a listára, stb.) 2. Felvétel 3. Gyorsfelvétel (olyan felvételi mód amelynél nincs mód a páciens minden kötelező adatának kitöltésére) 4. Leletezés 5. Továbbküldés saját és más intézetbe 6. Diagnózis bevitel 7. Beavatkozás bevitel 8. Különböző típusú recept nyomtatás lehetősége (általános, közgyógy, EU, gyógyászati segédeszköz, stb.) 9. Naprakész gyógyszer adatbázis megléte a rendszerben, kölcsönhatás figyelés 10. Megrendelés feladás (diagnosztika, vizsgálatkérés, stb.) 11. Ambuláns lap és ambuláns napló kezelése 12. On-line beutalók, konzílium és vizsgálatkérések generálása 13. On-line leletfogadás és megtekintés 14. Ellátási forma utólagos megváltoztatás (pl:járóbeteg fekvőbe átminősítés)

B.2.3.2 Előjegyzés, ellátás ütemezés 15. Előjegyzés kezelésre (szakrendelésenként és orvosonkénti bontásban) a. Előjegyzések felvitele, módosítása, törlése b. Előjegyzés adatainak nyomtatása 16. Betegfogadási listakezelés a. Felvétel b. Törlés c. Módosítás d. Átütemezés 95


e. Listák nyomtatása 17. WEB-es kommunikáció a törvény szerint

B.2.3.3 Biztosítás, finanszírozás 18. Biztosítási adatok bevitele ellenőrzése 19. Jogviszony és jogosultság on-line ellenőrzési lehetőség 20. Betegfogadási és várólisták adatküldő állományának előállítása 21. Finanszírozással kapcsolatos tevékenységek a. Finanszírozási adatok bevitele b. Biztosítási adatok rögzítése és ellenőrzése c. Fekvőből visszarendelésnél határnap figyelés d. Lezáratlan esetekről hibalista e. Kikódolatlan esetekről hibalista f. TAJ ellenőrzés g. TAJ ellenőrzés hiányáról hibalista

B.2.3.4 Ambuláns dokumentumok kezelése (szerkesztés és nyomtatás) 22. Ambuláns lelet készítés és nyomtatás a szakma szabályai szerinti tagolás szerint 23. Ambuláns betegforgalmi napló 24. Várólistával és betegfogadási listával kapcsolatos nyomtatási feladatok 25. Adatlap nyomtartás 26. Dokumentumok nyomtatása (beleegyező nyilatkozatok, lelet, beutaló, stb.) 27. Speciális nyomtatványok elkészítése (recept, etikett nyomtatás, stb.) 28. Munkalista nyomtatás 29. Ellenőrző és hibalisták nyomtatása (pl: ambuláns napló, előjegyzési adatok, elszámolási listák, stb.) 30. Lista megtekintés nyomtatás előtt

B.2.3.5 PACS illesztés 31. Az intézeti PACS rendszerben tárolt képi információk és leletek legyenek elérhetők a szakrendelői programból történő kilépés nélkül (az intézeti rendszer automatikusan hívja meg és jelenítse meg a kiválasztott vizsgálathoz tartozó képi információt). 32. A PACS rendszerben tárolt képek leletbe történő illesztésére és nyomtatására legyen engedélyezett. B.2.4 A fekvőbeteg szakellátás során elvárt minimális funkcionalitás

B.2.4.1 Páciens adatkezeléssel kapcsolatos alapvető funkciók : 1. A leggyakrabban használt fekvőbeteg adminisztrációs funkciókat lehessen (felhasználó típusonként esetleg felhasználónként) csoportba szervezni. 2. Legyen mód a beteggel kapcsolatos mozgások osztályon történő rögzítésére (pl: áthelyezés). 3. A fekvőbeteg adminisztrációs rendszer kezelje az egészségügyben előforduló betegmozgásokat  felvétel, felvétel törlése,  átminősítés fekvőből járóba vagy más finanszírozási formába,  áthelyezés intézeten belül, 96


 áthelyezés más intézetbe,  visszavétel más intézetből,  elbocsátás, elbocsátás törlése,  távoztatás, távozás törlése,  adaptációs szabadság, 4. Újszülöttek esetén legyen mód TAJ szám nélkül is felvételre majd az adatok pótlására. 5. Tetszőleges számú statikus és dinamikus űrlapot lehessen az osztályok adatbeviteli elvárásának megfelelően definiálni. 6. Sürgős esetekben biztosítani kell a gyors betegfelvételt. Ilyen esetben legyen mód TAJ szám nélkül is az ellátáshoz szükséges megrendelés elektronikus megrendelésére (labort, diagnosztika, konzílium, műtétet, stb.). 7. Személyhez köthető orvosi adatok rögzítésére legyen lehetőség (pl: rizikófaktorok, allergia, gyógyszerérzékenység, stb.) 8. Elektronikus és szükség esetén papíros labor-kérés és automatikus eredmény fogadás kerüljön megvalósításra. 9. Elektronikus és papíros konzílium-kérés és eredmény fogadás 10. Ápolási tevékenység rögzíthetősége 11. Elektronikus gyógyszerrendelés 12. Szűkített BNO és OENO törzs definiálhatósága csoportra (pl. osztály) és orvosra. 13. Beavatkozás csoportok szűkítése osztályra 14. Legyen mód az esetfinanszírozott eszközök rögzítésére 15. Legyen mód az élelmezési adatok rögzítésére 16. Napi létszám jelentés (új, áthelyezett, távozott, meghalt páciensek listája)

B.2.4.2 Felvételtervezés, várólista kezelés 17. Felvételtervezés a. Tervezett felvétel rögzítése, módosítása, törlése, átütemezése b. Tervezett felvétel adatainak nyomtatása különböző szempontok szerint 18. Várólista kezelés a. Felvétel b. Törlés c. Módosítás d. Átütemezés e. Listák nyomtatása f. Web-es kommunikáció a törvény szerint

B.2.4.3 Biztosítás, finanszírozás 19.Biztosítási adatok bevitele ellenőrzése 20. Finanszírozással kapcsolatos tevékenységek: a. Finanszírozási adatok bevitele b. Biztosítási adatok rögzítése és on-line ellenőrzési lehetősége c. Fekvőből visszarendelésnél határnap figyelés d. Lezáratlan esetekről hibalista e. Kikódolatlan esetekről hibalista f. TAJ ellenőrzés g. TAJ ellenőrzés hiányáról hibalista h. Havi tetszőleges számú HBCS elő besorolás futtatásának biztosítása i. HBCS optimalizálás 97


j. Határnap figyelés. k. Garanciális idő figyelés

B.2.4.4 Fekvőbeteg dokumentumok kezelése (szerkesztés és nyomtatás) 21. Az Ajánlatkérő elvárásai szerint tudjon a rendszerbe új dokumentumokat, statikus és dinamikus űrlapokat szerkeszteni, beilleszteni, funkcióhoz csatolni. 22. A dokumentumot lehessen funkcióhoz esetleg munkaállomáshoz kapcsolni. 23. A jelenleg használt dokumentumok elkészítése az Ajánlattévő feladata (pl:kórlap, beleegyező nyilatkozatok, zárójelentés, kérőlapok, diagnosztikai kérések, konzílium kérések, vér rendelés, a visszaérkezett eredmények listái, stb.).

B.2.4.5 PACS illesztés 24. Az intézeti PACS rendszerben tárolt képek legyenek elérhetők a szakrendelői programból. 25. A PACS rendszerben tárolt képek leletbe történő illesztésére és nyomtatására legyen engedélyezet B.2.5 Az elektronikus kórlaptól és lázlaptól elvárt minimális funkcionalitás 1. 2. 3.

4.

5.

6.

Az elektronikus kórlap és lázlap elkészítésének kiindulója a jelenlegi meglévő papír alapú dokumentáció legyen. Az elektronikus kórlap és lázlap szervesen illeszkedjen az ápolási dokumentumokhoz. Az elektronikus kórlapnak és lázlapnak legyen kapcsolódása (automatikus átemelési lehetősége) az ápolási dokumentáció azon részeivel ahol az elrendelések találhatók (pl. gyógyszer rendelés, vizsgálatok elrendelése, terápia beállítása, stb.) A Terápiás feladatok elrendelésével kapcsolatos adatok rögzíthetők legyenek  Elrendelő neve, beosztása  Az elrendelt feladat neve és kódja  Gyakoriság, időpont  Dózis  Beadás módja  Intervallum  Felfüggesztés, folytatás, csere, elmaradás  Indoklás  Az elrendelés validálása Vizsgálat és konzílium kérésekkel kapcsolatos adatok rögzíthetők legyenek  Elrendelő neve, beosztása  Az elrendelt kérés neve és kódja  Időpont  A mintavétellel kapcsolatos információk  Szállítás módja  Kérés törlése, indoklás  Az elrendelés validálása Dokumentum típusonként illetve betegenként legyen beállítható a kötelezően kitöltendő mezők alapértelmezett értéke 98


7. 8. 9. 10.

11. 12. 13.

Az Ajánlatkérő maga tudjon új elektronikus kórlapot lázlapot vagy terápiás lapot létrehozni. Az Ajánlatkérő maga tudja a felmerülő változtatási igényeket az elektronikus dokumentumon elvégezni. Az elektronikus kórlapnak és lázlapnak legyen kapcsolódása az élelmezési rendszerrel (pl. diéta elrendelés legyen átemelhető az élelmezési rendszerbe). Az elektronikus kórlap és lázlap rendelkezzen betegre szóló gyógyszerelési és gyógyszer rendelési funkcióval (az elrendelés alapján készüljön betegre és osztályra szóló gyógyszer rendelés összesítő mely formájában úgy nézzen ki, hogy validálás után elektronikus megrendelésként is szolgálhasson a gyógyszertár felé). A dokumentációk vezetésének befejezésével legyen mód elektronikus validálásra. Az elektronikus kórlap modulban vezetett adatok alapján legyen mód ad az egyedi lekérdezésekre, mely segít az elvárásokkal szembeni megfelelésben. A rendszerbe csatolható legyen szabványos formátumú fényképet, szkennelt képet és hangfelvételt mint eKórlap adatot214.

B.2.6 Az ápolási dokumentációtól elvárt minimális funkcionalitás Az ápolási dokumentáció készítését az 1997. CLIV. Egészségügyi Törvény kötelezővé tette, része az egészségügyi dokumentációnak. Minden betegnek van ápolási dokumentációja, amit az ápolók, asszisztensek naponta többször, vagy műszakváltáshoz vezetnek, bejegyzik a beteg ápolási eseményeinek fontosabb mozzanatait. Összegzi a beteg állapotára, az ápolásra és a beteg reakciójának értékelésére vonatkozó lényeges megfigyeléseit. A szakmai profil meghatározza a dokumentáció vezetésének számát, részletességét, tartalmát. Eltérő a dokumentáció vezetése intenzív területeken, ill. hotel részlegeken. Tegye lehetővé a beteggel kapcsolatos korábbi ápolási tevékenységek hatékonyságának eredményességét, azok összevetését, a kapott információk alapján lehessen dönteni a további ellátásról. 1. Tetszőleges ápolási terv készítése betegségcsoportonként. Az elektronikus ápolási dokumentáció elkészítésének kiindulója a jelenlegi meglévő papír alapú dokumentáció legyen (az ápolási dokumentáció része: Ápolási zárójelentés, Decubitus lap, Transzfúzió követő lap, Diabetes lap, Gyógytorna lap, Folyadék lap, stb.) 2. Dokumentum típusonként illetve betegenként legyen beállítható a kötelezően kitöltendő mezők default értéke) 3. Az Ajánlatkérő maga tudjon új elektronikus ápolási lapot és ápolási tervet (ápolási diagnózis, ápolási célkitűzés, ápolási tevékenység, értékelés) létrehozni. 4. Az Ajánlatkérő maga tudja a felmerülő változtatási igényeket az elektronikus ápolási lapon elvégezni. 5. Az elektronikus ápolási dokumentációnak legyen kapcsolódása (automatikus átemelési lehetősége) az orvosi dokumentáció azon részeivel ahol az elrendelések

214

EuroRec: GS003763.02+ GS003764.01+ GS003765.01

99


6. 7.

8. 9.

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

100


B.3 A szakellátás jövőképe B.3.1 Múlt és jövő folyamatai

B.3.1.1 Az informatikai rendszerek fejlődése Napjainkban végbemenő egészségügyi informatikai fejlesztések révén olyan új, egymással kapcsolódó rendszerek jönnek létre, melyek az egészségügyi ellátás minőségileg új rendszerét teremtik meg. Az intézményi egészségügyi informatikai rendszerek fejlődését eredetileg finanszírozási szempontok motiválták. Az első rendszerek ezért az egyes intézményekben megtörtént ellátásoknak legtöbb esetben csupán a tényét, illetve néhány paraméterét dokumentálták, az ellátás révén létrejött információk számítógépes rendszerekbe vitele ebben a fázisban vállalhatatlannak tűnt. Az informatikai rendszerek fejlődése, szélesebb körű hozzáférhetővé válása teremtett lehetőséget arra, hogy a már informatikai rendszerekben rögzített beteg epizódokhoz az ellátás mind szélesebb körű, orvos-szakmai adatai rögzítésre kerülhessenek. Ezen fázist azonban a szabad szöveges adatrögzítés dominálta, melyek jellemzően az ellátott betegek egészségügyi személyzet által interpretált állapotát írták le. A számszerűsíthető mérési eredmények informatikai rendszeren belüli, mező alapú megjelenése relatíve lassan nyert teret. A XXI századra az informatikai rendszerek fejlődése robbanásszerű változást hozott létre. Az elszeparált rendszerek online összekapcsolása napjainkra realitás lett, a gyors internetes kapcsolatok révén egy munkafolyamaton belül is vállalhatóvá vált a felhasználó kiszolgálása távoli adatbázisokból származó adatokkal, ez nem jár a munkafolyamatok érzékelhető megakasztásával. Másrészről az informatikai rendszerek árcsökkenése révén az informatikai végpontok olyan frekvenciával jelentek meg környezetünkben, hogy az információ áradattal táplálja az egészségügyi informatikai rendszereket. A kialakult helyzet révén az egészségügyi informatikai rendszerek a korábbi kiszolgáló szerepkörből egyre inkább a vezérlő szerepkörbe lépnek át. A jövő egészségügyi informatikai rendszereinek ezen szerepmódosulást kell kiszolgálni.

B.3.1.2 Az egészségügyi folyamatok fejlődése Az egykoron alapvetően rövid lefolyású, akut kórképeket kiszolgáló egészségügyi ellátó szolgálat a XXI. századra azzal szembesül, hogy forrásainak immár meghatározó részét hosszú lefolyású, krónikus kórképek gondozására kell felhasználnia. A fenti eltolódást az egészségfinanszírozás rendszere egyelőre nem követi, továbbra is a teljesen lezárható ellátási epizódokban gondolkodik, melynek leképezésére a szintén epizód rendszerben működő egészségügyi informatikai rendszer megfelelőnek tűnik. Az ellátási igény változásával alapvetően változik az ellátás formája is. Míg egykoron az akut kórképek meghatározó része a beteg otthonában, családorvosa által is jellemzően megoldható volt, napjainkra az ellátások technikalizálódása, invazívabbá válása tapasztalható. Ez az egészségügyi szolgáltatások intézményi, fekvőbeteg formáit hozta az érdeklődés előtérbe. Ezen spontán súlyponteltolódást az egészségügyi kormányzatok a költségeszkalálódásra tekintettel megpróbálják tudatosan visszafordítani. Ennek következében a fekvő beteg ellátások ápolási ideje fokozatosan csökken, egynapos ellátások jelentek meg. Ezen kettős prés ugyanakkor az ellátások egymásba fedését hozta létre. A betegek korai otthonukba helyezése csak úgy biztosítható, ha otthonukban szakápolói szolgáltatások, mint parenteralis 101


folyadékpótlás, gyógytorna válnak hozzáférhetővé, a háziorvos a felépülő fázisban lévő betegek kezelés vezetését a fekvőbeteg ellátóktól egy relatíve korábbi fázisban veszi át. Ezen egymásba szövődő ellátási formák a különböző szintű és típusú ellátók mind szorosabb együttműködését kényszeríti ki. Az ellátás egyre invazívabbá válása ellenére a hosszú távú követéses vizsgálatok sora hívja fel a figyelmet ezen reményteljes invazív ellátások kudarcaira. Egyre nyilvánvalóbbá válik, hogy a már megismert életmódi, illetve gyógyszeres kezelések következetes végig vitele legalább olyan fontos, ha nem fontosabb, mint egy-egy új, invazív megoldás bevezetése. Az optimális gyógyszeres kezelések napi gyakorlatba kerülése azonban közismerten elhúzódó folyamat. Az évről évre megjelenő, egyre komplexebb szakmai ajánlások csak igen lassan tudják átalakítani a sok ezernyi önálló orvos működését. Ennek egyik magyarázata, hogy a modern szakmai ajánlások nagy klinikai adatbázisok statisztikai kiértékelésére épülnek. Az ajánlásban szereplő komplex algoritmusok humán befogadása, majd végrehajtása nehézkes. Triviális tény, hogy a számítógépes adatbázisok elemzése alapján létrehozott döntési algoritmusok elsősorban később keletkező számítógépes adatbázisok kezelésére alkalmasak. Mivel több kórkép humán terápiavezetése ezen algoritmusok elsajátítása mellett ráadásul egy különleges jártasságot, a kívánatos hatások és még tolerálható mellékhatások szűk mezsgyéjén való haladás képességét is igényli, az ellátások a járóbeteg környezetben egyre inkább a speciális szakambulanciák irányába tolódnak a hagyományos háziorvosi környezet felől. Tanulmányok sora igazolja, hogy ezen kezelések akkor igazán eredményesek, ha annak irányítását specialista tartja a kezében. Mivel egy általános háziorvosi praxisban a komplex terápia vezetést igénylő szívelégtelenségtől, az egyre komplexebbé váló cukorbetegségen át a gyulladásos bélbetegekig a szub-specialitások tömege jelenhet meg egy-egy reprezentáns beteg személye révén, a háziorvostól ezen speciális jártasságok megszerzése nem várható. A folyamat inkább a szakellátásokon belüli specializálódás fokozódása irányába hat: a belgyógyászati ellátásokból alig két évtizede kivált kardiológián, gastroentorológián belül napjainkra már önálló járóbeteg gondozó ambulanciák indulnak például a szívelégtelenségben szenvedők, a ritmusszabályozó készülékkel élők, vagy a gyulladásos bélbetegek gondozására.

B.3.2 Várható fő kimenetek

B.3.2.1 Online hálózatok hatása A munkamenetekbe illeszthető online kapcsolatok miatt hosszú távon nem tartható az a történelmi rend, melyben az egyes betegre vonatkozó információkat minden intézmény lokális rendszerében manuálisan újra és újra rögzítik. A kooperatív tér nyújtotta kapcsolatok révén a jövőben a betegfelvételi folyamat a központilag nyilvántartott törzsadat, kapcsolati adat lekérdezésére, gyors visszaellenőrzésére korlátozódhat az egyes intézményi szolgáltatók szintjén, az esetleges változások központi adattárolóba vitelével. Hasonlóan okafogyottá válik a beutalóra vonatkozó adatok manuális rögzítése a betegfelvétel során. A tervezett ellátások vonatkozásában ezen munka meghatározó részét átveszi a központi megrendelés nyilvántartó rendszer, mely a tervezett ellátás megrendelése során rendelkezésre álló adatokat automatikusan biztosítja a szolgáltatás igénybevételekor, ezért a felvételi folyamat a beteg intézeten belüli ellátóhoz rendelésére korlátozódhat. A sürgősségi ellátások az egészségügyi intézményeken belül egyre inkább sürgősségi betegellátó osztályokra koncentrálódik. A speciális kórházi osztályok a sürgős betegeket is 102


egyre inkább mint sürgősséggel áthelyezett, mintsem direktben osztályra érkező sürgős felvétel kapják. A gyors hozzáférésű online adatbázisok révén az ellátás tartalmi adatai is a beteg ellátásának következő epizódját irányító orvos elé tárhatók. Legelső lépés ebben az irányban a már jelenleg is központosított adatbázisban tárolt gyógyszerelési adatok hozzáférhetővé tétele lesz, mellyel az egyes intézeti ellátások elindításának orvos-szakmai élőmunka igénye csökkenthető, az ellátás biztonsága, szakmai színvonala emelhető. A központilag tárolt gyógyszerelési adatok betegellátókhoz csatornázásával egyidejűleg valósulhat meg a szintén központi tárolásra kerülő gyógyszer túlérzékenységi adatok mozgatása. Mivel az egyes gyógyszerek szedése kapcsán megjelenő mellékhatások összefüggése adott gyógyszerrel sosem bináris, igen/nem összefüggés, hanem egy valószínűség, a tapasztalt reakciók pontos leírása, és ezen információ hozzáférhetővé tétele a beteg későbbi kezelőorvosa számára a betegellátás hatékonyságát jelentős mértékben növelheti. Elképzelhető olyan eset ugyanis, melyben a beteg kirekesztése egy-egy gyógymódból korábbi kétes allergiás reakcióra hivatkozva a beteg számára nagyobb veszélyt jelent, mint a kezelés felvállalása. Az online adathozzáférés már rövidtávon lehetőséget teremt az adatok idősoros táblázatos, illetve grafikus megjelenítésére. Ilyen prezentációk először a már jelenleg is mező struktúrában rögzített adatoknál várhatók, hosszabb távon ezen strukturált adatrögzítés várhatóan szélesedik, a numerikus, illetve diszkrét stádiumokkal leírható állapotok így könnyebben áttekinthetőkké válnak.

B.3.2.2 Hálózati input pontok bővülésének hatása B.3.2.2.1 Eszközös mérések szaporodása Az informatikai rendszerek bemeneti kapuinak szaporodása révén az egészségügyi rendszerekben kezelt adatok mennyisége több nagyságrenddel bővül. Ezen adatbővülés egyik motorját azon szenzorok képezik, melyek mérési eredményeit eddig jellemzően csak papír alapon dokumentáltuk. Intézeti körülmények között ide sorolódnak például a fiziológiai állapot leírói, mint a vérnyomás, testsúly, testhőmérséklet adatok, illetve a már jelenleg is ágy melletti labor metodikának tekintett mérések, mint a vércukor meghatározása. A vezeték nélküli adatátvitel fejlődésével egyre több mérési eredmény érkezhet ezen mérőkészülékekről közvetlenül az egészségügyi informatikai rendszerekbe. A mérések egyszerűbbé válása ugyanakkor önmagában a mérési frekvencia növelését indukálja, tovább növelve ezzel az adatmennyiséget. Mivel ezen rendszerek a telemedicina fejlődése révén ráadásul a betegek otthonában is kinyúlhatnak, az adatmennyiség növekedése valóban több dimenziós, összességében több nagyságrendet elérő lesz. A mérési eredmények azonnali, betegágy melletti digitalizálása révén több mérési időponttal, részletgazdagabb képet kaphatunk az ellátottak állapotáról. Az adatok megbízhatóságának növelése érdekében azonban elkerülhetetlen lesz a betegek informatikai rendszerek révén való automatikus azonosítása, ezzel a betegtévesztésből adódó eddigi hibák visszaszorítása.

B.3.2.2.2 Nem mérhető adatok szaporodása A beteg közelébe kerülő informatikai végpontok szaporodása révén nem csak az eszközös mérési adatok mennyisége bővül. A mobil informatika érintő képernyős egységei, a tabletek, okostelefonok, révén új grafikus interfészek is megjelennek a beteg közelében, melyek például az egészségügyi személyzet betegre vonatkozó észlelési adatait rögzíthetik. Megfelelő 103


elektromos űrlapok alkalmazásával a betegre vonatkozó anamesztikus adatok, illetve a beteg állapotára vonatkozó aktuális szubjektív adatok is rögzíthetők. A társadalom infokommunikációs kultúrájának bővülésével ezen egészségügyi személyzet által asszisztált adatrögzítés helyét idővel a beteg által végzet aktív adatrögzítés veheti át.

B.3.2.3 Információ hiányból információ áradatra váltás Az egészségügyi ellátás területén napjainkban még oly jellemző információ hiányos állapotot a fenti fejlődési folyamatok rövidtávon információ túlkínálati állapotba billentik át. Az informatikai rendszerek ezen fázistól kiléphetnek a gyermekcipőből, az adathozzáférés biztosítása után az információ feldolgozásra, humán döntések előkészítésére, majd a döntések végrehajtásának megszervezésére koncentrálhatnak.

B.3.2.3.1 Információ értelmezés informatikai rendszerek révén A betegtől érkező adatok áradata intelligens feldolgozás nélkül az egészségügyi ellátás folyamatait nem egyszerűsítik, hanem inkább terhelik. Az adatok szaporodásával elkerülhetetlenül szaporodik ugyanis a kórosnak tekinthető értékek frekvenciája. Amennyiben minden egyes ilyen kóros érték megítéléséhez humán erőt veszünk igénybe, az olyan mértékű erőforrás igényel, mely már más tevékenységektől vonna el erőforrásokat, rontva ezzel az egészségügy globális rendszerének működését. Az információ áradat szűrése, a változási tendenciák intelligens feltárása az információ kinyerését az interpretáló személyek számára nagymértékben egyszerűsíthetik. Mivel ezen adatértelmezési algoritmusok olyan adatok értelmezésére is használhatók lesznek, melyek korábban nem jutottak el a digitalizált adatbázisokba, ezért humán megítélésük elkerülhetetlen volt, az egységes informatikai adatfeldolgozás révén a globális humán ráfordítási igény is csökkenni fog.

B.3.2.3.2 Döntéstámogatás Az adatok informatikai rendszerek általi kezelése, vizsgálhatósága, a humán döntések előkészíthetősége a humán időráfordítás mérséklése mellett az ellátás minőségét is javítani fogja. Az eddig csak humán megtapasztalásra épülő algoritmusok mellett megjelenhetnek a korábbi eredmények szisztematikus áttekintésére épülő informatikai döntési algoritmusok. Az automatizálás ipari, közlekedési ágazatban igazolódott eddigi eredményei alapján a döntések ezen automatizálásával a döntések biztonsága javítható, a humán döntésekkel együtt járó kimeneti fluktuáció mérsékelhető.

B.3.2.3.3 Döntés végrehajtás, logisztika Az infokommunikáció fejlődése nem csak az értékelést igénylő adatmennyiség növekedésében lesz tetten érhető, a betegadatok döntéshozókhoz áramlásával párhuzamosan bővülnek azon csatornák is, melyek a megszületett döntések gyors végrehajtását, ezáltal a beteg állapotának minél gyorsabb rendeződését támogatják. Az infokommunikációs rendszerek fejlődése az egészségügyi ágazat mellett tetten érhető a civil szférában. Már napjainkban olyan penetráltságot érnek el ez egyénig nyúló mobilkommunikációs rendszerek, mely 1-2 évtizede elképzelhetetlen lett volna. A 104


mobiltelefon birtoklása olyan természetes része lett kultúránknak, mint természetessé vált a múlt században az írás-olvasás képességének megszerzése. Ezen penetráltsági szinten rendszerek építhetők a betegek mobiltelefonos elérhetőségére, kivételként kezelve azt a kisebbséget, mely ezen kommunikációs csatorna nélkül éli életét. Olyan informatikai rendszerek kialakulta várható, melyben a kivizsgálás, majd a ráépülő terápia megszervezésében ezen csatornák aktív szerepet kapnak. A beteg kivizsgálásának megszervezését támogató információ áramlás révén az egészségügyi eszközpark kihasználása javulhat, csökkenhet az előjegyzett, de mégis megvalósulatlanul maradt vizsgálati időpontok aránya. A diagnosztikus kapacitások szűkösségével, egyre hosszabbodó várólistákkal jellemzett ellátói környezetben az előjegyzett vizsgálaton meg nem jelenő betegek aránya ilyen interaktív intézkedések nélkül sajnos folyamatosan növekszik. A terápia vezetése az intézményi informatikai rendszerekbe integrált mobilkommunikáció segítségével jelentősen egyszerűsödhet. Az informatikai rendszerben feldolgozott mérési eredmények (labor adatok, esetleg telemedicinálisan továbbított otthoni mérések) alapján a beteg terápiája a beteg személyes megjelenése nélkül módosítható. Az intézményi informatikai rendszereket a patikai rendszerekkel összekötő e-Recept rendszer információi a betegek felé ezen csatornákon keresztül szintén megosztható. Ezáltal a beteg gyógyszerellátása mind a módosuló gyógyszerelés, mint a tartósan szedett gyógyszerek vonatkozásában sokkal kiszámíthatóbbá válik, melynek eredménye a gyógyszer adherencia, ezáltal a kezelés hatékonyságának növekedése lesz. Mivel a mobilkommunikációs csatorna kétirányú, a beteghez jutó információk a beteg által nyugtázhatók, a nyugtázás ténye az intézményi rendszerben a beavatkozás zárásaként értelmezhető. A tartósan szedett gyógyszerek folyamatos ellátása interaktív mobilkommunikációs rendszerekkel támogathatók, melyek csak a terápia folytathatóságának feltételeit ellenőrzi, és humán interakció nélkül biztosítja a beteg gyógyszerellátását. Ez igen jelentős humán ráfordítást szabadíthat fel az egészségügyi rendszeren belül.

B.3.2.4 Epizód kezelésből gondozási folyamat kezelésre váltás Ahogy a betegek epizód alapú adatai az informatikai hálózatok révén egyre inkább kiegészülnek élethossz adatokkal, válik lehetővé az epizód alapú ellátásról a krónikus gondozási folyamatok kezelésére való áttérés. Míg a klasszikus epizód alapú ellátási folyamatai jellemzően néhány diagnosztika elrendelése, eredmény értékelése, terápia indítása ciklusra korlátozódtak, és egy záró orvosi dokumentummal lezárultak, a krónikus betegmenedzsment rendszerek hasonló ciklusok sokaságát kezelik, és időszakos riportjaik csak köztes zárást jelentenek, a gondozási folyamat jellemzően tovább folytatódik. A klasszikus epizód alapú ellátások informatikai rendszereit ezért jellemzően az epizódon belülről indított ciklusok értékelésére konstruálták, más epizódban indított diagnosztikák későbbi epizódban való értékelése ezért sokszor nehézkes. A krónikus betegmenedzsment rendszereket ezzel szemben úgy kell megalkotni, hogy a betegek hosszú távú gondozási folyamata során, több időpontban, akár több ellátónál keletkezett adat is a a kooperatív tér révén áttekinthető, a terápia vezetés meghatározásánál figyelembe vehető legyen. Amennyiben az egyes ellátóknál ezen adatok mező struktúrában kerülnek rögzítésre, akkor az adatok a gondozási folyamatot támogató tetszőleges nézetre átstrukturálhatók legyenek, a gondozási folyamat ezáltal gyorsítható legyen. A gondozási folyamatról időszakosan készülő riportok a kooperatív térben más szolgáltatók epizód alapú riportjaihoz hasonlóan természetesen megosztandók. 105


A betegmenedzsment rendszerek működése hosszabb távon azonban többet igényel annál, mintsem a beteg életútja során különböző helyeken keletkező adatok szintetizálása. A több szakmás gondozására szoruló betegek gondozási folyamatainak hosszabb távú összehangolása elkerülhetetlen. Nem tartható az a jelenlegi gyakorlat, amikor diabetológiai, nephrológiai, neurológiai és kardiológiai ambuláns gondozási programok egymástól függetlenül, párhuzamosan futnak azonos betegen, önállóan szervezve, időnként ismételve az egyes diagnosztikus lépcsőket, például labor vizsgálatokat. A betegellátás több irányú folyamatai a krónikus betegségmenedzsment programok keretében harmonizálandók, még ha minden gondozási folyamatot nem is lehet egyetlen orvos felügyelete alá vonni a párhuzamos ellátók előre tervezhető diagnosztikus igényei összerendezhetők. Az egyes gondozók tervezhető labor vizsgálatai például összevonhatók. Hosszabb távon a különböző betegség kombinációkra közös gondozási protokollok, és ezt kiszolgáló informatikai rendszerek alkothatók.

B.3.2.5 Életmód támogató informatikai rendszerek A krónikus betegségek gondozásának előterében napjainkban a nagy értékű, invazív kezelések optimális időzítése, a komplex gyógyszeres terápia több lépcsős beállítása áll. Ezen krónikus betegségek kialakultában meghatározó életmódi faktorok rendezésének fontosságát mindenki megemlíti, de ennek nehézségeire tekintettel az életmódrendezést, mint intervenciót csak igen szűk kör kezeli súlyponti kérdésként. Az intézményi egészségügyi informatikai rendszerek intézményen belüli kapcsolata a dietétikai rendszerek irányába jelenleg is elvárt. A fizikai aktivitás fenntartását célszó tevékenység a legtöbb járóbeteg, fekvőbeteg intézményben korlátozott, az otthoni fizikai aktivitást megközelítő, esetleg meghaladó tréning programok csak rehabilitációs osztályokon, ambulanciákon működnek. Az otthoni diéta, fizikai aktivitás támogatása napjaink intézményi egészségügyi informatikai rendszereiből hiányzik. A betegek otthonába nyúló, szenzorokkal kiegészíthető mobil informatikai rendszerek jó lehetőséget teremtenek a betegek életmódjának monitorozására, ezzel az életmód változást célzó intervenciók vezetésére. A jövő krónikus betegségmenedzsment rendszereinek ezen informatikai megoldásokat pozitív diszkriminációval kell kezelni, hogy az életmódrendezés a komplex betegségmenedzsment keretrendszerben a szakmailag elvárható szintre juthasson. A preventív orvosi szemléletet támogató rendszerek fejlesztése évtizedek óta napirenden van. Az eddigi megoldások alacsony hatékonysága, a betegek alacsony motiváltsága az életmód változtatás tekintetében ezen fejlesztési eredmények elterjedését eddig hátráltatta. Az orvosi diagnosztika fejlődése napjainkra azonban oda jutott, hogy egyre biztosabban prediktálható egyénre specifikusan egy-egy betegség kialakulta, például genetikai determináció alapján. Ezen immár megfogható egyéni veszélyeztetettségek mérséklése az egyes személyek számára a korábbinál lényegesen markánsabb motivációt képezhet, melyre hatékony preventív eljárások épülhetnek. Bár ezen eljárások ritka esetben lehetnek műtétek, esetleg gyógyszerek, meghatározónak mindenképpen az életmód alkalmas módosítását támogató eljárásoknak kell válnia. A betegség menedzsment rendszerek kialakítása után ezért elkerülhetetlen, hogy készüljünk a személy specifikus betegség megelőző informatikai rendszerek kialakítására.

106

Egészségügyi információs rendszerek üzemeltetése

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 üzemeltetési követelményei

információs

rendszerek

C.1 Üzemeltetési alapkövetelmények Jelen fejezet az anyag céljainak megfelelő mélységben és szemléletben foglalkozik a Szolgáltatásmenedzsment stratégián kívüli területeivel a folyamatok és követelmények szemszögéből. Nem, vagy csak felületesen érinti a szerepek, funkciók területét. C.1.1 Szolgáltatás tervezés

C.1.1.1 Szolgáltatás szint menedzsment A szolgáltatás szint menedzsment célja, hogy a szolgáltatás katalógusban rögzített szolgáltatásokat az elvárásoknak megfelelő színvonalon szolgáltassa. A szolgáltatási szinteket, és az elvárásokat megfelelő szintű dokumentumban kell rögzíteni. A dokumentum alapkövetelményei azonosak belső szolgáltatás, illetve külső fél szolgáltatása esetén. A szolgáltatás szint megállapodás (Service Level Agreement - SLA) a szolgáltatás megrendelője és a szolgáltató között jön létre mérhető módon meghatározva a szolgáltatás céljait, feladatait, mérési módszerét, kapcsolati pontjait, felelősségi köreit, nemteljesülés esetén a vállalt szankcióikat, az ellenőrzés és a visszajelzés lehetőségeit. Az egészségügyi intézményrendszerben elterjedt az a gyakorlat, hogy a tevékenységeit támogató szoftver licenc használati/bevezetési megállapodás mellett támogatási megállapodásokat is kötnek. Ezek a szerződések több évre meghatározhatják a rendszer megbízhatóságát, minőségét, rugalmasságát, így döntő befolyással bírnak annak elfogadottságára és az intézmény alaptevékenységére. Ezen tevékenység támogatására is SLA megállapodást kell kötni.

C.1.1.1.1 Szolgáltatás szint megállapodás C.1-2-001 C.1-2-002 C.1-2-003 C.1-2-004

C.1-2-005

C.1-2-006

A szolgáltatás szint megállapodáshoz minden esetben szolgáltatás katalógust kell csatolni. A szolgáltatás katalógusnak részletesen tartalmaznia kell azokat a szoftver folyamatokat, melyeket a rendszernek a megállapodás szerint annak érvényessége idején szolgáltatni kell. A szolgáltatási szint megállapodásnak tartalmaznia kell a szolgáltatási szint biztosításához szükséges elvárt üzemeltetési szintet. Amennyiben az üzemeltetés kiszervezett, üzemeltetési szint megállapodást kell kötni, amely feltételrendszere megfelel a szolgáltatási szint megállapodás által elvártaknak. Az elvárt üzemeltetési szint tartalmazza az architekturára vonatkozó elvárásokat, együttes üzemeltetésre, tápellátásra, általános üzemeltetési tevékenységekre vonatkozó feltételeket. Az szolgáltatási szint megállapodás során mérhető paramétereket kell megadni, amelyek pontos mérési módszerét a megállapodásban rögzíteni kell. 108


C.1-2-007

Dokumentálni kell a kötelezettségek betartásához kapcsolódó garanciákat, és a mulasztási következményeket.

C.1.1.1.2 A szolgáltatásszint menedzsment felelősségi körei Miután az SLA szerződés eredményeként két fél megállapodása jön létre, a feleknek pontosan meg kell fogalmazni a szolgáltatás nyújtásában történő együttműködés elhatárolásait, feladatait, felelősségeit. C.1-4-001 Pontosan el kell különíteni a felek faladatait Pontosan meg kell határozni a kapcsolattartó személyeket és azok C.1-4-002 jogosultságait, faladatait C.1-4-003 Meg kell határozni a döntéshozói kört C.1-4-004 Meg kell határozni a kapcsolattartási szinteket és módokat

C.1.1.1.3 Szolgáltatásszint mérés és felülvizsgálat C.1-5-001

Az elfogadott szolgáltatás szint mutatókhoz elfogadott mérési módszert és eljárást kell rögzíteni

C.1-5-002

Rögzíteni kell a mérési gyakoriságot, kontrollt

C.1-5-003

Mutatónként meg kell határozni a figyelmeztetési, riasztási szinteket

C.1-5-004

A változáskezeléssel folyamatosan együttműködve a rendszerrel szembeni elvárások változásaihoz igazodva az elvárt szolgáltatás szinteket felül kell vizsgálni rendszeres előre meghatározott időszakonként.

C.1-5-005

Az elvárt szolgáltatásszint változást a változáskezelés folyamatainak megfelelően kell a rendszeren átvezetni

C.1.1.1.4 SLA küszöbérték átlépésének kiértékelési szabályai és következményei C.1-6-001

Biztosítani kell a szolgáltatásszint mutatók figyelmeztetési szint elérési értékeihez tartozó eljárásrendet

C.1-6-002

Biztosítani kell a szolgáltatásszint mutatók megsértési értékeihez tartozó eljárásrendet

C.1-6-003

Szolgáltatásszint sértésnél biztosítani kell az esemény és hibamenedzsment szerinti eljárásrend alapján a rendszer megfelelő szintű működését

C.1-6-004

Meg kell határozni a szolgáltatásszint megsértése esetén alkalmazandó jogkövetkezményeket

C.1-6-005

Szolgáltatásszint megsértésének időszakára szolgáltatási díj nem kérhető (amennyiben a szolgáltatásszint sértés a szolgáltató hibájából történt)

C.1-6-006

Szolgáltatásszint megsértésének időszakára kötbért kell megállapítani

C.1-6-007

Szolgáltatásszint megsértése esetén a kötbéren kívül kártérítés is kiköthető 109


C.1.1.1.5 Kapacitás menedzsment A kapacitás menedzsment célja, hogy a rendszer kapacitásainak, erőforrásainak pontos nyilvántartására, monitorozására alapozva tervezni lehessen az erőforrás igényeket és optimalizálni lehessen az erőforrásokat A rendszer kapacitásait oly módon kell megszervezni, hogy az elfogadott C.1-7-002 SLA szintek teljesíthetők legyenek A változáskezelés döntési folyamataiban a kapacitásmenedzsment adatait C.1-7-007 figyelembe kell venni A rendelkezésre állás növelésére, az érzékeny alkalmazások biztonságára C.1-7-008 létrehozott tartalék kapacitásokat még átmeneti időre sem szabad más célra igénybe venni.

C.1.1.2 Rendelkezésre állás és a szolgáltatások folytonosságának biztosítása A rendelkezésre állás az informatikai rendszer azon állapota, mely során annak minden szolgáltatása, funkciója működőképes és elérhető. A rendelkezésre állás menedzsment célja, hogy a rendelkezésre állás az üzemidő minél nagyobb százalékában megvalósuljon. A rendelkezésre állás kérdésével alapvetően két szinten, a rendszer tervezése és az üzemeltetése során kell foglalkozni. Ezek során a biztosítandó feltételek: o Rendelkezésre állás o Megbízhatóság o Biztonság o Ellenálló képesség o Javíthatóság o Szervizelhetőség A biztonsági kérdésekkel külön fejezet foglalkozik. A rendelkezésre állást csökkentő/megszüntető időszak mindig az esemény létrejötte és a helyreállítás közötti időszak. Az időszak a következő eseménysort tartalmazza o esemény létrejötte o esemény/következmények észlelése o esemény információjának dedikált helyre történő beérkezése o esemény regisztrációja o esemény okának, hatásainak megállapítása o javítás o hatások megszűntetése/helyreállítás o felhasználók kiértesítése o dokumentálás A rendelkezés állás csökkenése a rendszer szolgáltatásainak csökkenését jelenti. Ezek pontos és mindenki számára elfogadott meghatározásához a C.1-8-001 rendszer elvárt szolgáltatásait pontosan definiálni kell (pl. SLA, szolgáltatás katalógus). A rendelkezésre állás csökkenését a szolgáltatás csökkenésének C.1-8-002 függvényében kategorizálni kell. A rendelkezésre állási százalékot mindig egy adott időszakra (év, vagy C.1-8-004 hónap, vagy nap, stb.) vonatkoztatva kell megállapítani215. Figyelembe kell 215

Legelfogadottabb a rendelkezésre állás százalékát a számlázási időszakhoz kötni. Ideális eset ha a számla mellékletét képezi az adott időszakra vonatkozó rendelkezésre állás százaléka

110


venni elsősorban az SLA megállapodásokkor, hogy például 99,9%/hó max. 43 perc kiesést jelent havonta 99,9/év max. 8,76 nap kiesést jelent évente, ha egyéb kitétel nem szerepel.

C.1.1.2.1 LAN: C.1-8-022 C.1-8-024 C.1-8-025

Kábelezés esetén az alkalmazásoknak és a környezetnek megfelelő kábelrendszer216 és kiépítés alkalmazása. WIFI esetén a megfelelő lefedettség és titkosítás biztosítása A hálózat pontos dokumentáltsága

C.1.1.2.2 WAN: C.1-8-026 C.1-8-027 C.1-8-028 C.1-8-029 C.1-8-030 C.1-8-031

A hálózati előírás értékei feleljenek meg az alkalmazások eredője igényeinek. A méretezés vegye figyelembe az inhomogén igénybevételi szintet, a biztonsági zónákat. A hálózat sávszélességi értékeinek előírása mindkét irányban. A hálózat válaszidejének előírása A hálózat megengedett csomagvesztési értékeinek előírása Folyamatos monitorozási lehetőség az aktív eszközökre vonatkozóan

C.1.1.2.3 Szoftverek: C.1-8-035 C.1-8-039 C.1-8-041

Biztosítani kell a megfelelő szoftvertámogatást Garanciák előírása A szoftverek licencszerű használata

C.1.1.2.4 Környezet: C.1-8-046 C.1-8-047

A szünetmentes tápellátás rendszeres időszakonkénti tesztelése Szerverek leállításának szünetmentesről történő vezérlése

C.1.1.2.5 Helyreállíthatóság: C.1-8-052 C.1-8-053 C.1-8-054 C.1-8-055

Biztonsági másolatok készítése Biztonsági mentések készítése Biztonsági mentések készítésének rendszerelőírása Biztonsági mentések, másolatok tárolási rendje

C.1.1.3 Informatikai biztonság menedzsment Az egészségügyben alkalmazott rendszerek, illetve az egészségügyi szervezetek tekintetében az információ biztonságnak kiemelt jelentősége van. A 2012. évi CLXVI. törvény rendelkezik a létfontosságú rendszerek és létesítmények azonosításáról, kijelöléséről és védelméről. A törvény értelmében létfontosságú rendszerelem: a törvény az 1–3. mellékletében meghatározott ágazatok valamelyikébe tartozó eszköz, létesítmény vagy rendszer olyan rendszereleme, amely elengedhetetlen a létfontosságú társadalmi feladatok ellátásához – így különösen az egészségügyhöz, a lakosság személy- és vagyonbiztonságához, a gazdasági és szociális közszolgáltatások 216

A hálózat megfeleőségét mérési jegyzőkönyvvel kell dokumentálni (teljes link mérés+mérési jegyzőkönyves pach kábelek és lengőkábelek)

111


biztosításához –, és amelynek kiesése e feladatok folyamatos ellátásának hiánya miatt jelentős következményekkel járna. A törvény nevesített mellékletében szerepel az egészségügyön belül az aktív fekvőbeteg ellátás, a mentésirányítás, az egészségügyi tartalékok és vérkészletek, a magas biztonsági szintű biológiai laboratóriumok, és az egészségbiztosítás egészségügyi rendszere. A törvény végrehajtására vonatkozó 65/2013 Kormányrendelet szerint a rendszerelemet azonosítani kell. Az azonosítás lehet önkéntes, vagy kijelölő hatóság által előírt. Az azonosítást követően az arról készült jelentés alapján a javaslattevő hatóság javaslata alapján a kijelölő hatóság dönt a rendszerelem felvételéről. A jogszabály részletesen foglalkozik az azonosítási eljárással, az eljárás során elvégezendő, és a besorolást követő kockázatmenedzsmenti feladatokról. A létfontosságú rendszerelemmé nyilvánított informatikai rendszerelemekre értelemszerűen jelen ajánlás mellett a jogszabályi szigorúbb követelmények az irányadóak.

C.1.1.3.1 Kockázatelemzés C.1-9-001 C.1-9-002 C.1-9-003 C.1-9-004 C.1-9-005 C.1-9-006 C.1-9-007 C.1-9-008 C.1-9-009 C.1-9-011 C.1-9-014 C.1-9-016 C.1-9-017 C.1-9-018

Kockázatelemzési módszertant kell választani A választott módszertannak illeszkednie kell az elvárt működési követelményekhez A választott módszertannak biztosítania kell, hogy az eredmények reprodukálhatók legyenek Azonosítani kell a kockázatkezelés területeit, környezetét, céljait, a kockázatértékelés szempontjait Azonosítani kell a kockázatokat fenyegetettség irányból Azonosítani kell a fenyegetett pontokat Azonosítani kell a sebezhető pontokat Azonosítani kell az esetleges magvalósult fenyegetettségek következményeit A választott módszertannak megfelelően az azonosított elemeket szintekbe kell sorolni Szintekbe kell sorolni és súlyozni a kockázatokat Kockázatjavítás végrehajtása után meg kell határozni a maradvány kockázatokat. A kockázatokat kezelni kell. Az elfogadott kockázatokhoz kell igazítani a szolgáltatástervezés további tevékenységeit, a szolgáltatás bevezetést és üzemeltetést. A kockázatelemzés folyamatait új fenyegetettség megjelenése esetén ismételni kell A kockázatelemzés folyamatait háromévente ismételni kell

C.1.1.3.2 Biztonsági szabályzat C.1-10-001 C.1-10-002 C.1-10-003

A szervezet vezetésének iránymutatást kell adnia az információbiztonság követelményeivel kapcsolatosan. Ennek lényege olyan szabályzat létrehozása, mely valamennyi alkalmazottra és partnerre vonatkozik Megfogalmazásának feltétele a tartalmi követelmények mellett a közérthetőség Gondoskodni kell a megismertetéséről 112


C.1-10-004 C.1-10-005 C.1-10-006

A biztonsági szabályzatnak minden érintett részére elérhetőnek kell lennie Rendszeres időközönként aktualizálni kell Meg kell határozni a felülvizsgálat felelősét, továbbá a szükséges felülvizsgálatok gyakoriságát, és esetleges eseményhez kötöttségét. (pl. jelentős biztonsági esemény, jelentős szervezeti, technológiai változás stb.)

C.1.1.3.3 Az informatikai biztonság szervezeten belüli menedzsmentje C.1-11-001 C.1-11-002 C.1-11-003

C.1-11-004

C.1-11-005

C.1-11-006

C.1-11-007

A vezetésnek elkötelezett magatartást kell tanúsítania. Fel kell állítani azt a szervezeti kört, amely felelős a biztonsági szerepek kiosztásáért, a biztonsági szabályzat karbantartásáért. E körön belül kell elemezni az esetlegesen bekövetkezett biztonsági eseményeket. Létre kell hozni az adatvédelmi felelős funkciót, és a jogszabályoknak megfelelő felelősségi és jogosultsági körökkel ellátni. Felelősségi körök definiálása. Tisztázni kell a vagyontárgyak és folyamatok felelőseit. Tisztázni kell, új eszköz, folyamat bevezetésekor, megszűnésekor a felelősségi kör karbantartás rendjét. Meg kell határozni, hogy a felelősségi kör milyen jogokkal, kötelességekkel, eljárásrenddel jár. Megfelelő funkciókkal és jogokkal felruházott képviselőket kell delegálni. Ezeket központi dokumentumban és munkajogi megállapodásban is rögzíteni kell. Titoktartási nyilatkozatok, megállapodások folyamatos karbantartása Külső ügyfelekkel összefüggő kockázatok megállapítása és kezelése eszközátadás, adatkapcsolat, egyéb szerződések során. Elsősorban meg kell állapítani a hozzáférés indokát, célját és módját. Ez alapján kell tisztázni és szabályozni a fizikai és logikai (pl. adatokhoz) hozzáférési jogokat. Tisztázandó, hogy a külső fél alkalmaz-e további alvállalkozókat, azok jogosultsági szintjeit. A harmadik féllel kötött szerződés biztonságpolitikai fejezetének tartalmaznia kell a szervezet biztonsági szabályzatának mindazon elemeit, melyeket érint, továbbá a harmadik fél hozzáférési módjait, az együttműködés, az ellenőrzés szabályait, a felelősségi köröket a változáskezelési, hibaelhárítási szabályokat. Erőforrás kihelyezés biztonsági feltételei nagyrészt megegyeznek az előző ponttal, azzal a megjegyzéssel, hogy pontosan el kell határolni a két szervezet felelősségét, feladatait. Erőforrás kihelyezés esetén figyelembe kell venni, hogy a biztonságpolitikai események körülményei sokszor összetettek, így a pontos elhatárolások tervezésére kiemelt jelentőségű.

C.1.1.3.4 Informatikai vagyon kezelése C.1-12-002

C.1-12-003

C.1-12-004

A szoftverek leltárát oly módon kell vezetni, hogy a kiadás és a visszavételezés mellett a szerzői jogoknak megfelelően a licenc előírásoknak megfelelő használat igazolható legyen. Az informatikai vagyon azonosítása nem minden esetben felel meg a számviteli leltári vagyon fogalmaival. Vagyontárgynak kell tekinteni minden szerzői jog által védett, vagy szellemi értéket képviselő anyagot is, mint rendszerdokumentációt, kezelési kézikönyvet, oktatási anyagot stb. Az informatikai vagyon része az információ is. Az információ nyilvántartásához annak azonosítása, osztályozása, csoportba sorolása szükséges. A csoportképzés alapja lehet az információ típusa, védettségi 113


C.1-12-006

szintje, a rá vonatkozó elévülési, tárolási előírások (pl. egészségügyi adatok külön szabályai). Az információ osztályozásához hozzá kell kapcsolni a csoportra vonatkozó vagyonkezelési előírásokat a tárolás, másolás, mozgatás, továbbítás, megsemmisítés vonatkozásában. Vagyontárgyak tulajdonjoga. Az egészségügyben gyakran előforduló idegen eszközök (alapítványi, próba stb.) elkülönített nyilvántartása. Az azokon található adatvagyon védelme az esetleges visszaadáskor.

C.1.1.3.5 A személyzet biztonsága A szakirodalom szerint az információ biztonságára a legnagyobb veszélyt a személyzet jelenti. Az egészségügyben általában központi rendszereket használ nagyszámú személyzet, ami az adatbiztonságra kiemelt kockázatot jelent. C.1-13-001 Biztonsággal összefüggő feladat és felelősségi körök kialakítása Az alkalmazottak és közreműködők alkalmazási szerződésben vállalt felelőssége és kötelezettségeinek megfogalmazása, titoktartási nyilatkozat. Az alkalmazási szerződésben kell rögzíteni a biztonsági felelősségeket C.1-13-003 (többek között pl. a privát mail lehetőségét/tiltását), titoktartási előírásokat. A titoktartásra vonatkozó előírások a szerződésben akár a foglalkoztatás utáni időszakra is vonatkozhatnak. Célszerű szerződésbe foglalni az előírt követelmények megszegésének munkajogi következményeit. C.1-13-004 A kötelezettségek betartatása Alkalmazás/szerződés megszüntetése esetén meg kell határozni a felelősségi C.1-13-006 körök további sorsát Alkalmazás/szerződés megszüntetése esetén vissza kell szolgáltatni a C.1-13-007 kezelésben lévő vagyontárgyakat beleértve az adatvagyont is. Alkalmazás/szerződés megszüntetése esetén meg kell szüntetni a hozzáférési jogokat. Ideértve az összes használt rendszer, a levelezés, és bármilyen C.1-13-008 hozzáférés jogát. Az előírásból következően alkalmazás/szerződés megszüntetése csak az adott terület információ biztonságával megbízott felelős ellenjegyzésével történhet. A biztonsággal összefüggő eljárások, feladatok oktatása. A szervezet érintett tagjait folyamatosan képezni, továbbképezni szükséges. A képzésnek ki kell térni a betartandó szabályokra, eljárásokra. A képzés fontos része az esetleges biztonsági eseményekre történő reagálás begyakorlása. Az ellátási C.1-13-009 intézményekben például a központi betegadminisztrációs rendszer esetleges leállása nem befolyásolhatja alapvetően a betegellátást. Minden érintettnek tudnia kell a megfelelő szabályzatok és képzés alapján a tennivalóit ilyen esetben is. Ugyanígy tudnia kell az esemény megszűnését követő tennivalókat is. Meg kell szervezni a biztonsági események jelentésének eljárásrendjét. Nem engedhető meg, hogy egyes esetleg helyben alacsonyabb fokozatúnak ítélt esemény ne kerüljön továbbításra, mert az egyrészről lehetetlenné teszi a C.1-13-010 válaszlépések kidolgozását másrészről esetlegesen további eseményeket idézhet elő, ami már az alapvető működést, esetleg a betegellátást veszélyezteti.

C.1.1.3.6 Fizikai és környezeti biztonság 114


C.1.1.3.6.1 Területek védelme

C.1-14-002 C.1-14-004

Kamerás védelem alkalmazása esetén be kell tartani az arra vonatkozó külön jogszabályokat. (pl. személyiségi jogok és adattárolással kapcsolatos előírások) A kiemelt biztonsági területeken (pl. szerverszoba) végzett munkavégzés szabályainak kidolgozása

C.1.1.3.6.2 Berendezések védelme

C.1-14-005

C.1-14-009

C.1-14-010

C.1-14-011

C.1-14-012

C.1-14-013

A berendezéseket úgy kell elhelyezni, hogy csökkenjen a jogosulatlan hozzáférés lehetősége. Nem helyezhető el úgy például egészségügyi adatokat feldolgozó eszköz, hogy arra a személyzeten kívül más ráláthasson, vagy ahhoz őrzés hiányában más hozzáférjen. A berendezések biztonsága jelentős mértékben függ a karbantartástól. A gyári előírásokat be kell tartani. A karbantartásokat tervezni és naplózni kell. Berendezések biztonsága telephelyen kívül. Ide értendő a mobil eszközök biztonsága. A telephelyen kívüli munkavégzés kiemelt biztonsági kockázatot jelent mind az eszközök fizikai biztonsága, mind az adatok biztonsága szempontjából. Szabályozni kell ezen eszközök használatát, és biztosítani, hogy az adatok – kiemelten a személyi és egészségügyi adatok – illetéktelen kézbe ne kerülhessenek. Az adatkezeléssel kapcsolatos tevékenységeket naplózni szükséges. Külön szabályozni kell az otthoni munkavégzés esetében az adatbiztonságot, betörésbiztonságot. Szabályozni kell a karbantartásra házon kívülre kerülő berendezésekre vonatkozó előírásokat. Nem engedélyezhető, hogy ilyen berendezések visszaállítható módon adatot tartalmazzanak. kiemelten védendők a személyi, egészségügyi adatok. Ezek elsősorban az alapellátás egygépes rendszereire jelentenek veszélyt217 Berendezések áthelyezése, selejtezése. Ennek során mindig figyelemmel kell lenni a tárolt adatokra. Az érvényes adatvédelmi jogszabályok szerint gondoskodni kell azok archiválásáról, az eszközről visszaállíthatatlan módon történő törléséről.

C.1.1.3.7 A kommunikáció és az üzemeltetés biztonsága C.1.1.3.7.1 Üzemeltetési eljárások és felelősségi körök

C.1-15-001

Az üzemeltetési eljárásokat karbantartott dokumentumba kell foglalni, és a felhasználóknak hozzáférhetővé tenni.

C.1.1.3.7.2 Harmadik fél szolgáltatásnyújtásának irányítása

Az egészségügyi szolgáltatók esetében az alkalmazott központi rendszerek szállítóival gyakorlat a kapcsolódó (pl. support) szolgáltatási megállapodás. A szolgáltatás azonban nem kerülhet ki a megrendelő irányítása, kontrollja alól. Semmilyen körülmények között nem engedélyezhető, hogy a szállított rendszerekben akár a helyszínen, akár távolról kontroll nélküli tevékenységet folytassanak. 217

A hibaelhárítási szerződéskötések kapcsán ragaszkodjunk a helyszíni hibaelhárításhoz.

115


C.1-16-001 C.1-16-002 C.1-16-004

Biztosítani kell a harmadik fél szolgáltatásnyújtásában a biztonsági előírások betartását. Biztosítani kell a szolgáltatási szintek betartását. A harmadik fél által végzett szolgáltatások esetében a változáskezelésre, az ahhoz kapcsolódó felelősségi körökre és szabályokra külön megállapodást kell kötni, és azt folyamatosan betartatni.

C.1.1.3.8 Rendszertervezés és elfogadás C.1.1.3.8.1 Rosszindulatú szoftverek elleni védelem

C.1-18-001 C.1-18-003 C.1-18-004 C.1-18-005

Központi eszközök védelme. Személyi eszközök védelme Mobil eszközök védelme Biztosítani kell a védelem naprakészségét

C.1.1.3.8.2 Biztonsági mentés

C.1-19-001 C.1-19-002

C.1-19-003

Az információkról és szoftverekről biztonsági másolatot kell készíteni. Az egészségügy sajátos adatvédelmi szabályozásának megfelelően az adatokat oly módon kell menteni, hogy azok eredeti formájukban visszaállíthatók legyenek teljesítve az adatok megőrzésének feltételeit is. Az egészségügy sajátos adatvédelmi szabályozásának megfelelően az adatokat rendszeres időközönként oly módon is kell menteni, hogy azok eredeti szoftverkörnyezete is mentésre kerüljön..

C.1.1.3.9 Hálózat biztonsága C.1.1.3.9.1 Adathordozók biztonsága

C.1-21-003

Az adathordozók selejtezését oly módon kell elvégezni, hogy a rajtuk lévő adatok visszaállítása ne legyen lehetséges.

C.1.1.3.9.2 Információcsere

Az egészségügyi rendszerek közötti információcsere már jelenleg is igen nagy szerepet kap mind a központi rendszerek (pl. OEP) felé, mind egymás között (pl. háziorvos-szakellátás, szakellátás-labor közreműködő, szakellátó-szakellátó). Nyilvánvaló törekvés, hogy ezek a kapcsolatok tovább fejlődjenek. Az információcsere biztonsága azonban követelmény. Az információcserében résztvevő valamennyi eszközre, szoftverre ki kell dolgozni a szakmai eljárásokat és biztonsági intézkedéseket. A szabványos C.1-22-001 eljárásokat kell preferálni, amelyek biztosítják az információ védelmét. Nem engedhetők meg olyan kapcsolatok, melyek során bármelyik fél a szükségesnél magasabb szinten hozzáférhet a másik rendszeréhez, adataihoz. C.1-22-002 A külső féllel történő információcserét megállapodásban kell rögzíteni. Amennyiben az információcsere adathordozón valósul meg, azt védeni kell a C.1-22-003 megrongálástól, visszaélésektől. Minimális védelem az adatok titkosítása. További védelem lehet pl. az adathordozó jelszóvédelme. Az elektronikus üzenetekben (email) történő adatcsere szintén C.1-22-004 veszélyeztetett. Amennyiben védett adatok továbbítására kerül sor, azokat külön védeni kell pl. elektronikus aláírással, titkosítással. 116


C.1.1.3.9.3 Monitoring

C.1-24-002

C.1-24-004

Külön kiemelendő, hogy a medikai adminisztrációs rendszerekben naplózni kell minden adatmódosítást és adatolvasást is. Ezáltal ellenőrizhetővé téve az esetleges belső jogellenes tevékenységet. A naplók védelmét és mentését meg kell szervezni. A naplók őrzési ideje arányos kell hogy legyen a bennük tárolt adatok aktualitásával és a vonatkozó jogi előírásokkal. Például adat jogellenes kiszivárogtatása esetén bizonyítékként szolgál a jogi eljárásban.

C.1.2 Szolgáltatás bevezetés

C.1.2.1 Változáskezelés Az informatikai rendszerekkel szemben változtatási igények merülhetnek fel szervezeti változások, tevékenységi változások, probléma megoldások, új technológiák, bővülő igények, hardver218 és szoftver bővítések vagy csere219 esetén, új folyamatok belépése, folyamatok módosulása stb. miatt. A változáskezelés célja, hogy a változtatások végrehajtásának sikerességét biztosítsa a káros hatások kizárása, vagy minimalizálása mellett.

C.1.2.1.1 Intézményen belüli változtatási folyamatok C.1-27-008

C.1-27-009 C.1-27-012 C.1-27-013 C.1-27-014

A változtatás jóváhagyása, ütemezése – a változtatást csak az arra kinevezettek hagyhatják jóvá, és csak az ő megrendelésük alapján kezdődhet a létrehozásuk. Ők a felelősek a megfelelő ütemezésről, mely biztosítja a rendszer optimális működését. A változtatást pontosan meg kell tervezni, és létrehozása csak a terv szerint történhet. A változtatások végrehajtásának előkészítése során elvégzendő az oktatás, kezelési anyagok kiadása A változtatások biztonságának előkészítése során gondoskodni kell a mentésekről. A változtatások végrehajtását csak az arra kinevezettek engedélyezhetik, az csak az engedély birtokában hajtható végre.

C.1.2.2 Kiadás és üzembe állítás A kiadáskezelés célja a szolgáltatás tervezés során a változáskezelés eredményeként beszerzett, kialakított folyamatok, szoftverek, hardverek bevezetése, üzembe állítása. A szoftver kiadás lehet különbségi, amely csak a legutóbbi kiadás óta változott elemeket tartalmazza, és lehet teljes kiadás, mely során a szoftver/folyamat minden elemét együtt állítjuk üzembe.

C.1.2.2.1 Teljes vagy jelentős kiadásnál a alkalmazni

218 219

Pl: HDD bővítés, stb. Pl: adatbázis kezelő váltás, kommunikációs könyvtás változtatás, stb.

117

Projektmenedzsment előírásait kell


C.1.2.3 Konfigurálás C.1-28-007

Visszatérési eljárást kell tervezni, mely lehetővé teszi az esetleges sikertelen bevezetés után a korábbi helyzetbe történő visszatérést.

C.1.3 Kiadás elfogadása C.1-29-001 C.1-29-006 C.1-29-007

A kiadás elfogadása csak sikeres teszt után történhet. Fejlesztői környezetből közvetlenül éles környezetbe kiadás nem vihető. A migrációt tesztelni kell A biztonságot tesztelni kell

C.1.3.1 Telepítés tervezése C.1-30-002 C.1-30-004 C.1-30-006

Meg kell határozni a telepítés felelőseit, feladataikat Szükség esetén biztosítani kell a telepítés során a munkavégzést/betegellátást Biztosítani kell az oktatás tárgyi, helyiség és személyi feltételeit

zavartalan

C.1.3.1.1 Oktatás C.1-31-001 C.1-31-006 C.1-31-007

Az oktatások során minden kiadásban érintett felhasználót oktatni kell. Az oktatás során minden olyan tevékenységet oktatni kell, amit az adott hallgató munkája során végezni fog. Az oktatás időtartamának arányosnak kell lennie az oktatott anyag terjedelmével, és az oktatottat alkalmassá kell tennie a működtetésre.

C.1.3.1.2 Telepítés C.1-32-001 C.1-32-004 C.1-32-005

Telepítés során a visszatérési eljárás előírásainak megfelelően biztosítani kell a korábbi állapot konzerválását Biztosítani kell, hogy a kiadott rendszer életbe léptetése minden területen egységesen a szükséges átmigrált éles adatokkal történjen. A létrejövő éles rendszert a teszt rendszertől el kell különíteni, és biztosítani kell, hogy a két rendszert a továbbiakban ne lehessen együtt használni.

C.1.3.2 Ismeret menedzsment Az ismeretmenedzsment célja, hogy minden szereplő az adott területen és pillanatban elegendő információval, tudással, készséggel rendelkezzen. C.1-33-001 Biztosítani kell az adott terület használatához szükséges oktatást Biztosítani kell, hogy a használat során naprakész segédanyagok, Help a C.1-33-002 felhasználó rendelkezésére álljanak C.1-33-007 Biztosítani kell a változásokból adódó ismeretek elsajátítását C.1.4 Szolgáltatás üzemeltetés

C.1.4.1 Incidens menedzsment Az incidens egy olyan esemény, amely nem része a szolgáltatás normális működésének és annak megszakadását vagy minőségének romlását okozhatja. Az incidens hátterében lévő ok a probléma. Az incidenskezelés célja, hogy a szolgáltatás normális állapota a lehető leggyorsabban visszaállításra kerüljön úgy, hogy csökkentse 118


ezáltal az incidens az egészségügyi szolgáltató működésére gyakorolt hatását. A nem saját fejlesztésű rendszerek/rendszerelemek esetén szerződés műszaki mellékletében részletesen elő kell írni, hogy az adott rendszer mely C.1-36-002 funkcionalitással, milyen válaszidőkkel történő működése jelenti a rendszer normális működését, amelytől bármilyen eltérés incidensként azonosítandó. Meg kell határozni, és mind a rendszerszállítókkal, mind a felhasználókkal el C.1-36-003 kell fogadtatni az incidensek besorolási rendszerét. C.1-36-005 Az egyes incidens csoportokhoz hibaelhárítási időtartamokat kell előírni. A hibaelhárítási időtartamoknak a következő részletezettségűnek kell lenni: C.1-36-006 észlelés, bejelentés, kezdet, befejezés, helyreállítás A hibaelhárítási szakaszokhoz meg kell határozni a felelősöket és C.1-36-007 eljárásrendet.

C.1.4.2 Ügyfélszolgálat C.1-37-001 C.1-37-002 C.1-37-003 C.1-37-004 C.1-37-005 C.1-37-006 C.1-37-007 C.1-37-008 C.1-37-009 C.1-37-010 C.1-37-011 C.1-37-012

10 gépes hálózat felett ügyfélszolgálatot kell létrehozni. Szoftver szállítóval szemben a működő ügyfélszolgálatot elő kell írni. Az ügyfélszolgálaton olyan hibajegykezelést kell alkalmazni, mely lehetővé teszi a hiba megoldásának eseménykövetését, személyi követését, időpont követését, a szükséges statisztikák lekérését. Szoftverszállító felé elő kell írni, hogy biztosítson olyan felületet, melyen az eseménykövetés megvalósítható. Az ügyfélszolgálatot úgy kell felépíteni, hogy optimálisan kiszolgálja az adott feladatokat és az adott szervezetet. Több telephelyes szervezet esetében – amennyiben az egyes telephelyek elérik az ügyfélszolgálat alsó határát – több szintű ügyfélszolgálatot kell létrehozni. Meg kell határozni, hogy az egyes ügyfélszolgálati szintekhez milyen megoldási szintek tartoznak Meg kell határozni az egyes ügyfélszolgálati szintek feladatait, kapcsolatait, felelősségét. Meg kell szervezni a szervezeten belüli értesítési rendet, mely tartalmazza az incidens bejelentési rendet, a besorolás szerinti értesítési rendet, az állapot visszajelzések rendjét. Meg kell határozni a külső/szállítói ügyfélszolgálatok felé történő kapcsolattartási rendet. Külső/szállítói ügyfélszolgálat megléte esetén pontosan el kell különíteni a külső-belső felelősségi és tevékenységi köröket. Kimenet lehet készre, megkerülés, problémajelentés, szolgáltatási szint jelentés

C.1.4.3 Probléma menedzsment A problémamenedzsment célja, hogy az incidensek kiváltó okait megtalálja, illetve minimálisra csökkentse. A hibajegy kezelő rendszernek alkalmasnak kell lennie, hogy az incidenst a C.1-38-001 problémakezelés igényeinek megfelelő pontossággal írja le Biztosítani kell a lehetőséget a vélhetően azonos problémához köthető C.1-38-002 incidensek szűrésére, statisztikájára, behatárolására 119


C.1-38-003 C.1-38-004 C.1-38-005 C.1-38-006 C.1-38-007

Az incidenseket kategorizálni kell előfordulási gyakoriságuk, hatásuk szerint A problémamegoldást a kategóriákhoz kapcsolódó prioritási sorrendben kell kezelni. A probléma megoldására felelős személyt kell kijelölni, aki a problémát a hibajegy kezelő rendszer információi alapján és az előírt prioritási sorrendben kezelheti. Amennyiben a problémamegoldás eredménye a rendszerben változást hoz létre, alkalmazása során a változáskezelésnek megfelelően kell eljárni. Az problémamegoldás eredményéről, állapotáról az ügyfélszolgálat részére folyamatos információt kell szolgáltatni.

C.1.4.4 Kérésteljesítés menedzsment A kérésteljesítés menedzsment lehetőséget biztosít a rendszer szolgáltatásai keretén belüli olyan kérések szabályozott elbírálására és teljesítésére, melyek teljesítése a kérő jogosultsági szintjén kívül esik. (Pl. jogosultságok beállítása, funkciók hozzárendelése stb.) C.1-39-001 A kéréseket egységesített formába és nyilvántartásba kell szervezni C.1-39-002 Ki kell alakítani a kérések elbírálásának eljárásrendjét C.1-39-003 Ki kell jelölni az elbíráló, végrehajtó szereplőket Meg kell határozni a végrehajtási sorrendet alkotó prioritási rendet, és a C.1-39-004 hozzá tartozó határidőket C.1-39-005 A teljesített kérésekről meg kell szervezni az értesítési rendet.

C.1.4.5 Hozzáférés menedzsment A jogosult felhasználók számára biztosítja a szolgáltatás felhasználásának jogát, működését, amit a jogosulatlanoknak számára megtagad. Személyazonosság megállapítása – név + egyéb azonosító pl.: születési C.1-40-001 dátum, törzsszám, orvoskód stb. Személyazonosság ellenőrzése minimum kettős azonosítással pl.: felhasználó C.1-40-002 név +jelszó, felhasználó név+biometrikus azonosító, chip kártya+jelszó stb. Jelszó alkalmazása esetén az csak megfelelő biztonsági szintű lehet (eltérő C.1-40-003 betűméretek és számok egy jelszón belül) A jelszó a felhasználó által megváltoztatható meghatározott időszakonként C.1-40-004 kötelező módon C.1-40-005 A jelszavak nem tárolhatók visszafejthetően. A felhasználók részére szerepeket kell meghatározni. A szerepek lehetnek egyediek, csoportba sorolhatók, kiterjesztettek. Egy egészségügyi C.1-40-006 szolgáltatónál például jellemző szerepcsoportok: orvos, ápoló/asszisztens, betegirányító, hr-es, pénzügyi, könyvelő, rendszergazda. Jellemző egyedi szerepek orvosvezető, gazdasági vezető, adatvédelmi felelős. Lehetőséget kell adni, hogy egy személyhez több szerep is kapcsolható C.1-40-007 legyen Vizsgálni kell az esetleges szerepkonfliktust, azaz ha egy személy több C.1-40-008 szerepe egymásnak ellentmondó C.1-40-009 A szerepekhez jogosultságokat kell rendelni A jogosultságoknak ki kell szolgálni a szerephez kapcsolódó minden C.1-40-010 tevékenységet a teljes/minden rendszerben. C.1-40-011 A jogosultságoknak meg kell felelnie a szervezet belső szabályainak. Például 120


C.1-40-012 C.1-40-013 C.1-40-014 C.1-40-015 C.1-40-016 C.1-40-017 C.1-40-018 C.1-40-019 C.1-40-020

a rendszergazda nem férhet hozzá védett adatokhoz. A jogosultságoknak meg kell felelni az érvényes jogszabályoknak. Egészségügyi szolgáltatók esetében kiemelt az egészségügyi adatok kezelésre vonatkozó jogszabály. A felhasználókat és jogosultságaikat egy nyilvántartási rendszerben/adatbázisban kell tárolni. A felhasználók jogosultsági életciklusának idősorosan követhetőnek és megőrzöttnek kell lennie. Tárolni kell a jogosultságot engedélyező és a kiadó azonosítóit. A jogosultság igénylés lehet egyedi pl. az adott dolgozó további feladatot kap, és vezető igényel hozzá jogosultságot A jogosultság igénylés lehet automatikus pl. új orvos belépése esetén a hr értesítése alapján orvos csoportba kerül. A rendszert monitorozni kell, hogy az egyes jogosultságok folyamatosan megfelelnek a szerepköröknek. Meg kell határozni a jogosultsági életciklus felelőseit: igénylés, igény ellenőrzés, jóváhagyás, beállítás, monitorozás, megvonás igénylés, megvonás jóváhagyás, megvonás beállítás. Biztosítani kell a szerep megszűnése esetén a kapcsolódó összes jogosultság megszüntetését.

C.1.4.6 Folyamatos szolgáltatásfejlesztés A folyamatos szolgáltatás fejlesztés célja, hogy a rendszer szolgáltatásai minél jobban illeszkedjenek a változó felhasználói, műszaki környezeti követelményekhez. C.1-41-001 Ki kell dolgozni a mérési indikátor rendszert C.1-41-002 Az indikátorokat monitorozni kell C.1-41-003 A mérési eredményeket analizálva az illeszkedés mértékét elemezni kell Az elemzés eredményeit felhasználva ajánlatot kell tenni a szolgáltatás C.1-41-004 tervezés felé a további fejlesztésekre

C.1.4.7 Üzemeltetési szerződésmenedzsment C.1-42-001 C.1-42-001 C.1-42-002 C.1-42-003

C.1-42-004 C.1-42-005 C.1-42-006 C.1-42-007

A szerződéseknek illeszkednie kell az egységes üzemeltetési rendszerbe Üzemeltetési feládátok kiszervezése során figyelembe kell venni áz érvényes jogi rendelkezéseket (pl. ádátfeldolgozást szábályái) Üzemeltetési feladatok kiszervezése során figyelembe kell venni a kockázatelemzés eredményeit Üzemeltetési feladatokat csak úgy lehet kiszervezni, hogy a szolgáltatás folyamatossága biztosítva legyen esetleges soron kívüli szerződésbontás esetén is A szerződéseknek rendelkezni kell az alapvető tartalmi követelményekkel (felek, időszak, tárgy, teljesítési feltételek, ellenszolgáltatás, késedelmeshibás teljesítés definíció és következmény, dátum, aláírás) A szerződésben szolgáltatási szint megállapodást kell kötni Rögzíteni kell a rendelkezésre állás és a szolgáltatás folytonosságának tényezőit, követelményeit Az üzemeltetési tevékenységnek meg kell felelnie a biztonságmenedzsment előírásainak 121


C.1-42-008 C.1-42-009 C.1-42-010 C.1-42-011 C.1-42-012 C.1-42-013

Az üzemeltetési tevékenységben résztvevőknek vállalniuk kell a biztonságmenedzsment előírásainak betartását Tisztázni kell az esemény és incidens menedzsment felelősségi köreinek elhatárolásait Tisztázni kell az esemény és incidens menedzsment körébe eső eseményeket, azok kezelésének, megoldásának felelőseit, határidejét, következményeinek viselőjét, annak mértékét Meg kell határozni az ügyfélszolgálattal szembeni elvárásokat Meg kell határozni az együttműködési kereteket, eljárásrendet a kérésteljesítés területein és a probléma menedzsment kérdéskörében Tisztázni kell a hozzáférés feltételeit, eljárásrendjét

C.2 A szakellátási rendszerek üzemeltetésének ajánlott követelményei C.2.1 Szolgáltatás tervezés

C.2.1.1 Szolgáltatás katalógus menedzsment C.2-1-001 C.2-1-002 C.2-1-003 C.2-1-004

Létre kell hozni az informatikai rendszer szolgáltatási katalógusát A szolgáltatás katalógusnak részletesen tartalmaznia kell azokat a folyamatokat, melyeket a rendszernek szolgáltatni kell. A szolgáltatási katalógusban jelezni kell a folyamatok kapcsolatrendszerét. A szolgáltatás katalógust a változáskezelés irányítása alatt karban kell tartani.

C.2.1.2 Szolgáltatás szint menedzsment C.2.1.2.1 Az egészségügyben használatos monitorozandó objektumok

C.2-3-001

C.2-3-002

rendszereknél

leggyakrabban

Meg kell határozni a Hardver (szerverek, nyomtatók,munkaállomások stb.) SLA jellemzőit o Rendelkezésre állás – adott időegységre vonatkozó százalék o Processzor idő – időtartam o Processzor terheltség – százalék o Válaszidő – időtartam o Memória kihasználtság – százalék o Egy időben működő munkaállomások száma – db o Szabad tárkapacitás – kapacitás egység Meg kell határozni a hálózat SLA jellemzőit o Külön SLA-t kell megállapítani LAN, WAN hálózatokra, külső kapcsolatokra, internetre o Rendelkezésre állás - adott időegységre vonatkozó százalék o Sávszélesség – irányonként(letöltés, feltöltés), névleges és minimális - adatmennyiség/időegység o Válaszidő – meghatározott méretű és számú csomag átviteli ideje egyeztetett mérési metódus szerint – időtartam maximális vagy átlagos 122


C.2-3-003

C.2-3-004

C.2-3-005

C.2-3-006

o Csomagvesztés – meghatározott méretű és számú csomag átvitele során elveszett csomagok aránya – db vagy százalék Meg kell határozni a szoftver alkalmazások SLA jellemzőit o Rendelkezésre állás – szoftver esetében a rendelkezésre állást a rendelkezésre állás menedzsmentben taglaltak alapján kell osztályozni – adott időegységre vonatkozó százalék o Működő licencek száma – (licenc szerződéstől függően, de az egy időben maximálisan működő licencek alapján) – db o Válaszidők – válaszidőket kell meghatározni alapvető folyamatokhoz pl. adatbevitel, szótárakban keresés, adatbázisban keresés, nyomtatás stb. – időtartam o A válaszidők mérésére pontos eljárásrendet kell meghatározni, amely tartalmazza a mérés tárgyát, környezetét, gyakoriságát, kiértékelési módját. Meg kell határozni a szoftver követés SLA jellemzőit o Közhiteles adatbázisok követési ideje – közzétételt követően – időtartam o Közhiteles szabályalgoritmusok követési ideje - közzétételt követően – időtartam o Jogszabályok követési ideje - közzétételt követően – időtartam o Jogszabályok követési ideje visszamenőleges hatály esetén időtartam Meg kell határozni a támogatás SLA jellemzőit o Támogatási időszak – napi, heti időszakok o Telefonos elérhetőség – vonalak száma o Telefonos elérhetőségi idő – időtartam o E-mail-en történő elérhetőségi idő – igazolt olvasás – időtartam o Válaszidő – időtartam Meg kell határozni a hibakezelés SLA jellemzőit o Esemény besorolási szabályok – szintek o Hiba bejelentési időszak – napi, heti időszakok o Telefonos elérhetőség – vonalak száma o Telefonos elérhetőségi idő – időtartam o E-mail-en történő elérhetőségi idő – igazolt olvasás – időtartam o Válaszidő – időtartam o Helyreállítási idő – bejelentéstől a helyreállításig hibaszintenként – időtartam o Hiba javítás állapotáról értesítési gyakoriság hibaszintenként – időtartam

C.2.1.2.2 Szolgáltatásszint mérés és felülvizsgálat C.2-5-003

Mutatónként meg kell határozni a figyelmeztetési, riasztási szinteket

C.2-5-004

A változáskezeléssel folyamatosan együttműködve a rendszerrel szembeni elvárások változásaihoz igazodva az elvárt szolgáltatás szinteket felül kell vizsgálni rendszeres előre meghatározott időszakonként.

C.2-5-005

Az elvárt szolgáltatásszint változást a változáskezelés folyamatainak 123


megfelelően kell a rendszeren átvezetni

C.2.1.2.3 SLA küszöbérték átlépésének kiértékelési szabályai és következményei C.2-6-006

Szolgáltatásszint megsértésének időszakára kötbért kell megállapítani

C.2.1.3 Kapacitás menedzsment A kapacitás menedzsment célja, hogy a rendszer kapacitásainak, erőforrásainak pontos nyilvántartására, monitorozására alapozva tervezni lehessen az erőforrás igényeket és optimalizálni lehessen az erőforrásokat A rendszernyilvántartásokat oly módon kell megalkotni, hogy az egyes C.2-7-001 kapacitásértékek lekérdezhetőek legyenek C.2-7-003 A rendszer kapacitás igényeit, kihasználtságát monitorozni kell A monitorozás során figyelembe kell venni az erőforrásigény időbeli C.2-7-004 változásait C.2-7-005 Az adatokat elemezni kell Az elemzések alapján dönteni kell esetleges változáskérelem vagy C.2-7-006 áthangolás kérdéskörben

C.2.1.4 Rendelkezésre állás és a szolgáltatások folytonosságának biztosítása

C.2-8-003

A rendszer tervezésénél, a szolgáltatási szint megállapodásánál a rendelkezésre állási százalékot meg kell tervezni. A tervezés során figyelembe kell venni, hogy az elvárt szint emelése egy határ fölött a rendszer árának drasztikus emelkedésével jár a szükséges technológiák minőségi váltása miatt. Ezért a tervezés során alkalmazni kell a risk menedzsment elemeit, és az ár érték arányt optimalizálni kell.

C.2.1.4.1 Szerverek C.2-8-005 C.2-8-006 C.2-8-007 C.2-8-008 C.2-8-009 C.2-8-010 C.2-8-011 C.2-8-012 C.2-8-013 C.2-8-014 C.2-8-015

Brand, kiforrott típus választása220 Redundáns táp (hot swap), processzor, HDD (hot swap) Szerverhez tervezett processzor Hardveres RAID és hardveres RAID vezérlő Skálázhatóságot és rendelkezésre állást növelő tényezők a virtuális szerver, storage megoldások A rendszerszoftverek folyamatos frissítése221 Három év helyszíni garancia Élettartamra biztosított alkatrészellátás Saját távfelügyeleti menedzsment rendszer A menedzsment során mérhetőnek kell lenni az alapvető működési értékeknek: hőmérsékleti, HDD állapoti stb. tényezők A működési indikátorok szélsőséges értékénél riasztani kell222.

220

Ezt legjobban az eszközökhöz igénybe vehető szerviz szolgáltatások, rendelkezésre állás, alkatrész ellátottság és a garanciális feltételek alapján lehet lemérni 221 Pl: firmware frissítések, eszköz meghajtó szoftverek 222 Csak a gyári, szoftveres megoldás elfogadható

124


C.2.1.4.2 Személyi számítógépek C.2-8-016 C.2-8-017

Az eszköz kiválasztásánál megbízhatóságot növelő tényező a megfelelő brand223 a kiforrott típus választása. Rendelkezésre állást növelő tényező a felhasználáshoz optimalizált típus alkalmazása224 .

C.2.1.4.3 LAN C.2-8-018 C.2-8-019 C.2-8-020 C.2-8-021 C.2-8-023

Aktív eszköz kiválasztásánál megbízhatóságot növelő tényező a megfelelő brand225, a kiforrott típus választása. Az otthoni felhasználásra szánt eszközök alkalmatlanok az egészségügyben alkalmazott rendszerek kiszolgálására. Aktív eszközök központi menedzselhetősége Az aktív eszközök megfelelő menedzselése, és a forgalmak és a portok folyamatos monitorozása A hálózat passzív elemei egy gyártótól származó garantált minőségűek legyenek Földelés és villámvédelem226

C.2.1.4.4 WAN C.2-8-032 C.2-8-033

Tartalék megoldás biztosítása eltérő technológiával és eltérő útvonallal Automatikus váltás a tartalék megoldás felé.

C.2.1.4.5 Szoftverek C.2-8-034 C.2-8-036 C.2-8-037 C.2-8-038 C.2-8-040 C.2-8-042

Megbízhatósági tényező az elterjedt, brand227 megoldások alkalmazása Operációs rendszerek, adatbázis kezelők esetén hibatűrő megoldások alkalmazása Több szoftver együttes alkalmazása esetén együttműködő képesség vizsgálata Nem dobozos szoftverek esetén szabványos fejlesztői módszertan és dokumentáció előírása Rendszeres szoftverfrissítés és támogatási szolgáltatás megrendelése A szoftverek erőforrásigényeinek betartása/előírása

C.2.1.4.6 Környezet C.2-8-043 C.2-8-044 C.2-8-045 C.2-8-048 C.2-8-049

Az igények szerint méretezett többirányú betáplálás biztosítása automatikus átkapcsolással A rendelkezésre állási terv szerinti szünetmentes megoldás biztosítása A szünetmentes tápellátás monitorozása Áramingadozási, villám védelem Földelés228

223

Ezt legjobban az eszközökhöz igénybe vehető szerviz szolgáltatások, rendelkezésre állás, alkatrész ellátottság és a garanciális feltételek alapján lehet lemérni. Eszköz és operációs rendszer frissítések, BIOS frissítés, távmenedzselhetőség, stb. 224 Pl. az otthoni (home) használatra szánt típusok mellőzése, vékony kliens alkalmazásánk számbavétele 225 Ezen a piacon elérhető az élettartam garancia az eszközökre valamint sok beépített extra szolgáltatás (hálózatfigyelés, vírusvédelem,stb.) 226 A földelés és villámvédelem jóságát rendszeres időközönként méréssel ellenőrizni kell 227 Jogtiszta, licenszelt és fejlesztett, verziózott

125


C.2-8-050

Az eszközök előírt üzemhőmérsékletének biztosítása

C.2.1.4.7 Helyreállíthatóság C.2-8-056 C.2-8-057

Archiválási rendszer alkalmazása Kritikus alkalmazások esetén duplikát megoldás alkalmazása

C.2.1.5 Informatikai biztonság menedzsment C.2.1.5.1 Kockázatelemzés C.2-9-010 C.2-9-012 C.2-9-013 C.2-9-015

Meg kell becsülni a kockázatok megvalósulásának valószínűségét Dönteni kell az egyes kockázatok javításáról a kockázatarányosság figyelembevételével A kockázatjavítási döntés esetén pontos tervet kell készíteni, mely magába foglalja a szükséges tevékenységeket és a várt hatások elemzését. Dönteni kell az egyes kockázatok elfogadásáról a kockázatarányosság figyelembe vételével

C.2.1.5.2 Informatikai vagyon kezelése

C.2-12-001

C.2-12-005

A vagyonleltárt oly módon kell felvenni, hogy az alkalmas legyen az egyértelmű azonosításra, és az egyes vagyontárgyak szervezeten belüli mozgásának követésére. Az informatikai vagyon leltárát az általános leltári előírások mellett olyan részletezettséggel kell vezetni, hogy folyamatosan figyelemmel lehessen kísérni az eszközök garanciális mutatóit, avultsági szintjét, meghibásodási, szervizelési és javítási eseményeit. Az informatikai vagyon ily módon történő kezelése segítséget nyújt a kockázat elemzésben, a beruházások tervezésében. Külön rendelkezni kell a hosszú őrzési idejű adatcsoportok esetleges technológiaváltást követő migrálási megoldásairól. Ide kell érteni az adatkezelő szoftverek váltásának következményeit és a tárolási eljárások váltásának feltételeit.

C.2.1.5.3 A személyzet biztonsága

C.2-13-002

C.2-13-005

Az alkalmazottak vizsgálata a felvételnél. Ellenőrizni kell, hogy a hozzáértés valódi. Szükség esetén ellenőrizni kell a megbízhatóságot. Kiképzetlen új személyzet esetén ki kell dolgozni a betanítás rendjét és felelősségi körét. Folyamatosan kapcsolatot kell tartani a személyzettel. Hirtelen élethelyzet változások, romlások biztonsági problémákat okozhatnak. A biztonságot megsértők megfelelő szintű számonkérése

C.2.1.5.4 Fizikai és környezeti biztonság C.2.1.5.4.1 Területek védelme

C.2-14-001 228

Azokon a területeken, ahol információt, vagy érintett eszközöket tartanak, biztonsági elhatárolókat, határzónákat kell alkalmazni. Belépés védelem a

A földelés és villámvédelem jóságát rendszeres időközönként méréssel ellenőrizni kell

126


C.2-14-003

csak a személyzet által használt területeken. Lehetőség szerint a beléptetési védelmet portaszolgálattal, örző-védő szolgálattal kell kiegészíteni. Ebben az esetben a feladatköröket rögzíteni kell. Külső és környezeti veszéllyel szembeni védelem (tűz, árvíz, földrengés, robbanás villámlás, egyéb katasztrófák)

C.2.1.5.4.2 Berendezések védelme

C.2-14-006

C.2-14-007

C.2-14-008

C.2-14-014

Tartalék berendezéseket, mentett adatokat tartalmazó hordozókat úgy kell elhelyezni, hogy a megfelelő védelme mellett az alap berendezéstől/adattárolótól olyan távolságra legyenek, hogy minimalizálják annak lehetőségét, hogy bármilyen külső hatás mindkettőt együttesen érjen. A berendezések védelme az áramkimaradástól. A kockázatelemzés során tisztázni kell, hogy melyek elemeket, milyen szinten kell védeni ahhoz, hogy a folyamatos működés az elvárt szinten tartható legyen. A védelem a többutas tápellátástól a generátoros tartalék ellátásig terjedhet. A tartalék áramforrások állapotát kidolgozott terv és felelősségi kör mellett rendszeresen tesztelni kell. Kábelbiztonság. Az energiaátviteli és az adathálózatot védeni kell a károsodástól, illetve lehallgatástól. Amennyiben például a LAN hálózatok csomópontjai és aktív elemei a közforgalomtól nem elzárt területen helyezkednek el, gondoskodni kell megfelelő fizikai védelmükről. A hálózatot védeni kell az esetleges sérülésektől is egyrészt a megfelelően biztonságos kábelutak kialakításával, másrészt a megfelelő dokumentálással. Elő kell írni, hogy a szervezeten belüli egyéb karbantartásokat ezekkel a dokumentumokkal mindig egyeztetni kell. Vagyontárgyak mozgatása. A vagyontárgyakat csak az adott terület információ biztonságával megbízott felelős ellenjegyzésével lehet áthelyezni, telephelyről kivinni.

C.2.1.5.5 A kommunikáció és az üzemeltetés biztonsága C.2.1.5.6 Üzemeltetési eljárások és felelősségi körök C.2-15-002

C.2-15-003

C.2-15-004

Az eszközök és rendszerek változásait szabályozni kell. Rögzíteni kell a változtatásra jogosultak körét, a változtatási eljárásokat, az eljárásokat megelőző tervezési folyamatot, az esetleges helyreállítási eljárásrendet, a változtatást követő tesztelési, dokumentálási feladatrendszert. Az üzemeltetési feladatköröket és felelősségi területeket szét kell választani. A szétválasztás során biztosítani kell, hogy az ellenőrző szerepkőr mindig elkülönüljön a felhasználói szerepkőrtől. Ezzel az esetleges visszaélések a független ellenőrzések révén csökkenthetők. A fejlesztés, tesztelés, üzemeltetés eszközeit külön kell választani. Meg kell akadályozni, hogy az üzemeltetés biztonságát a fejlesztés, tesztelés esetleges szélsőséges következményei befolyásolják. Továbbá élesen el kell különíteni az üzemeltetési jogosultságokat és adathozzáférést a fejlesztési és tesztelési jogosultságoktól.

C.2.1.5.7 Harmadik fél szolgáltatásnyújtásának irányítása 127


C.2-16-003

A harmadik fél által végzett szolgáltatásokat folyamatosan monitorozni kell.

C.2.1.5.8 Rendszertervezés és elfogadás

C.2-17-001

C.2-17-002

Az üzemeltetés során folyamatosan hangsúlyt kell helyezni a kapacitásmenedzsmentre. Azaz folyamatosan monitorozni kell az erőforrások kapacitás igényét, illetve kapacitás leterheltségét. A monitoring lehetőséget ad a jövőbeli kapacitásigények, erőforrásigények meghatározására, tervezésére. Rendszerszintű változtatásokra átvételi eljárást kell kidolgozni.

C.2.1.5.9 Rosszindulatú szoftverek elleni védelem C.2-18-002

C.2.1.5.10 C.2-20-001 C.2-20-002

A központi eszközök védelme során biztosítani kell a támadások dokumentálását

Hálózat biztonsága A hálózati szolgáltatásokra SLA-t kell megállapítani, amelyet folyamatosan be kell tartani229/tartatni. A hálózati szolgáltatások biztonságát folyamatosan ellenőrizni kell.

C.2.1.5.10.1 Adathordozók biztonsága

C.2-21-001 C.2-21-002

C.2-21-004

A mobil adathordozók kezelésre eljárásrendet kell kidolgozni. Az egészségügyi adatokat kezelő rendszereket védeni kell az illetéktelen mobil hordozóktól230, illetve bármilyen más adatkinyerési eljárástól. A dokumentációkat az adatokhoz hasonlóan védeni kell a jogosulatlan hozzáféréstől. Azok egyrészt szerzői jogi védelem alatt állhatnak, másrészt illetékteleneknek információt szolgáltathatnak a rendszer felépítéséről csökkentve ezáltal a biztonságot.

C.2.1.5.10.2 Információcsere

C.2.1.5.11 C.2-23-001

C.2-23-002

C.2-23-03

C.2.1.5.12 C.2-24-001 C.2-24-003

Elektronikus szolgáltatások Az online tranzakciókat védeni kell lehallgatástól, esetleges jogosulatlan módosítástól, téves helyre kézbesítéstől. Az egészségügyi rendszereket231 védeni kell a rendszert az esetleges rosszindulatú behatolástól. Ez minden esetben úgy történhet, hogy külső kapcsolatok sohasem jöhessenek létre közvetlen kapcsolódás útján. Azok csak külső védelmi vonalakon történjenek. Meg kell védeni az intézmények által közzétett információkat (pl. web oldalon) a jogosulatlan módosítástól.

Monitoring A felhasználói tevékenységről, kizárásokról, biztonsági eseményekről logot kell vezetni. Eljárásokat kell kidolgozni a rendszerek használatának figyelésére. Az

229

A hálózati szolgáltatások megfelelőségét, teljesülést mérési jegyzőkönyvekkel kell dokumentálni. Pl: USB portok tiltása 231 Kórházi rendszerek, háziorvosi rendszerek, stb. 230

128


C.2-24-005

C.2-24-006

eltéréseket folyamatosan követni kell, és esetlegesen be kell avatkozni. Naplózni kell a rendszeradminisztrátori tevékenységeket, a rendszerhibákat, az arra adott válaszokat az esetleges anomáliák kiszűrése érdekében A szervezeten belül működő minden rendszer órajelét szinkronizálni kell. Az egyes rendszerek együttműködését az eltérő órajelek veszélyeztetik. Az egészségügyi adminisztrációs rendszereknél az évváltás szinkronizálása kiemelt fontosságú.

C.2.1.6 A hozzáférés ellenőrzése C.2-25-001 C.2-25-002

A hozzáférést szabályzat szinten kell kezelni. A felhasználók hozzáférés megadását és megvonását regisztrálni kell.

129


C.2.2 Szolgáltatás bevezetés

C.2.2.1 Szolgáltatási eszköz és konfiguráció menedzsment C.2-26-001 C.2-26-002 C.2-26-003 C.2-26-004 C.2-26-005

Az informatikai komponenseket fel kell mérni és nyilván kell tartani verziószámmal, komponensekkel, kapcsolatokkal A nyilvántartást úgy kell megoldani, hogy az információval szolgáljon a leltár, az üzemeltetés, a változáskezelés számára. A nyilvántartásba követni kell az eszköz állapotát Menedzsment rendszernek támogatni kell a központi vezérlést, változáskezelést A nyilvántartások monitorozásával információval kell szolgálni a változáskezelés felé a tervezhető felújítások, cserék tekintetében

C.2.2.2 Változáskezelés Az informatikai rendszerekkel szemben változtatási igények merülhetnek fel szervezeti változások, tevékenységi változások, probléma megoldások, új technológiák, bővülő igények, hardver232 és szoftver bővítések vagy csere233 esetén, új folyamatok belépése, folyamatok módosulása stb. miatt. A változáskezelés célja, hogy a változtatások végrehajtásának sikerességét biztosítsa a káros hatások kizárása, vagy minimalizálása mellett.

C.2.2.2.1 Intézményen belüli változtatási folyamatok C.2-27-001 C.2-27-002 C.2-27-003 C.2-27-004 C.2-27-005 C.2-27-006 C.2-27-007 C.2-27-010 C.2-27-011

C.2-27-015 C.2-27-016

Egységes változáskezelési rendszert kell működtetni A változáskérelmeket egységesíteni kell és meg kell fogalmazni a kérelmezők jogosultsági rendszerét Ki kell nevezni a változtatási kérelmek elsődleges szűrése jogosult személyzetet Biztosítani kell a változtatások és annak hatásainak felmérését, a rendszerbe integrálhatóság vizsgálatát A változtatások kategorizálása erőforrás alapján A változtatások kategorizálása hatásuk alapján A változtatások prioritásának meghatározása A változtatást dokumentálni kell. A változtatások tesztelése – a változtatásokat tesztelni csak az éles rendszerrel azonos beállításokkal rendelkező tesztrendszeren lehet. A tesztelés során a funkcionális folyamatteszt mellett tesztelni kell a megbízhatóságot, a biztonságot és a teljesítményigényt is. Sürgős változtatási kérelem esetében sem lehet eltekinteni a jóváhagyástól, a minimális teszttől, a mentéstől, a felhasználói értesítéstől, a végrehajtás engedélyezésétől. A dokumentálás, részletes tesztelés, hatáselemzés utólag elvégezendő A változtatások hatásait elemezni kell.

C.2.2.2.2 Külső szolgáltatóhoz kapcsolódó változtatási folyamatok 232 233

Pl: HDD bővítés, stb. Pl: adatbázis kezelő váltás, kommunikációs könyvtás változtatás, stb.

130


C.2-27-017

C.2-27-018

Abban az esetben, amennyiben a változtatást az intézmény kezdeményezi külső szolgáltató rendszerén, a létrehozás kivételével minden folyamatot be kell tartani Abban az esetben, amennyiben a változtatást külső szolgáltató kezdeményezi rendszerkövetés vagy javítás miatt, a jóváhagyás, tesztelés, végrehajtás előkészítés, mentés, végrehajtás, elemzés az előírás.

C.2.2.3 Kiadás és üzembe állítás A kiadáskezelés célja a szolgáltatás tervezés során a változáskezelés eredményeként beszerzett, kialakított folyamatok, szoftverek, hardverek bevezetése, üzembe állítása. A szoftver kiadás lehet különbségi, amely csak a legutóbbi kiadás óta változott elemeket tartalmazza, és lehet teljes kiadás, mely során a szoftver/folyamat minden elemét együtt állítjuk üzembe.

C.2.2.3.1 Teljes vagy jelentős kiadásnál a alkalmazni

Projektmenedzsment előírásait kell

C.2.2.4 Konfigurálás C.2-28-001 C.2-28-002 C.2-28-003 C.2-28-004 C.2-28-005 C.2-28-006

Hardver kiadások esetén meg kell tervezni az egyes elemek összeállítási módjait. Hardver kiadások esetén tesztelni kell, hogy a tervezett konfigurációk megfelelnek-e az alkalmazások és a felhasználók által támasztott követelményeknek. A rendszert a felhasználás igényei szerint paraméterezni, konfigurálni kell. A paraméterezés teljes kiadások esetén a szállító feladata A paraméterezés része a rendszer szótárak létrehozása, panelek létrehozása, a rendszerből kinyerhető dokumentumok paraméterezése is. Szoftver kiadások esetén tesztelni kell a rendelkezésre álló hardver környezetben a szoftver működőképességét.

C.2.2.5 Kiadás elfogadása C.2-29-002 C.2-29-003 C.2-29-004 C.2-29-005 C.2-29-008 C.2-29-009 C.2-29-010 C.2-29-011

A tesztelésre az éles környezettel megegyező tesztkörnyezetet kell létrehozni. A tesztelést a bevezetők és a felhasználók együttesen végzik. Az összes funkciót tesztelni kell Az integrációs kapcsolatokat tesztelni kell A terhelési teszteket a várható éles terhelésnek megfelelő értékek mellett kell végezni. A tesztek során pontonként rögzíteni kell az eredményességet, eltérést, sikertelenséget Hibás teszteredmény esetén az adott témakörre vonatkozó teljes tesztet eredménytelennek kell nyilvánítani. Korábbi tesztek területeit érintő beavatkozás esetén a megelőző teszteket ismételni kell.

C.2.2.5.1 Telepítés tervezése 131


C.2-30-001 C.2-30-003 C.2-30-005 C.2-30-007

Ki kell dolgozni a telepítés fázisait Meg kell tervezni a migrálási eljárásrendet Biztosítani kell a telepítéshez szükséges infrastruktúrát – parkolás, eszköztárolás, helyszíni támogatás feltételei Az oktatás beosztásáról, menetéről, tartalmáról tervet kell készíteni.

C.2.2.5.2 Oktatás C.2-31-002 C.2-31-003 C.2-31-004 C.2-31-005 C.2-31-008 C.2-31-009 C.2-31-010 C.2-31-011

Az oktatást úgy kell szervezni, hogy az oktatás és az éles üzem között 2 hétnél hosszabb idő nem telhet el. Az oktatások max. 12 fős csoportban végezhetők. Az oktatások során minden hallgató részére külön gépet kell biztosítani Az oktatások során minden hallgató részére oktatási anyagot kell biztosítani. Külön menedzseroktatást kell tartani a rendszert közvetlenül nem használó vezetők részére. Olyan kulcsfelhasználókat is oktatni kell, akik a rendszert átfogóan ismerik, és alkalmasak későbbi új felhasználók oktatására. Az oktatást számonkéréssel kell zárni. Teljes kiadás vagy nagyon jelentős különbségi kiadás esetén az éles indulást követően utólagos oktatást, utólagos konzultációt kell biztosítani.

C.2.2.5.3 Telepítés C.2-32-002 C.2-32-003

Az elfogadásnak megfelelő konfigurációk és szoftver telepíthető. Az adatok migrálása az elfogadott migrálási eljárásnak megfelelő ellenőrzött forrás és eljárási algoritmus mellett történik.

C.2.2.6 Ismeret menedzsment Az ismeretmenedzsment célja, hogy minden szereplő az adott területen és pillanatban elegendő információval, tudással, készséggel rendelkezzen. C.2-33-003 Biztosítani kell a személyes támogatás rendszerét C.2-33-004 A szereplő felkészültségét monitorozni kell C.2-33-005 Biztosítani kell az ismerethiányok megszüntetését C.2-33-006 Biztosítani kell az ismeretek felfrissítését

C.2.2.7 Szolgáltatás validálás és tesztelés C.2-34-001 C.2-34-002 C.2-34-003

A szolgáltatás bevezetés csak záró tesztek után zárható le A záró tesztek során az éles rendszeren követni kell az éles üzem hibamenetes működését A záró tesztek során vizsgálni kell, hogy a létrejött rendszer milyen szinten felel meg a tervezés során lefektetett elképzeléseknek.

C.2.3 Szolgáltatás üzemeltetés

C.2.3.1 Eseménymenedzsment Az esemény egy olyan állapotváltozás, amely jelentőséggel bír az IT infrastruktúra vagy egy szolgáltatás biztosítása szempontjából. Egy esemény jelezheti azt, hogy valami nem működik megfelelően. Így egy esemény egy incidens kialakulásához vezethet. Esemény jelezhet előre normál, rutinszerű tevékenységet is. 132


Az eseménymenedzsment célja a rendelkezésre állás és teljesítmény monitorozás számára az információ biztosítása. Az eseményeket csoportba kell sorolni úgy, mint informális események – a C.2-35-001 normális működést dokumentáló, szokatlan események – az általánostól eltérő, de nem incidens jellegű, incidensek – a normálistól eltérő esemény C.2-35-002 Az eseményeket a rendszer teljes életciklusán keresztül kezelni kell Az események megjelenése eltérő típusú lehet, melyeket megfelelő C.2-35-003 interfészek segítségével kell az eseménymenedzsment részére feldolgozhatóvá tenni. Központi hardverek eseményeinek mérései: Szerver meghibásodási jelzések, C.2-35-004 hőmérsékleti jelzések, táblatér jelzések, tápellátási jelzések, újraindítások. Operációs rendszerek eseményeinek mérései: Meghibásodási jelzések, C.2-35-005 frissítések jelzései Védelmi rendszerek eseményeinek mérései: Támadások jelzései, behatolási C.2-35-006 kísérletek jelzései, frissítések jelzései Alkalmazói rendszerek eseményeinek mérései: Írás, módosítás, olvasás C.2-35-007 esetén: ki, mikor, mit. Hibák jelzései, frissítések jelzései Rendszerek kapcsolatainak, mérései: Adatküldés, adatfogadás honnan hova, C.2-35-008 mikor, mit. Hibák jelzései. Külső kommunikáció, mail rendszerek mérései: ki, mikor, mit, honnan hová. C.2-35-009 Hibák jelzései. Az eseményeket pl. naplókban úgy kell tárolni, hogy a tárolási idő megfeleljen a vonatkozó jogszabályoknak. Például az egészségügyi C.2-35-010 adminisztrációs rendszer hozzáférés naplóit az egészségügyi adatvédelmi törvény szerint. Az eseményeket úgy kell tárolni, hogy bármilyen elemzésre visszamenőleg C.2-35-011 is alkalmasak legyenek. Pl. jogosulatlan hozzáférés kimutatása bizonyító erejű módon. Meg kell határozni az események feldolgozásának algoritmusát, és a C.2-35-012 kimeneti szinteket. Kimenetek lehetnek: esemény rekord, incidens rekord, probléma rekord, C.2-35-013 automatikus válasz, riasztás

C.2.3.2 Incidens menedzsment Az incidens egy olyan esemény, amely nem része a szolgáltatás normális működésének és annak megszakadását vagy minőségének romlását okozhatja. Az incidens hátterében lévő ok a probléma. Az incidenskezelés célja, hogy a szolgáltatás normális állapota a lehető leggyorsabban visszaállításra kerüljön úgy, hogy csökkentse ezáltal az incidens az egészségügyi szolgáltató működésére gyakorolt hatását. C.2-36-001 Definiálni kell az adott rendszerre az incidens fogalmát. Az incidensek besorolási rendszerének kialakításakor figyelembe kell venni az incidens hatását a rendszerre, az incidens kiterjedtségét, az érintett rendszerek prioritását, az incidens hatását az SLA-ra. Például egészségügyi C.2-36-004 intézményeknél egy HIS rendszert alapszolgáltatásaiban érintő incidens prioritása és besorolása más, mint a gazdasági rendszert hasonló módon érintő incidens. Az incidens menedzsment részére bemeneti interfészt kell biztosítani az C.2-36-008 eseménymenedzsment felől. 133


C.2-36-009

C.2-36-010

Az incidens menedzsmentnek kimeneti interfészt kell biztosítani a problémamenedzsment, a konfiguráció menedzsment, a kapacitás menedzsment, a rendelkezésre állás menedzsment, a szolgáltatás szint menedzsment felé. A nyilvántartást úgy kell megszervezni, hogy a kimenet (készre jelentés, megkerülés, stb.) szerint az incidens lezárást követő utóélete követhető legyen.

C.2.3.2.1 Ügyfélszolgálat C.2-37-001 C.2-37-003 C.2-37-004 C.2-37-005 C.2-37-006

10 gépes hálózat felett ügyfélszolgálatot kell létrehozni. Az ügyfélszolgálaton olyan hibajegykezelést kell alkalmazni, mely lehetővé teszi a hiba megoldásának eseménykövetését, személyi követését, időpont követését, a szükséges statisztikák lekérését. Szoftverszállító felé elő kell írni, hogy biztosítson olyan felületet, melyen az eseménykövetés megvalósítható. Az ügyfélszolgálatot úgy kell felépíteni, hogy optimálisan kiszolgálja az adott feladatokat és az adott szervezetet. Több telephelyes szervezet esetében – amennyiben az egyes telephelyek elérik az ügyfélszolgálat alsó határát – több szintű ügyfélszolgálatot kell létrehozni.

C.2.3.3 Probléma menedzsment A problémamenedzsment célja, hogy az incidensek kiváltó okait megtalálja, illetve minimálisra csökkentse. A hibajegy kezelő rendszernek alkalmasnak kell lennie, hogy az incidenst a C.2-38-001 problémakezelés igényeinek megfelelő pontossággal írja le Biztosítani kell a lehetőséget a vélhetően azonos problémához köthető C.2-38-002 incidensek szűrésére, statisztikájára, behatárolására C.2-38-003 Az incidenseket kategorizálni kell előfordulási gyakoriságuk, hatásuk szerint A problémamegoldást a kategóriákhoz kapcsolódó prioritási sorrendben kell C.2-38-004 kezelni. A probléma megoldására felelős személyt kell kijelölni, aki a problémát a C.2-38-005 hibajegy kezelő rendszer információi alapján és az előírt prioritási sorrendben kezelheti. Amennyiben a problémamegoldás eredménye a rendszerben változást hoz C.2-38-006 létre, alkalmazása során a változáskezelésnek megfelelően kell eljárni.

C.2.3.4 Kérésteljesítés menedzsment A kérésteljesítés menedzsment lehetőséget biztosít a rendszer szolgáltatásai keretén belüli olyan kérések szabályozott elbírálására és teljesítésére, melyek teljesítése a kérő jogosultsági szintjén kívül esik. (Pl. jogosultságok beállítása, funkciók hozzárendelése stb.) C.2-39-001 A kéréseket egységesített formába és nyilvántartásba kell szervezni C.2-39-002 Ki kell alakítani a kérések elbírálásának eljárásrendjét Meg kell határozni a végrehajtási sorrendet alkotó prioritási rendet, és a C.2-39-004 hozzá tartozó határidőket C.2-39-005 A teljesített kérésekről meg kell szervezni az értesítési rendet.

134


C.2.3.5 Hozzáférés menedzsment A jogosult felhasználók számára biztosítja a szolgáltatás felhasználásának jogát, működését, amit a jogosulatlanoknak számára megtagad. A jelszó a felhasználó által megváltoztatható meghatározott időszakonként C.2-40-004 kötelező módon A felhasználók részére szerepeket kell meghatározni. A szerepek lehetnek egyediek, csoportba sorolhatók, kiterjesztettek. Egy egészségügyi C.2-40-006 szolgáltatónál például jellemző szerepcsoportok: orvos, ápoló/asszisztens, betegirányító, hr-es, pénzügyi, könyvelő, rendszergazda. Jellemző egyedi szerepek orvosvezető, gazdasági vezető, adatvédelmi felelős. Lehetőséget kell adni, hogy egy személyhez több szerep is kapcsolható C.2-40-007 legyen Vizsgálni kell az esetleges szerepkonfliktust, azaz ha egy személy több C.2-40-008 szerepe egymásnak ellentmondó C.2-40-009 A szerepekhez jogosultságokat kell rendelni A felhasználókat és jogosultságaikat egy nyilvántartási C.2-40-013 rendszerben/adatbázisban kell tárolni. A felhasználók jogosultsági életciklusának idősorosan követhetőnek és C.2-40-014 megőrzöttnek kell lennie. C.2-40-015 Tárolni kell a jogosultságot engedélyező és a kiadó azonosítóit. A jogosultság igénylés lehet egyedi pl. az adott dolgozó további feladatot C.2-40-016 kap, és vezető igényel hozzá jogosultságot A jogosultság igénylés lehet automatikus pl. új orvos belépése esetén a hr C.2-40-017 értesítése alapján orvos csoportba kerül. A rendszert monitorozni kell, hogy az egyes jogosultságok folyamatosan C.2-40-018 megfelelnek a szerepköröknek.

C.2.3.6 Folyamatos szolgáltatásfejlesztés A folyamatos szolgáltatás fejlesztés célja, hogy a rendszer szolgáltatásai minél jobban illeszkedjenek a változó felhasználói, műszaki környezeti követelményekhez. C.2-41-001 Ki kell dolgozni a mérési indikátor rendszert C.2-41-002 Az indikátorokat monitorozni kell C.2-41-003 A mérési eredményeket analizálva az illeszkedés mértékét elemezni kell Az elemzés eredményeit felhasználva ajánlatot kell tenni a szolgáltatás C.2-41-004 tervezés felé a további fejlesztésekre

C.2.3.7 Üzemeltetési szerződésmenedzsment C.2-42-001 C.2-42-002

A szerződéseknek illeszkednie kell az egységes üzemeltetési rendszerbe Üzemeltetési feladatok kiszervezése során figyelembe kell venni a kockázatelemzés eredményeit

135

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

Recommend Documents