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

Az egészségügyi információs rendszerek követelményei (verzió: 9.0)

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

Tartalomjegyzék

Tartalomjegyzék Bevezető..................................................................................................................................... 1 1

Előszó.................................................................................................................................. 1 Általános feladat meghatározás........................................................................................................... 1 A jelen dokumentum célja .................................................................................................................. 2 A dokumentum kapcsolata az orvosszakmai környezettel.................................................................. 3

2

Szószedet............................................................................................................................. 4

Követelmények és minősítés .................................................................................................... 6 3 Központi kormányzati egészségügyi informatikai fejlesztések, a rendszerkövetelmények anyag illeszkedése ...................................................................................................................... 6 3.1 Ágazati központi e-Egészségügyi kulcsprojektek......................................................................... 6 3.1.1 TÁMOP 6.2.1 Humánerőforrás (HR) monitoring rendszer .......................................................... 9 3.1.2 TÁMOP 6.2.3 Országos egészségmonitorozási és kapacitástérkép adatbázis- és alkalmazásfejlesztés .................................................................................................................................... 10 3.1.3 TIOP 2.3.2 Nemzeti Egészségügyi Informatikai (e-Health) Rendszer - Elektronikus közhiteles nyilvántartások és ágazati portál fejlesztése ................................................................................................ 11 3.1.4 TIOP 2.3.1 Nemzeti Egészségügyi Informatikai (e-Health) Rendszer: központi informatikai rendszerek fejlesztése az intézményen belüli betegazonosítási rendszerek fejlesztésének biztosításához és az intézményen belüli betegazonosítási rendszerek fejlesztése ................................................................... 12 3.1.5 EKOP 2.3. Egészségbiztosítási ügyfélkapcsolatok fejlesztése, egészségügyi rendszerekbe integrált adatkezelés és azonosítás megvalósítása ....................................................................................... 13 3.1.6 TIOP 2.3.3 Nemzeti Egészségügyi Informatikai (eHealth) Rendszer - Térségi, funkcionálisan integrált intézményközi információs rendszerek kiépítése .......................................................................... 14 3.1.7 TÁMOP 6.2.7 Nemzeti Egészségügyi Informatikai (eHealth) Rendszer bevezetésének támogatása – módszertan - és képzésfejlesztés............................................................................................ 15

3.2 A Semmelweis-Terv egyéb fejlesztéspolitikai konstrukcióihoz (pályázataihoz) való viszony .. 16

4

Az informatikai rendszerek követelményei ...................................................................... 19 4.1 Az informatikai infrastruktúra architektúrális követelményei .................................................... 19 4.1.1 Bevezetés .................................................................................................................................... 19 4.1.2 Jogi formában rögzítendő ajánlások az egészségügyi informatikai rendszerek védelme érdekében 19 4.1.3 Általános architekturális követelmények .................................................................................... 21 4.1.4 Infrastruktúrális követelmények ................................................................................................. 23 4.1.5 Mentési, archiválási, visszatöltési követelmények...................................................................... 24 4.1.6 Biztonságos működéssel-működtetéssel kapcsolatos követelmények ........................................ 25 4.2 Az egészségügyi ellátási szintek specifikus követelményei ....................................................... 31 4.2.1 Az alapellátás specifikumai ........................................................................................................ 31 4.2.2 Az szakellátás specifikumai ........................................................................................................ 37 4.2.3 A betegfelvétel során elvárt minimális funkcionalitás................................................................ 55 4.2.4 A Járóbeteg szakellátás során elvárt minimális funkcionalitás ................................................... 56 4.2.5 A fekvőbeteg szakellátás során elvárt minimális funkcionalitás................................................. 57 4.2.6 Az elektronikus kórlaptól és lázlaptól elvárt minimális funkcionalitás ...................................... 59 4.2.7 Az ápolási dokumentációtól elvárt minimális funkcionalitás ..................................................... 60 4.3 Intézményi működést támogató informatikai rendszerek általános és specifikus követelményei 62 4.3.1 Intézményi működést támogató informatikai rendszerek általános követelményei (valamennyi ilyen típusú megoldásnál)............................................................................................................................ 62 4.3.2 Intézményi működést támogató informatikai rendszerek specifikus követelményei (a releváns megoldásoknál) ........................................................................................................................................... 62 4.4 Intézményközi rendszerszolgáltatások általános és specifikus követelményei........................... 70 4.4.1 Intézményközi rendszerszolgáltatások általános követelményei ................................................ 70 4.4.2 Intézményközi technológiai protokollok követelményei ............................................................ 72

Összeállította a GYEMSZI szakértői munkacsoportja

i

Tartalomjegyzék

4.5 Üzemeltetési követelmények – Szolgáltatásmenedzsment kérdések .......................................... 73 4.5.1 Szolgáltatás tervezés ................................................................................................................... 73 4.5.2 Szolgáltatás bevezetés................................................................................................................. 85 4.5.3 Szolgáltatás üzemeltetés ............................................................................................................. 88

5

A fejlesztési pályázat és a megvalósítási projekt követelményei, minősítése .................. 93 5.1 Az intézmény felkészültségének követelményei......................................................................... 95 5.1.1 A fejlesztés elhelyezése az intézmény működésében ................................................................. 95 5.1.2 Intézményi követelmények a fejlesztés előkészítésére ............................................................... 97 5.2 A beszállító felkészültségének és ajánlatának követelményei ................................................... 98 5.2.1 Beszállítói követelmények .......................................................................................................... 98 5.2.2 Az ajánlott megoldás illeszkedése a kiíráshoz ............................................................................ 99 5.3 A fejlesztés előkészítésének, megvalósításának és eredményének, követésének követelményei 102 5.3.1 A fejlesztés előkészítésének tervezési feladatai és módszerei .................................................. 102 5.3.2 A Projekt Alapító Dokumentum követelményei....................................................................... 103 5.3.3 A fejlesztéssel kapcsolatos szerződés(háló) kialakításának követelményei.............................. 104 5.3.4 Szoftverszerződésekkel kapcsolatos elvárások ......................................................................... 105 5.3.5 A fejlesztés megvalósítása követésének követelményei ........................................................... 106 5.3.6 A fejlesztés eredményének követelményei ............................................................................... 107

6

A követelmények alapján folytatott minősítés módszertana, folyamata és szervezete .. 109 6.1 A minősítés célkitűzése, alanyai ............................................................................................... 109 6.2 Információs rendszerek ............................................................................................................. 109 6.2.1 Elvárás a minősítő eljárással szemben ...................................................................................... 109 6.2.2 Az eljárás kimeneti pontja ........................................................................................................ 110 6.2.3 A minősítés eredményterméke.................................................................................................. 110 6.2.4 A minősítés eredményének hatása a vizsgált objektumra, intézményre és ágazati szervekre... 110 6.3 Információs rendszerfejlesztési projektek................................................................................. 111 6.3.1 Elvárás a minősítő eljárással szemben ...................................................................................... 111 6.3.2 Az eljárás kimeneti pontja ........................................................................................................ 111 6.3.3 A minősítés eredményterméke.................................................................................................. 111 6.3.4 A minősítés eredményének hatása a vizsgált objektumra, intézményre és ágazati szervekre... 111 6.4 Információs rendszerfejlesztési projektet vezető egészségügyi intézmény .............................. 112 6.4.1 Elvárás a minősítő eljárással szemben ...................................................................................... 112 6.4.2 Az eljárás kimeneti pontja ........................................................................................................ 112 6.4.3 A minősítés eredményterméke.................................................................................................. 112 6.4.4 A minősítés eredményének hatása a vizsgált objektumra, intézményre és ágazati szervekre... 113 6.5 A minősítő eljárás módszertana ................................................................................................ 113 6.5.1 A minősítő eljárás során alkalmazott módszer.......................................................................... 113 6.5.2 Információs infrastruktúra minősítése ...................................................................................... 115 6.5.3 Egészségügyi információs rendszerek szolgáltatásainak minősítése ........................................ 117 6.5.4 Információs rendszerfejlesztési projekt minősítése................................................................... 117 6.5.5 Szervezet minősítése az információs rendszer fejlesztési projekt szempontjából..................... 119 6.6 A rendszerminősítés folyamata, a minősítések publikálása ...................................................... 119 6.6.1 Információs rendszer minősítésének folyamata ........................................................................ 119 6.6.2 Fejlesztési projekt minősítésének folyamata............................................................................. 120 6.6.3 Szervezet minősítésének folyamata .......................................................................................... 121 6.7 A rendszerminősítés szervezete/intézménye............................................................................. 121 6.7.1 A minősítő szervezet/intézmény jogállása ................................................................................ 122

7

Javasolt jogszabályi változtatások .................................................................................. 123

Mellékletek............................................................................................................................ 125 8

A követelmények rendszerét meghatározó fejezetek...................................................... 125 8.1 Az egészségügyi információs rendszerek nemzetközi minősítési követelményei és gyakorlata 125 8.1.1 A fejezet célja ........................................................................................................................... 125 8.1.2 A globális egészségügyi trendek hatása az egészségügyi informatikára................................... 126


ii

Tartalomjegyzék 8.1.3 Az Európai Unió egészségügyi ellátással kapcsolatos szabályozása és politikája.................... 128 8.2 Egészségügyi gazdasági információs rendszerek és VIR rendszerek speciális adatkezeléssel kapcsolatos minősítése ajánlásai ..................................................................................................... 142 8.2.1 Törvényi háttér.......................................................................................................................... 142 8.2.2 Hatókör ..................................................................................................................................... 144 8.2.3 Személyi adatok védelme a nem klinikai rendszerekben.......................................................... 145 8.2.4 A személyes adatok kezelésével kapcsolatos tevékenységek naplózása................................... 146 8.2.5 A személyes adatok továbbításával kapcsolatos tevékenységek naplózása .............................. 146 8.2.6 Egyéb adatok továbbításával kapcsolatos elvárások................................................................. 147 8.3 Intézményi portálok közzététellel kapcsolatos tartalmi követelményei.................................... 148 8.3.1 Törvényi háttér......................................................................................................................... 148 8.3.2 Szervezeti és személyzeti adatok .............................................................................................. 149 8.3.3 Tevékenységre, működésre vonatkozó adatok.......................................................................... 151 8.3.4 Gazdálkodási adatok ................................................................................................................. 153 8.3.5 Várólistával kapcsolatos adatok................................................................................................ 155 8.3.6 Közbeszerzési eljárással kapcsolatos adatok ............................................................................ 156 8.4 A telemedicina alkalmazásának helyzete Magyarországon, a telemedicina rendszerkövetelményei.................................................................................................................... 158 8.4.1 Szabványosítás.......................................................................................................................... 159 8.4.2 Finanszírozás. ........................................................................................................................... 159 8.4.3 Orvosi gyakorlatba vétel. .......................................................................................................... 160 8.4.4 Jogszabályi környezet. .............................................................................................................. 161 8.5 IT konszolidációs munkacsoport + Nemzeti Fejlesztési Minisztérium (NFM) által gondozott IT követelmény-rendszer integrálása, intézményi üzemeltetési-szabályozási konzekvenciák meghatározása................................................................................................................................. 162 8.5.1 Előzmények, összefoglaló......................................................................................................... 162 8.5.2 Az egészségügyi információs rendszerkövetelmények anyag megfelelése a kormányzati infokommunikációs konszolidációs intézkedési tervben leírtakhoz.......................................................... 163 8.5.3 Informatikai szabályozás és informatikai szervezete – kormányzat / egészségügy .................. 167 8.5.4 Konklúzió ................................................................................................................................. 170

9

A dokumentum szerzői ................................................................................................... 171


iii

Bevezető

BEVEZETŐ 1 Előszó A 21. század első évtizedében jelentős erőfeszítések történtek 1 az egészségügyi ágazatban működő információs rendszerek közötti interoperabilitás felépítésére. Az informatikai rendszerek integrálhatóságát ma is annak érdekében kell megtenni, hogy egyrészt az informatikai megoldások valóban segítsék a felhasználóikat a társadalmat érő egészséggel kapcsolatos hatások (betegellátás, megelőzés, rehabilitáció, népegészségügy, stb.) kezelésében, másrészt az egészségügyet szervező, döntési helyzetbe kerülő szereplők – legyenek azok állami, vagy szakmai szervezetek – valós információkat kaphassanak a működő egészségügyről, jó döntések meghozatalához. A jelen dokumentum a fenti igény kielégítését kívánja támogatni, azok számára készült, akik az egészségügyi informatika működtetésében, fejlesztésében dolgoznak, hogy tevékenységük eredményeképpen ki tudjon alakulni az a szakmailag és módszertanilag korszerű ismeretekre alapozott, transzparens informatikai üzemeltetési és fejlesztési szolgáltatási tér, amely mind az ellátó intézmények, mind az ágazatirányító intézmények részéről minősíthető, és egyre inkább homogenizált, magas szolgáltatási szinteken szolgálja az ágazat informatikai működtetését.

Általános feladat meghatározás Az ágazati informatikáért felelős kormányzati szerv – az ESKI (2011. május 1-től GYEMSZI) – azt a feladatot kapta, hogy dolgozzon ki egy feltételrendszert (stratégiai fejlesztési projekt tartalmak, azokat működtető intézmény és folyamat rendszer, ágazati informatikai koordináció) – amely elősegíti egymással együttműködő ágazati informatikai folyamatok és rendszerek kialakulását, ezáltal az ágazatban keletkező információkat elérhetővé teszi mindazok számára, akik munkájához azok szükségesek. A tervek között egy fontos tématerület a folyamatban lévő és jövőbeli információs beruházások és fejlesztések olyan mederbe terelése, hogy módszertanilag a legkorszerűbb követelmények által ezek kivitelezése és fenntartása ellenőrizhetővé és minősíthetővé váljék. Fontos az uniós források összehangolt felhasználása, és az egyes egyedi beruházások olyan szemléletű tervezése, hogy az őt körülvevő rendszerekkel együttműködők legyenek, készüljenek fel a később bevezetésre kerülő más megoldások hatásainak kezelésére. Fontos 1

Az első az 1997 – 2000 között lezajlott világbanki Kórházvezetést Támogató Információs rendszerfejlesztési (KTI) projekt volt, amely a szakellátásban (főleg a kórházi fekvőbeteg ellátásban) volt hivatva integrált HIS rendszereket fejleszteni, ezáltal letisztítani a hektikusnak mondható, uralkodó informatikai piacot, másrészt a kórházakat csoportokba szervezve kialakítani olyan együttműködéseket, amelyek a szabványosság és interoperabilitás szabályrendszerével kívánta a színvonalat emelni, a hazai kórházakat a projektszerűen végiggondolt fejlesztési folyamatra rávezetni. A KTI 24 kórházra korlátozódott, mivel az 1998‐ban történt kormányváltás a világbanki kölcsönt – amely 1992‐ben köttetett – drágának ítélte, és a projektet az első fázisa után leállította, bár készen állt a második – követő – fázis, amely a kórházak döntő többségére kiterjesztette volna a projekt eredményeit. A piac viszont az első fázis hatására letisztult, a jelenleg működő 4‐5 meghatározó jelentőségű informatikai fejlesztő a KTI program hatására lett piacvezető. A második a HEFOP (Humán Erőforrás Fejlesztési Operatív Program) 4.4 intézkedése volt az első Nemzeti Fejlesztési Terv keretében a hátrányos helyzetű 3 régió interoperábilis egészségügyi intézményközi rendszerének kialakítására. Tekintettel arra, hogy a KTI tervezői indították útjára a HEFOP 4.4‐et, sok kitűzött cél a világbanki fiaskó pótlását, illetve újragondolását valósította volna meg. Jelentős hangsúlyt kapott VOLNA az intézmények közötti információcsere, az interoperabilitás olyan – akkor már máshol megjelenő – szolgáltatásokkal kiegészítve, mint az e‐Recept, e‐Konzílium, stb. Az intézkedés végrehajtásakor az egészségügyi kormányzat viszont nagyobb teret hagyott az intézményen belüli fejlesztéseknek (érthető okokból), amely eredményeképpen csak egy korlátozott funkcionalitású, és a bekapcsolt intézményeket mélyen megosztó intézményközi rendszer alakulhatott ki, amely a szabványosítás területén sem ért el áttörést, az egészségbiztosítás, az alapellátási rendszerek kívül maradtak a projekt terjedelmén.


1

Bevezető

továbbá a fejlesztési projekteket végrehajtó informatikai szállítók, valamint a velük üzleti kapcsolatban álló egészségügyi intézmények IT szervezetei számára olyan szakmaimódszertani ismereteket koncentráltan összegyűjteni, ezekre az ismeretekre követelményeket megfogalmazni, amelyeket egy egészségügyi intézmény önmaga értelemszerűen nem tudna kellő koherenciával összeállítani. A jelenleg működő információs rendszerek sem maradhatnak ki a fenti megfontolások szerinti vizsgálatból, hiszen a folyamatos fejlesztések közepette azok tovább kell, hogy működjenek. Szükséges tehát egy általánosan (de egészségügyi ágazat-specifikusan) megfogalmazott feltételrendszer kidolgozása mellett olyan értékelési rendszer megalkotása is, amely a feltételek teljesülését vizsgálja a működő rendszerek esetén. Nem feledkezhet el az egészségügyi informatikáért felelős szerv arról sem, hogy foglalkozzon az egészségügyi intézmények – a projektek kedvezményezettjei – fejlesztésben betöltött szerepének meghatározásával, azzal a szervezeti követelményrendszerrel, amely biztosítja a fejlesztési projektek zökkenőmentes és hatékony levezetésének lehetőségét az egyes intézményeken belül.

A jelen dokumentum célja A GYEMSZI a fenti célokat egy ajánlásrendszerrel is segíteni kívánja. A feladat meghatározásában lényeges szempont volt a közérthetőség, a száraz, tudományoskodó megfogalmazások kerülése, valamint a kidolgozandó informatikai feltételrendszer és a rendszerminősítési kritériumok praktikus, gyakorlati alkalmazhatósága. Ugyanakkor le kell szögezni, hogy a megfogalmazás egyedisége ellenére a hazai és nemzetközi informatikai sztenderdek, módszertanok és ajánlások az anyag összeállításánál figyelembe lettek véve (ITIL, uniós- és általános pályázati követelmények, szabványok, közismert projektvezetési módszertani alapok - PRINCE2, PMI stb.). Tehát összefoglalva a jelen dokumentum céljai: 9 Ajánlás, illetve követelményrendszer gyűjteményt közzétenni az egészségügyben megvalósuló informatikai üzemeltetési feladatok, valamint végrehajtandó informatikai fejlesztések (uniós forrásból támogatott központi projektek, intézményi pályázatok) színvonalas megvalósítása és a későbbiekben együttműködni képes megoldások létrehozása érdekében; 9 Alapkövetelményt adni egy jövőbeli minőség-hitelesítési folyamatnak, amely a követelmények alapján áll, és azok szerint kerül végrehajtásra. 9 A Semmelweis tervben megfogalmazott cél, hogy a jelen követelményrendszer alapján az ágazati informatika bekerüljön az akkreditálandó területek közé, az alábbiakra való közvetlen hatással: o Az ágazati adat-áramlás és intézményközi interoperabilitás o Üzemeltetési sztenderdek, szolgáltatási színvonal és szintek egységesedése, a színvonal emelkedése o Az ágazat stratégiai fejlesztési projektjeivel való összhang biztosítása informatikai képességek szintjén o Ágazati szereplők (intézmények, kórházak, stb.) közpénzzel támogatott informatikai fejlesztéseinek kötelező tartalmi elemei o Ágazati szoftver / informatikai rendszer akkreditáció bírálati szempontjai o Informatikai beruházások költségeinek jelentős csökkentése o Az ágazaton belüli és kívüli informatikai szállítóktól való függőség csökkentése


2

Bevezető

Az egészségügyi kormányzat határozott szándéka – a Semmelweis terv megalkotását tekintve mintaként – az ajánlásgyűjtemény folyamatos gondozása.

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


3

Felhasználói rendszerek

2 Szószedet adatcsoport: olyan, összetartozó adatsorok, melyek valamely adatkezelési okból logikai egységek képeznek (pl. egy beteg laboratóriumi leletsorozata). adatszerkezet (adatstruktúra): az adatszerkezetek adatcsoportok osztályai, definiált belső és külső kapcsolatokkal. aktív fekvőbeteg szakellátás finanszírozása: DRG-alapú, homogén betegségcsoportokba (HBCS) való besorolásra támaszkodó esetátalány finanszírozás. architektúra: egy rendszer alapvető szerkezeti felépítése, amely a komponenseiben, ezek egymáshoz ill. a környezethez való kapcsolódásaiban, valamint azon elvekben fejeződik ki, amelyek a rendszer tervezését, működését és továbbfejlesztését meghatározzák. beszállító: az a cég vagy szervezet, amely az információs fejlesztések kapcsán az egészségügyi intézmények számára javakat szállít, megoldást fejleszt és szolgáltatást nyújt, valamint rendelkezik ezen tevékenységek végzéséhez szükséges ismeretekkel és képességekkel. egészségügyi adat: a betegről, a beteg állapotáról és az ellátó intézmény működéséről szóló elemi ismeret. eredménytermék: a minősítő eljárás által célba vett eredmények (a minősítés eredménye) összefoglaló dokumentuma(i) fejlesztés: az informatikai erőforrások megteremtésére, bővítésére, korszerűsítésére vonatkozó folyamat (projekt) akár belső (saját), akár külső (EU-s, Norvég-Alap, stb.) vagy vegyes (külső és belső) finanszírozású HIS (Healthcare Information System) : Egészségügyi információs rendszer intézmény: az egészségügyi ágazatban finanszírozással kapcsolatban álló szervezet.

a

betegellátással,

népegészségüggyel

és

minősítés alanya: az információs rendszer, az informatikai fejlesztési projekt valamint az információs beszállító, vagy ilyet üzemeltető egészségügyi költségvetési intézmény szervezete, amely vonatkozásában a követelményeknek való megfelelés vizsgálata folyik. minősítő eljárás: a követelményeknek való megfelelés vizsgálatának összefoglaló megjelölése informatikai megoldásszállító: Olyan cég, vagy konzorcium, amely egy szerződéses partnerként képes a fejlesztés minden aspektusát maga megvalósítani illetve megvalósíttatni, beleértve a szükséges hardver, szoftver elemeket, a szükséges oktatást, képzést, implementációt, adaptációt valamint kellő színvonalú üzemeltetést és rendszertámogatást. 9 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. 9 A kiírásban megfogalmazott célok megvalósulásáért kellő jogi és szakmai garanciát tud vállalni. 9 Az elvárásoknak megfelelő szoftvereket tudja biztosítani. 9 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.


4


9 Folyamatosan biztosítani tudja (a megvalósítási és a támogatási szakaszban is) az elvárásoknak megfelelő hardver eszközök beszerzéséhez, telepítéséhez, paraméterezéséhez, javításához, működtetéséhez szükséges szakértelmet és szakembergárdát vagy bizonyítottan szerződéses jogviszonyt létesít ezen funkciók ellátására a projekt megvalósítás és üzemeltetés teljes szakaszára. 9 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,

kimeneti pont: a minősítő eljárás eredménytermékének előállítási pontja, általában az eljárás vége kritikus hiba: kritikus hibának kell tekinteni minden olyan rendellenességet, amelynek fellépése miatt a rendszer illetve a szolgáltatási folyamat megsérti a rendelkezésre állásra és a válaszidőre előírt követelményeket. minősítő szerv: a minősítési eljárás viszonylatában nevesített, abban résztvevő, ellenőrző vagy irányító hatáskörű (informatikai) szervezet SLA: az angol Service Level Agreement kifejezés rövidítése, ami magyarul szolgáltatási szint megállapodást jelent. SNMP: Simple Network Management Protocol SOA (Service Oriented Architecture): magyar terminológiával Szolgáltatás Alapú Architektúra. Software as a Service (SaaS): Alkalmazás (szoftver) biztosítása a felhasználóknak szolgáltatásként. A szolgáltatás menedzselt informatikai alkalmazás biztosítását jelenti, így az alkalmazás napi működtetését, üzemeltetését, felügyeletét a szolgáltató végzi, ezért szerződéses felelősséget vállal; az alkalmazás szerver oldali infrastruktúrája, az alkalmazás licenszek a szolgáltató eszközei közt vannak nyilvántartva; a szolgáltató a szolgáltatást írásban foglalt szolgáltatási szerződésen keresztül biztosítja az igénybevevő számára. szemantikus interoperabilitás (semantic interoperability): az adatok olyan megosztásának képessége heterogén rendszerekkel, ami érthetővé teszi azokat formálisan definiált domén koncepciók szintjén. vékony kliens: olyan a felhasználói munkaállomásokon alkalmazott technológia melynek következtében a felhasználó rendelkezésére álló eszközön (állapot mentes célhardver) alkalmazás nem fut. Ez az eszköz kizárólag az input output forgalom biztosítására szolgál. A célhardver helyett gyári vékonykliens emulációt biztosító (deszktop virtualizáció) megoldás is ennek tekinthető (pl. Citrix).


5


KÖVETELMÉNYEK ÉS MINŐSÍTÉS 3 Központi kormányzati egészségügyi informatikai fejlesztések, a rendszerkövetelmények anyag illeszkedése 3.1 Ágazati központi e-Egészségügyi kulcsprojektek Az anyag elkészítésének fő célja, hogy megfelelő szakmai támaszt, hátteret és közvetlenül átültethető követelményrendszert nyújtson az ágazatban a jövőbeni kormányzatilag elindítandó központi informatikai projektekhez és az intézmények infokommunikációs fejlesztéseihez, amelyek az egészségügy általános hazai megújítását célzó Semmelweis Terv 2 és a kormányzat infokommunikációs stratégiai programjának, a Digitális Megújulás Cselekvési Terv 3nek is fontos részét képezik. A Nemzeti Egészségügyi Informatikai Rendszer (e-Health) megvalósítását célzó, annak érdekében kidolgozott koncepció fejlesztéspolitikai intézkedései, vagyis a Társadalmi Infrastruktúra Operatív Program (TIOP), Társadalmi Megújulás Operatív Program (TÁMOP) és Elektronikus Közigazgatás Operatív Program (EKOP) 2011-2013-as konstrukciók megvalósítását (azokat nem konkrétan nevesítetten) a Semmelweis Terv 1208/2011. kormányhatározat 13. pontja irányozza elő. Az egészségügyi ágazati informatikai koncepció, az azokban megvalósítani tervezett intézkedések, fejlesztések alapvető céljai a következők: •

Az állam fokozott szerepvállalása az ellátásszervezésében és kapacitás-tervezésében.

•

Transzparens ágazati működés és elszámolás kialakítása.

•

Integrált támogató rendszerek megalkotása a funkcionális területi integráció, a progresszív ellátásszervezés és az intézményközi együttműködés lehetővé tételére.

•

Szükséglet alapú kapacitástervezést szolgáló informatikai megoldások.

A központi kormányzati fogalomrendszer:

egészségügyi

informatikai

projektek

kapcsán

használt

- Központi projektek: A Semmelweis Terv szakmai tartalmának megvalósítását támogató informatikai stratégiai központi fejlesztési projektportfólió (TIOP-TÁMOP-EKOP projektek) - Egységes elvek, követelmények és protokollok alapján működő integrált, egyes kiemelt funkciókat központilag biztosító egészségügyi ágazati informatikai rendszer (e-Health rendszer): a központi projektek keretében induló fejlesztések eredményeként létrejövő rendszer, melynek két pillére: A. Központi komponensek •

TÁMOP 6.2.1 Humánerőforrás (HR) monitoring rendszer

•

TÁMOP 6.2.3 Országos alkalmazásfejlesztés

egészségmonitorozási

és

kapacitástérkép

adatbázis-

és

2

Semmelweis Terv http://www.kormany.hu/hu/nemzeti‐eroforras‐miniszterium/egeszsegugyert‐felelos‐ allamtitkarsag/hirek/kormanyhatarozat‐az‐egeszsegugyi‐struktura‐atalakitasrol 3 Digitális Megújulás Cselekvési Terv http://www.kormany.hu/hu/nemzeti‐fejlesztesi‐miniszterium/infokommunikacioert‐ felelos‐allamtitkarsag/hirek/digitalis‐megujulas‐a‐magyar‐kreativitas‐kiteljesiteseert


6


•

TIOP 2.3.2 Nemzeti Egészségügyi Informatikai (e-Health) Rendszer - Elektronikus közhiteles nyilvántartások és ágazati portál fejlesztése

•

TIOP 2.3.1 Nemzeti Egészségügyi Informatikai (e-Health) Rendszer: központi informatikai rendszerek fejlesztése az intézményen belüli betegazonosítási rendszerek fejlesztésének biztosításához és az intézményen belüli betegazonosítási rendszerek fejlesztése

•

EKOP 2.3. Egészségbiztosítási ügyfélkapcsolatok fejlesztése, egészségügyi rendszerekbe integrált adatkezelés és azonosítás megvalósítása

•

TIOP 2.3.3 Nemzeti Egészségügyi Informatikai (e-Health) Rendszer - Térségi, funkcionálisan integrált intézményközi információs rendszerek kiépítése

•

TÁMOP 6.2.7 Nemzeti Egészségügyi Informatikai (e-Health) Rendszer bevezetésének támogatása – módszertan - és képzésfejlesztés

B. Központilag szabályozott egységes elvárások alapján folyamatosan fejlesztett lokális rendszerek A projektek / rendszerek egymáshoz kapcsolódását az alábbi ábra szemlélteti:

Az e-Health rendszer összefoglaló ábrája


7


Az intézményi nézet a következő:

Az e-Health rendszer intézményi koncepciója A GYEMSZI jövőképe szerint az e-Health rendszer az egyes kiemelt fejlesztési projektek eredményeként úgy alakul ki és működik, hogy: •

minden egészségügyi intézmény, ideértve a járó- és fekvőbeteg ellátási egységeket megmarad önálló entitásnak, saját hálózaton, saját rendszerekkel, saját eszközökkel, de úgy, hogy lesznek olyan alkalmazások, amelyeket egy központi SaaS rendszer biztosít.

•

minden egység elektronikusan kapcsolódik egymáshoz, ezáltal minden egység számára biztosított az integrált működés lehetősége (kétirányú adatkommunikáció közvetlenül vagy egy központon keresztül). Megépül egy új egészségügyi informatikai szolgáltató központ, amely integrációs és intézményközi adatkommunikációt biztosító központi funkciót egyaránt betölt.

Ez jelent: •

irányítást, mely a GYEMSZI hatáskörébe utalt feladat (SaaS rendszer működtetése, szerverpark üzemeltetés, központi szolgáltatások tervezése és folyamatos továbbfejlesztése, licencek biztosítása, help-desk fenntartása, adatvédelmi, adatbiztonsági, kommunikációs követelmények érvényesítése, lokális IT rendszerek fejlesztésével és üzemeltetésével kapcsolatos specifikációk karbantartása, oktatás). Az irányítás részeként a GYEMSZI hatáskörébe tartozik az egészségügyi informatikai ágazati stratégia elkészítése és karbantartása. A GYEMSZI az érvényes informatikai stratégiának alárendelten a központi komponensek eredményeként


8


o professzionális szakmai mátrix irányítási rendszert épít ki az egészségügy valamennyi lokális informatikai szervezettel rendelkező entitása esetében o professzionálisan szolgálja ki a területi ellátásszervezőket és működteti az ágazatirányításhoz szükséges valamennyi magas szintű, összegzett információs és elemzési bázisokat o professzionális oktatási rendszert épít ki és működtet (oktatás, oktató képzés, oktatási segédletfejlesztés /szoftver stb.) o virtuális és valós fejlesztési pilot- és teszt környezeteket épít ki és működtet. •

infrastruktúrát, amely professzionális, adat/biztonságtechnikailag legmagasabb szintű szerverközpontot/szolgáltatóközpontot jelent, ahol indextárolás és adattárolás folyik;

•

alkalmazásokat, szoftver szolgáltatásokat (pl. bérszámfejtési modult, portált), amelyeket a fenntartó biztosít az entitásoknak, díjmentesen);

•

az intézmények szabályozott hozzáféréssel rendelkező munkatársai részére adathozzáférési jogosultságot és lehetőséget, amikor konkrét esetekben konkrét páciensek esetében, teljes esettörténet és leletek állhatnak rendelkezésre. A központi rendszerben ugyanazok az adatok vannak nyilvántartva, mint az egyedi entitásoknál, de minőségileg másként, esettörténetbe rendezve, minden elemei adattal egyetemben (leletek). Az egyes entitásoknál az egészségügyi ellátások során képződött egészségügyi dokumentációk/adatok automatikusan kerülnek be az adatközpontba. A jövőben cél az, hogy az egészségügyi szakmai testületek által definiált szabványos egészségügyi dokumentumok (ide értve a gyógyszerterápiás, a környezetre veszélyt hordozó jellemzőinek stb. adatait) egységes adatszerkezetben központilag tárolódjanak. A központilag tárolt adatok erős autentikáció és a páciens nyilatkozata függvényében a gyógyítás érdekében elérhetők az arra jogosult entitások számára.

Extra hozadék, hogy működő módon definiálódnak azon szabványos egészségügyi dokumentumok melyek jelenleg intézet- és szakmaspecifikus módon vannak jelent a rendszerben, ráadásul EU és nemzetközi projektekhez kapcsolva megnyílik az út a konkrét nemzetközi interoperabilitás irányába. A konstrukciókhoz, fejlesztésekhez a következőképpen kapcsolódik és illeszkedik a rendszerkövetelmények és audit anyag.

3.1.1 TÁMOP 6.2.1 Humánerőforrás (HR) monitoring rendszer Konstrukció forráskerete: 500 millió Ft Eljárásrend: kiemelt projekt Kedvezményezett: GYEMSZI és EEKH konzorciuma A projekt célja olyan egységes ágazati HR monitoring rendszer és adattárház kiépítése , amely jól szolgálja a kormányzati és/vagy ágazati, intézményi, képzőhelyi szintű döntés-


9


előkészítését és döntéstámogatását, illetve támogatja az ágazati HR-stratégia kialakítását, továbbá lehetővé teszi az ágazati humánerőforrás jellemzők, trendek nyomon követését. A rendszerkövetelmények és audit anyag kapcsolódása a konstrukcióhoz: A projektből származtatott követelmények: Központi projekt felé szabott követelmény: Interface kialakításának szükségessége, mely lehetővé fogja tenni, hogy az egyes intézményeknél működő HR rendszerek automatikusan csatlakozhassanak a HR monitoring adatbázishoz. Lokális rendszerek felé szabott követelmény: Az anyag intézményi működést támogató rendszerek fejezetében (4.3) az alap, járó- és fekvőbeteg ellátó intézményeknél az ott működő (vagy bevezetésre kerülő) HR, bérszámfejtési moduloknál (4.3.2.1) követelményként javasoljuk feltüntetni a létrejövő központi HR monitoring rendszer felé (amikor az is rendelkezni fog ilyen kapcsolódási képességgel, vagyis nyitott lesz a közvetlen adatkommunikációra) interface kialakítását.

3.1.2 TÁMOP 6.2.3 Országos egészségmonitorozási és kapacitástérkép adatbázis- és alkalmazásfejlesztés Konstrukció forráskerete: 1 milliárd Ft Eljárásrend: kiemelt projekt Kedvezményezett: GYEMSZI, ÁNTSZ és OEP konzorciuma A projekt célja, hogy létrejöjjön egy, a magyar lakosság egészségi állapotát, és az egészségügyi rendszer leíró jellemzőit monitorozó rendszer, amely támogatja az egészségorientált kormányzati és egészségpolitikai döntéshozatal kialakítását. A projekt keretében kialakításra kerül a lakosság egészségi állapotát, az egészségügyi ágazat kapacitásait és valós felhasználásait jellemző módszertan, szabályozásra kerülnek az egészségügyi ágazat országos és helyi intézményeivel való szakmai együttműködések, információ szolgáltatási tartalmak, valamint létrejönnek azon csatornák, melyeken keresztül a monitorozó szervezet eredmény termékei visszacsatolásra kerülnek. A rendszerkövetelmények és audit anyag kapcsolódása a konstrukcióhoz: A projektből származtatott követelmények: Központi projekt felé szabott követelmény: Interface kialakításának szükségessége, mely lehetővé fogja tenni, hogy az egyes intézményeknél működő vezetői információs és döntéstámogató rendszerek automatikusan csatlakozhassanak a kapacitástérkép adatbázishoz Lokális rendszerek felé szabott követelmény: Javasoljuk, hogy az alap, járó- és fekvőbeteg ellátó intézményeknél az ott működő (vagy bevezetésre kerülő), az anyag 4.3.2 részében található specifikációkkal rendelkező Döntéstámogató (vezetői információs) rendszereknél legyen meg az a


10


képesség, mely lehetővé teszi (amennyiben az létre fog jönni) az Országos egészségmonitorozási és kapacitástérkép adatbázis közvetlen lekérdezését.

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


11


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


12


Szintén szükségesnek tartjuk a központ megvalósíthatósági tanulmányának működtetéssel kapcsolatos részeiben az 4.5. Üzemeltetési követelmények maximálisan érvényesüljenek. A rendszerkövetelmények és audit anyag 4.2.1 Az alapellátás specifikumai és a 4.2.2 A szakellátás specifikumai részekben javasolt kitérni az intézményen belüli betegazonosítással kapcsolatos informatikai (hardver, szoftver) követelményekre, úgy, hogy azok felhasználásra tudjanak kerülni a TIOP 2.3.1 projekt megvalósíthatósági tanulmányának vonatkozó részeiben, illetve később a projekt közbeszerzési dokumentációjának műszaki mellékletében. Célszerűnek tartanánk, hogy a megvalósuló projekt szakmai monitoringja (pl. helyszíni ellenőrzése) során az azt végző TÁMOP-TIOP Közreműködő szervezet (KSZ), vagyis az ESZA Nonprofit Kft. munkatársai részéről számon legyenek kérve a projektgazdától a fenti részekben leírt követelmények. Lokális rendszerek felé szabott követelmény: Valamennyi releváns egészségügyi intézményi informatikai rendszernél számon kérni javasoljuk (amennyiben majd az létrejön és működik) a TIOP 2.3.1 központhoz, az azok által szolgáltatásokhoz, komponensekhez való csatlakozás képességét. Tekintettel arra, hogy a TIOP 2.3.1 projektben fog létrejönni a funkcionális integrációkat kiszolgáló egységes és központi kapcsoló-adatbázis („integrációs motor”) a 4.4 Intézményközi rendszerszolgáltatások általános és specifikus követelményei részben fel kell tüntetni a megfelelő interfész kialakításának képességét az Országos Egészségügyi Core-SaaS központ, és azok szolgáltatott megoldásai (különösen a háziorvosi és e-recept rendszer) felé (amikor az létrejön és működik). Amennyiben lesz TIOP 2.3.1-nek közép magyarországi régiós (KMR) tükörkonstrukciója annál is értelemszerűen ugyanúgy javasoljuk az anyag illesztését. A TIOP 2.3.1 KMR-es tükörprojekt indítása, finanszírozásának előteremtése az EU-s források felhasználásának szabályai, a szükséges arányosítás miatt gyakorlatilag elkerülhetetlen, bár egyelőre a Közép Magyarországi Operatív Program (KMOP) 2011-2013-as Akciótervében nincs ilyen intézkedés.

3.1.5 EKOP 2.3. Egészségbiztosítási ügyfélkapcsolatok fejlesztése, egészségügyi rendszerekbe integrált adatkezelés és azonosítás megvalósítása Konstrukció forráskerete: 2 800 millió Ft Eljárásrend: kiemelt projekt Kedvezményezett: KIFÜ/ OEP A projektben valós ügyfélkapcsolati rendszer (CRM) kialakítása történik meg, elsősorban a szolgáltatók, mint ügyfelek felé biztosítva a hatékony kapcsolattartást, ügyintézést, az alapvető nyilvántartások szolgáltató képes alapnyilvántartássá szervezését. A projekt lehetővé teszi az ellátások finanszírozásának jobb megalapozását, pontosabb követését. Ennek része a még mindig létező floppys adatszolgáltatások helyett valódi monitoringot lehetővé tevő rendszer kialakítása, támaszkodva az e-kézbesítési szolgáltatására, felhasználva a (részben megújuló) űrlapos jelentési megoldásokat, de lehetővé téve a gépi adatszolgáltatást az auditált egészségügyi rendszerek számára.


13


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


14


Főbb elemek: 9 Regionálisan integrált intézményközi kórházi információs rendszerek lokális hardver és szoftver fejlesztése 9 Az integrálandó tartalmak és technológiai protokollok meghatározása, kifejlesztése 9 Interfészek és üzenettípusok fejlesztése vonatkozó sztenderdek alapján 9 Regionális telemedicina szolgáltatások infrastruktúrájának kiépítése a funkcionálisan integrált intézményi rendszerekhez kapcsolódóan 9 A betegek önrendelkezési jogait támogató informatikai megoldások fejlesztése A rendszerkövetelmények és audit anyag kapcsolódása a konstrukcióhoz: A projektből származtatott követelmények: Központi projekt felé szabott követelmények: Javasoljuk, hogy a projekt megvalósíthatósági tanulmányában, illetve később a projekt közbeszerzési dokumentációjának műszaki mellékletében felhasználásra vagy közvetlen beillesztésre kerüljenek az anyag 4.1 Az informatikai infrastruktúra architekturális követelmények, a 4.4 Intézményközi rendszerszolgáltatások általános és specifikus követelményei, az 4.5 Üzemeltetési követelmények – szolgáltatásmenedzsment kérdések és a mellékletben szereplő 8.4 Telemedicina alkalmazásának helyzete Magyarországon, a telemedicina rendszerkövetelményei – fejezetek részeinek releváns elemei. Célszerűnek tartanánk, hogy a megvalósuló projekt szakmai monitoringja (pl. helyszíni ellenőrzése) során az azt végző TÁMOP-TIOP Közreműködő szervezet (KSZ), vagyis az ESZA Nonprofit Kft. munkatársai részéről számon legyenek kérve a projektgazdától, illetve a fejlesztési támogatásban részesülő intézményeknél mind a négy részben leírt követelmények. Amennyiben lesz TIOP 2.3.3-nek közép magyarországi régiós (KMR) tükörkonstrukciója annál is értelemszerűen ugyanúgy javasoljuk az anyag illesztését. A TIOP 2.3.3 KMR-es tükörprojekt indítása, finanszírozásának előteremtése az EU-s források felhasználásának szabályai, a szükséges arányosítás miatt gyakorlatilag elkerülhetetlen, bár egyelőre a Közép Magyarországi Operatív Program (KMOP) 2011-2013-as Akciótervében nincs ilyen intézkedés.

3.1.7 TÁMOP 6.2.7 Nemzeti Egészségügyi Informatikai (eHealth) bevezetésének támogatása – módszertan - és képzésfejlesztés

Rendszer

Konstrukció forráskerete: 1 milliárd Ft Eljárásrend: kiemelt projekt Kedvezményezett: GYEMSZI A projekt célja az egyedileg azonosított betegadatok ágazati feldolgozási folyamatainak (beleértve az egyedi ellátási eseteket leíró kódolási folyamatokat, az elszámolási rendszereket és technikákat) korszerűsítése, az emberi erőforrás fejlesztése. A projekt főbb elemei: módszertani koherencia biztosítása, a szükséges (tovább-) képzések (egészségügyi dolgozók képességfejlesztése) lebonyolítása az egyetemek közreműködésével, az intézményeknél újonnan bevezetett infokommunikációs rendszerek használatának betanítása. Összeállította a GYEMSZI szakértői munkacsoportja

15


A rendszerkövetelmények és audit anyag kapcsolódása a konstrukcióhoz: A projektből származtatott követelmények: Központi projekt felé szabott követelmények: Javasoljuk, hogy a TÁMOP 6.2.7 projekt scope-ja terjedjen ki valamennyi rendszerkövetelmények és audit anyag 4.2.1 Az alapellátás specifikumai, 4.2.2 A szakellátás specifikumai és 4.3 Intézményi működéstámogató rendszerek fejezeteiben feltüntetett megoldásokkal kapcsolatos felhasználói képzésre, betanításra. A projekt megvalósíthatósági tanulmányának kidolgozásában célszerűnek tartanánk felhasználni az 5.1 Az intézmény felkészültségének követelményei részben leírtakat. Ezenkívül a kormányzati infokommunikációs konszolidációs intézkedési terv „közigazgatási humánerőforrás fejlesztése” intézkedésében (lásd 8.7.2 fejezet) leírtakkal való összhang megteremtése érdekében javasoljuk, hogy a projekt térjen ki a módszertan és tananyagfejlesztéseken és az ellátórendszeri felhasználók informatikai jellegű képzésén túl az egészségügyi informatikai szakemberállomány fejlesztésére, képzésére, életpálya modelljük kidolgozására is (akár az előirányzott 1 milliárd Ft forrás nagyságának újragondolásával).

3.2 A Semmelweis-Terv egyéb fejlesztéspolitikai konstrukcióihoz (pályázataihoz) való viszony Az előző részben felsorolt központi projektekhez való illesztésen túl javasoljuk, hogy az elkészülő anyagot használják fel a TIOP és Regionális Operatív Programok (ROP-ok) 20112013-as olyan egészségügyi konstrukcióihoz is a kiírások mellékleteként, illetve a közbeszerzések műszaki dokumentációjánál, ahol az intézmények számára támogathatók infokommunikációs fejlesztések a projektekben. Kívánatosnak tartanánk, hogy a rendszerkövetelmények és audit anyag releváns részeit az egyes infokommunikációs fejlesztéseket is támogató pályázatok, azok közbeszerzési dokumentációinak mellékleteként a Nemzeti Fejlesztési Ügynökség deklarálja, valamint a TÁMOP-TIOP Közreműködő szervezet (KSZ), vagyis az ESZA Nonprofit Kft., illetve a ROP KSZ VÁTI Nonprofit Kft. munkatársai vegyék figyelembe és kérjék számon mind az intézményi projektek értékelésekor, mind azok (helyszíni) szakmai monitoringja során. Az egyes konstrukciók és az anyag javasolt kapcsolódását (illesztését, felhasználását) a következő táblázatban mutatjuk be:

Rendszerkövetelmények anyag releváns részei az uniós forrás felhasználás különböző szakaszaiban Vonatkozó TIOP- ROP 2011-2013 konstrukciók Pályázati Közbeszerzési Monitoring melléklet, melléklet Értékelés TIOP

2.1.1

Regionális

járóbeteg 4.1;


4.2.2; 4.1; 4.2.2; 4.2.4; 4.1;

4.2.2; 16


Rendszerkövetelmények anyag releváns részei az uniós forrás felhasználás különböző szakaszaiban Vonatkozó TIOP- ROP 2011-2013 konstrukciók Pályázati Közbeszerzési Monitoring melléklet, melléklet Értékelés szakellátó intézmények fejlesztése

4.2.4; 4.2.5

4.2.5; 4.5

4.2.4; 4.5

4.2.5;

TIOP 2.1.3 Aktív kórházi ellátásokat 4.1; 4.2.2; 4.1; 4.2.2; 4.2.4; 4.1; kiváltó járóbeteg szolgáltatások 4.2.4; 4.2.5 4.2.5; 4.5 4.2.4; fejlesztése 4.5

4.2.2; 4.2.5;

TIOP 2.2.2 Sürgősségi fejlesztése (SO1 és SO2)

ellátás 4.1; 4.2.2; 4.1; 4.2.2; 4.2.4; 4.1; 4.2.4; 4.2.5 4.2.5; 4.5 4.2.4; 4.5

4.2.2; 4.2.5;

TIOP 2.2.4 Struktúraváltoztatást 4.1; 4.2.2; 4.1; 4.2.2; 4.2.4; 4.1; támogató infrastruktúra-fejlesztés a 4.2.4; 4.2.5 4.2.5; 4.5 4.2.4; fekvőbeteg-szakellátásban 4.5

4.2.2; 4.2.5;

TIOP 2.2.5 Korszerű regionális 4.1; 4.2.2; 4.1; 4.2.2; 4.2.4; 4.1; onkológiai hálózat kialakítása és 4.2.4; 4.2.5 4.2.5; 4.5 4.2.4; fejlesztése 4.5

4.2.2, 4.2.5;

DAOP 4.1.1 Alap és járóbeteg ellátás 4.1;4.2.1; 4.1; 4.2.1; 4.2.2; 4.1; 4.2.1; fejlesztése 4.2.2; 4.2.4; 4.2.4; 4.2.5; 4.5 4.2.2; 4.5 4.2.5 DAOP 4.1.2 Rehabilitációs és hosszú 4.1; 4.2.2 idejű ápolási ellátás fejlesztése

4.1; 4.2.2; 4.2.4; 4.1; 4.2.5; 4.5 4.2.4; 4.5

4.2.2; 4.2.5;

DDOP 3.1.3 Egészségügyi és szociális 4.1; 4.2.2; 4.1, 4.2.2; 4.2.4; 4.1; ellátás fejlesztése 4.2.4; 4.2.5 4.2.5; 4.5 4.2.4; 4.5

4.2.2; 4.2.5;

ÉAOP 4.1.2 Egészségügyi intézmények 4.1, fejlesztése 4.2.2; 4.2.5

4.2.1; 4.1; 4.2.1, 4.2.2; 4.1; 4.2.1; 4.2.4; 4.2.4; 4.2.5; 4.5 4.2.2; 4.2.4; 4.2.5; 4.5

ÉMOP 4.1.1 Egészségügyi alapellátás 4.1; fejlesztése 4.2.2

4.2.1; 4.1; 4.2.1; 4.2.2; 4.1; 4.2.1; 4.2.4; 4.2.5; 4.5 4.2.2; 4.2.4; 4.2.5; 4.5

ÉMOP 4.1.2 Rehabilitációs és hosszú 4.1; idejű ellátás fejlesztése 4.2.2; 4.2.5

4.2.1; 4.1; 4.2.1, 4.2.2; 4.1; 4.2.1, 4.2.4; 4.2.4; 4.2.5; 4.5 4.2.2, 4.2.4; 4.2.5; 4.5


17


Rendszerkövetelmények anyag releváns részei az uniós forrás felhasználás különböző szakaszaiban Vonatkozó TIOP- ROP 2011-2013 konstrukciók Pályázati Közbeszerzési Monitoring melléklet, melléklet Értékelés KDOP 5.2.1 Az egészségügyi 4.1; ellátórendszer fejlesztése, 4.2.2; hatékonyságának növelése 4.2.5

4.2.1, 4.1; 4.2.1; 4.2.2; 4.1; 4.2.1; 4.2.4; 4.2.4; 4.2.5; 4.5 4.2.2; 4.2.4; 4.2.5; 4.5

NYDOP 5.2.1 Egészségügyi 4.1; 4.2.1; 4.1; 4.2.1; 4.2.2; 4.1; 4.2.1; szolgáltatások fejlesztése 4.2.2 ; 4.2.4; 4.2.4; 4.2.5; 4.5 4.2.2; 4.2.4; 4.2.5 4.2.5; 4.5

Megjegyezzük, hogy a táblázatban felsorolt konstrukcióknál a 2007-2010-es időszakban, illetve a jelenleg is futó pályázati kiírásoknál megtalálható (volt) Infokommunikációs minimumkövetelmények segédlet. Ezeket megvizsgálva javasolnánk azok teljes frissítését, illetve újragondolását a rendszerkövetelmények és audit anyag által leírtak alapján.


18


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


19


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


20


b) az informatikai rendszernél az adatok szintaktikai szabályainak, az adatok tárolási szerkezetének, c) az informatikai rendszer elemeinek az egészségügyi előírások által meghatározott biztonsági osztályokba sorolási rendszerének, d) az adatokhoz történő hozzáférési rend meghatározásának, e) az adatgazda és a rendszergazda kijelölését tartalmazó iratnak, f) az alkalmazott szoftver eszközök jogtisztaságát bizonyító szerződéseknek, g) az informatikai rendszert alkotó ügyviteli, eglszségügyi szoftvereszközök teljes körű és naprakész nyilvántartásának. 9. A szoftvereknek együttesen alkalmasnak kell lenni legalább: a) a működéshez szükséges és jogszabályban előírt adatok nyilvántartására, b) az egészségügyi adatok és az egészségügyi dokumentumok biztonságos nyilvántartására, c) az egészségügyi intézmény tevékenységével összefüggő informatikai rendszerekhez történő közvetlen vagy közvetett csatlakozásra, d) a tárolt adatok ellenőrzéséhez való felhasználására, e) a biztonsági kockázattal arányos logikai védelemre és a sérthetetlenség védelmére. Az egészségügyi intézménynek belső szabályzatában meg kell határoznia az egyes munkakörök betöltéséhez szükséges informatikai végzettséget és ismereteket. Általános architekturális követelmények Az informatikai rendszereknek hardver és szoftver komponensek tekintetében, valamint architekturálisan meg kell felelni a fejlesztéskor elvárható szakmai színvonalnak. Gazdaságossági és fenntarthatósági, valamint interoperabilitás szempontból elvárás a SOA 4 típusú megoldások alkalmazása. A megfelelő fejlesztési technológia kiválasztásával időtálló 5, fenntartható rendszereket A-1-001 kell fejleszteni. Robosztus architektúra: Az alkalmazások architektúráját úgy kell megtervezni és megvalósítani, hogy az képes legyen a megcélzott (ágazati vagy intézeti) számú A-1-002 felhasználó biztonságos és gyors kiszolgálására. (Az elvárt gyorsaság megítélésénél az adott funkciók specifikációjánál megadott érték az irányadó). A megfelelőséget számítással kell alátámasztani és teszteléssel ellenőrizni. Architektúra 6: a megvalósításra kerülő alkalmazás kettő (kliensszerver), vagy több A-1-003 rétegű (multi-tiered) architektúrára 7 épüljön. Méretezhetőség: Az alkalmazások architektúrájának (hardver és szoftver) biztosítania kell az intézmény vagy régióhoz tartozó teljes intézményrendszernek, mint felhasználó A-1-004 számhoz szükséges méretre való felbővítés lehetőségét. A megfelelőséget számítással kell alátámasztani. 4.1.3

4

SOA (Service Oriented Architecture), magyar terminológiával Szolgáltatás Alapú Architektúra. A SOA nyílt, szabványos komponens technológia, amelynek építőelemei a szolgáltatások. A szolgáltatások önállóan is működőképesek legyenek , platform‐ és eszközfüggetlenek (tetszőleges technológiával készülhetnek), szabványos, jól definiált interfésszel rendelkezzenek, és szabványos adatcsere‐ és kommunikációs protokollokkal legyenek érhetők el az elosztott hálózatokban. 5 Az időtállóságnál figyelembe kell venni a 1997. évi XLVII. Törvény‐ben foglalt adatmegőrzési időtartamokat. Nyilatkozat és megvalósítási leírás szükséges az időtállóság megvalósításáról. 6 Az architekturális elvárások az ajánlásgyűjtemény készítésének időszakában elvárható és ajánlott architektúrát definiálják. Terveink szerint ez és egyéb műszaki paraméterek a technológiai fejlődésnek megfelelően folyamatosan frissítésre kerülnek. 7 Pl. three‐tier architektúra ‐ kliensl, alkalmazás szerver (application server), adatbázis szerver (database server)


21


A-1-005

A-1-006 A-1-007 A-1-008

A-1-009

A-1-009-1 A-1-009-2 A-1-009-3 A-1-009-4 A-1-009-5

A-1-009-6

A-1-010 A-1-011 A-1-012 A-1-013

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

8

Pl: feladatátvételi pár topológia, forró tartalék, feladatátvételi gyűrű, stb. http://kovetelmenytar.complex.hu/ 10 Az elvárt válaszidőket alkalmazás típusonként, funkciónként egyedileg kell specifikálni. 11 Operációs rendszer és a felhasználói szoftverek számára minimálisan elvárt a 2db HDD‐ből kialakított RAID 1 (tükrözés) tömb 12 Betegadatok tárolása esetén minimálisan elvárt a minimum 4 db HDD‐ből álló RAID 5 tömb kialakítása. Javasolt a minimum 5 db HDD‐ből kialakított RAID 6 tömb kialakítása mivel így kétszeres meghajtó meghibásodás is kiküszöbölhetővé válik. 9


22


4.1.4 Infrastruktúrális követelmények A környezeti hibaforrásokat minimálisra kell csökkenteni. Az alkalmazásokat futtató A-2-001 hardver környezetet minimálisan a következő paraméterekkel rendelkező gépteremben 14 kell elhelyezni ahol biztosított: 15 o a gépek hőtermelésének megfelelő légkondicionálás; A-2-001-1 A-2-001-2

o

az eszközök illetéktelen személyek általi hozzáférése elleni védelme;

A-2-001-3

o

A-2-001-4

o

A-2-001-5

o

A-2-001-6

o

A-2-001-7

o

A-2-001-8

o

az előírásoknak megfelelő tűzvédelmi infrastruktúra; a szolgáltatást igénybe vevő, felhasználók számának, és a használt alkalmazásoknak megfelelő 16 sávszélességű hálózati 17 csatlakozás; az alkalmazások által kezelt adatok üzemszerű 18 működéséhez szükséges háttértároló eszköz és szoftver; az alkalmazások által kezelt adatok rendszeres mentéséhez szükséges mentési eszköz és mentő szoftver; az alkalmazások által kezelt adatok rendszeres archiválásához 19 szükséges eszköz, archiváló szoftver, kellő számú licence és tároló kapacitás; a gépek teljesítmény felvételének megfelelő, szünetmentes áramellátást biztosító rendszer 20; o A szerver számítógépek és a szünetmentes áramforrásoknak rendelkezniük kell távmenedzsment 21 kommunikáció funkcionalitással az szállított és megmaradó eszközpark operációs rendszer platformok mindegyikére (pl. Win, Linux,…) o A beüzemelt szerver(ekre) telepíteni kell a szünetmentes áramforráshoz szükséges kommunikációs szoftvert a szabályos leállítási és riasztási (értesítési) folyamat megvalósítása érdekében. Javasolt a szolgáltatói rendszerek hardver, szoftver, és hálózati elemeinek monitorozását és távfelügyeletét biztosítani képes felügyeleti rendszer, o melynek segítségével a vállalt szolgáltatási színvonalnak megfelelő távfelügyeleti feladatok elvégezhetősége biztosított

A-2-0018-1 A-2-0018-2 A-2-001-9 A-2-0019-1 A-2-0019-2 A-2-0019-3

o

o melynek segítségével a vállalt SLA szintek 22 folyamatosan mérhetők és dokumentálhatók o melynek segítségével lehetőség van riasztási értékek és szintek beállítására, valamint a riasztások többféle eszközön történő egyidejű elküldésére

13

A hardver eszközöket úgy kell méretezni, hogy lekérdező modult csúcsidőben történő használata ne okozzon válaszidő növekedést. 14 Mind lokális mind hosting megvalósítás esetében elvárás 15 A gépek hőtermelését a pontos hardver konfigurációt figyelembe véve számítással kell dokumentálni. 16 A sávszélesség megfelelősségét számítással kell dokumentálni. 17 Pl: internet, bérelt vonali, mobil, stb. 18 Az üzemszerű működés feltételeit írásban definiálni kell 19 Az archiváló eszköz típusát és az előírásoknak megfelelő garantált adatmegőrzési időtartamot gyártói garanciákkal kell alátámasztani. 20 A szünetmentes áramellátást minimálisan az átlagos terhelés 130%‐ra kell méretezni. A méretezés során az elvárt áthidalási időt is figyelembe kell venni a számítások során. A szünetmentes ellátás méretezését számítással kell dokumentálni. 21 pl. SNMP (Simple Network Management Protocol) 22 Az SLA az angol Service Level Agreement kifejezés rövidítése, ami magyarul szolgáltatási szint szerződést jelent. Az 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.


23


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


24


Elosztott rendszereknél az inkonzisztencia (dominó effektus) elkerülése érdekében a A-3-011 biztonsági mentéseket koordináltan kell végezni az egymással kommunikáló adatbázisok esetében. 4.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 A-4-001 biztonságos vezetéséhez meg kell valósítania a biztonsági kockázatelemzés alapján indokolt védelmi intézkedéseket és rendelkeznie kell legalább a következőkkel: o informatikai rendszerének működtetésére vonatkozó utasításokkal és A-4-001-1 előírásokkal 32, valamint a fejlesztésre vonatkozó tervekkel, o olyan rendszergazdai, felhasználói és üzemeltetői dokumentációval, amely az egészségügyi ellátási tevékenységet közvetlenül vagy közvetve támogató A-4-001-2 informatikai rendszerek folyamatos és biztonságos működését - még a szállító, illetőleg a rendszerfejlesztő tevékenységének megszűnése után is - biztosítja 33, o az egészségügyi szolgáltatások ellátásához szükséges informatikai rendszerrel, valamint a szolgáltatások folytonosságát biztosító tartalék berendezésekkel, A-4-001-3 illetve e berendezések hiányában az ezeket helyettesítő egyéb - a tevékenységek, illetve szolgáltatások folytonosságát biztosító - megoldásokkal, o olyan informatikai rendszerrel, amely lehetővé teszi az alkalmazási környezet A-4-001-4 biztonságos elkülönítését a fejlesztési és tesztelési környezettől, valamint a megfelelő változáskövetés és változáskezelés fenntartását, o az informatikai rendszer szoftver elemeiről (alkalmazások, adatok, operációs rendszer és környezetük) olyan biztonsági mentésekkel és mentési renddel A-4-001-5 (mentések típusa, módja, visszatöltési és helyreállítási tesztek, eljárási rend), amelyek az adott rendszer helyreállíthatóságát a rendszer által nyújtott szolgáltatás kritikus helyreállítási idején belül lehetővé teszik 34, o jogszabályban meghatározott nyilvántartás ismételt előhívására alkalmas adattároló rendszerrel, amely biztosítja, hogy az archivált anyagokat a A-4-001-6 jogszabályokban meghatározott ideig, bármikor visszakereshetően, helyreállíthatóan megőrizzék, o a szolgáltatásai folyamatosságát akadályozó rendkívüli események kezelésére A-4-001-7 szolgáló tervvel. A biztonsági kockázatelemzés eredményének értékelése alapján a biztonsági A-4-002 kockázattal arányos módon gondoskodni kell legalább az alábbiakról: o a rendszer legfontosabb elemeinek (eszközök, folyamatok, személyek) A-4-002-1 egyértelmű és visszakereshető azonosításáról, 30

A kumulatív mentés során mindig az utolsó teljes mentés óta megváltozott adategységek kerülnek elmentésre. A Differenciál mentés során mindig az utolsó teljes mentés (Full backup)óta megváltozott adategységek kerülnek elmentésre. 32 Adatvédelmi szabályzat, Biztonsági Politikák (felhasználói policy, rendszergazdai policy, fejlesztői policy,… ), Felhasználó Hozzáférés Management, Távoli hozzáférés szabályzata, 33 Rendszergazdai leírások, beüzemelési, beállítási, működési és üzemeltetési paraméterek, hibaelhárítási útmutatók 34 Részletesen specifikációt lást a „Mentési, archiválási, visszatöltési követelmények” 30


25


A-4-002-2 A-4-002-3

A-4-002-4 A-4-002-5 A-4-002-6 A-4-002-7 A-4-002-8 A-4-003 A-4-003-1 A-4-003-2 A-4-003-3

o az informatikai biztonsági rendszer önvédelmét, kritikus elemei védelmének zártságát és teljes körűségét biztosító ellenőrzésekről, eljárásokról, o a rendszer szabályozott, ellenőrizhető és rendszeresen ellenőrzött felhasználói adminisztrációjáról (hozzáférési szintek, egyedi jogosultságok, engedélyezésük, felelősségi körök, hozzáférés naplózás, rendkívüli események) o olyan biztonsági környezetről, amely az informatikai rendszer működése szempontjából kritikus folyamatok eseményeit naplózza és alkalmas e naplózás rendszeres (esetleg önműködő) és érdemi értékelésére, illetve lehetőséget nyújt a nem rendszeres események kezelésére, o a távadatátvitel bizalmasságáról, sértetlenségéről és hitelességéről, o az adathordozók szabályozott és biztonságos kezeléséről, o a rendszer biztonsági kockázattal arányos vírusvédelméről 35, annak rendszeres, központi frissítéséről és folyamatos menedzsmentjéről o a felhasználó munkaállomásokon használt levelező rendszer biztonsági kockázattal arányos többszintű spam és vírusvédelméről, annak rendszeres, központi frissítéséről és folyamatos menedzsmentjéről. Az egészségügyi intézménynél mindenkor rendelkezésre kell állnia: o az informatikai rendszer felépítésének és működtetésének az ellenőrzéséhez szükséges rendszerleírásoknak és modelleknek, o az informatikai rendszernél az adatok szintaktikai szabályainak, az adatok tárolási szerkezetének, o az informatikai rendszernél a tárolást adatok lekérdezési mechanizmusának,

A-4-003-5

o az informatikai rendszer elemeinek az egészségügyi meghatározott biztonsági osztályokba sorolási rendszerének, o az adatokhoz történő hozzáférési rend meghatározásának,

A-4-003-6

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

A-4-003-4

előírások

által

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), o az informatikai rendszert alkotó ügyviteli, egészségügyi szoftvereszközökön A-4-003-8 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 A-4-003-9 körű és naprakész nyilvántartásának. Központi kiszolgáló szerverpark létrehozása esetén az informatikai célrendszerek együttműködéséről és a szolgáltatásaik egységes használatát biztosító feltételekről A-4-004 gondoskodni kell. Biztosítani kell az közszolgáltatás biztonságáról szóló 223/2009. (X. 14.) Korm. rendeletben foglalt elvárások teljesülését 36 , azaz: o az informatikai célrendszer tervezésére, a célrendszer elemeinek beszerzésére, valamint a célrendszer előállítására (különösen fejlesztésére, testre szabására, A-4-004-1 paraméterezésére, telepítésére) és felülvizsgálatára kiterjedő, a rendeletben meghatározott feltételeknek megfelelő minőségirányítással kell alátámasztania A-4-003-7

35

A vírusvédelmet mind szerver mind kliens oldalon biztosítani kell. Külön figyelmet kell fordítani a vékonykliensek vírusvédelmére is. 36 A kormányrendeletben foglalt elvárások teljesítéshez nyújt segítséget és megfelelő megoldásokat a Közigazgatási Informatikai Bizottság (KIB) 25. számú ajánlása


26


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

A HIS rendszerben működő illetve azzal online vagy offline kapcsolatban lévő minden eszköz és szoftver időszinkronizálását ugyan arról a helyről kell megvalósítani. Intézményen belül biztosítani kell a szerver, kliens eszközök és alkalmazások időszinkronizálásának megoldását.

37

EuroRec:EU003925.01 EuroRec: EU002888.01 39 EuroRec: EU002890.02 40 Az előírásokat a 195/2005. (IX. 22.) Korm. rendelet változásának megfelelően módosítani szükséges. 41 A gyakorlatban többféle forrásból kaphatunk pontos időt. pl: az atomórák által előállított idő,a GPS (Global Positioning System), stb. 38


27


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

Alapellátás, ambulancia, szakrendelő, fekvőbeteg ellátás, krónikus ellátás, egynapos sebészet,stb. illetve ezek vegyesen.


28


A-6-002-2

o törzsadattárak kialakíthatóságára.

A-6-002-3

o

A-6-002-4

„Ellátás biztosító személyek” személyes és szakmai adatainak rendszerbe történő rögzíthetősége. o „Páciens törzsadatok” rögzíthetősége.

A-6-002-5

o

„Ellátó egységek” adatainak rögzíthetősége.

o Szabványos regionális és ágazati szintű működés és kommunikáció kialakíthatósága. o Az ellátás folyamata során a magyar szakmai, működési és finanszírozási A-6-002-7 gyakorlatnak megfelelő dokumentációs rend kialakíthatósága (Az intézményi folyamatok követése és támogatása). o intézményvezetéssel, működéssel kapcsolatos automatikus lekérdezések A-6-002-8 definiálhatósága és ütemezett elkészítésére Az informatikai szállító által leszállított rendszernek minden olyan modulja A-6-003 rendelkezzen szoftver akkreditációval, ahol ezt törvény előírja.(pl: receptíró alkalmazás) 43. A szállított szoftverekre a szerződés teljes időtartamára szóló díjmentes jogszabálykövetést kell biztosítani a jogszabályban előírt határidőre és a rendszert A-6-004 mindenkor díjmentesen alkalmassá kell tenni a jogszabályban előírt határidőre az adatszolgáltatási kötelezettségeknek (pl: adatbevitel, kódszótárak, adatküldés). A jogszabályváltozások miatti módosítást abban az esetben is térítésmentesen kell elvégeznie az informatikai szállítónak amennyiben változtatás elvégzéséhez az A-6-005 informatikai szállító olyan program modult fejleszt ki, amely az eddigi beüzemelt új modulok között nem szerepelt. A jogszabályi változásokat legkésőbb a hatályba lépést megelőző 3 munkanappal előbb a rendszer éles verzióján át kell vezetni (Az éles rendszerre való telepítést meg kell A-6-006 előznie egy sikeres tesztüzemnek). A működtetéshez szükséges dokumentáció és oktatási anyag átadásának is ez a határideje. Visszamenőleges hatálybalépés esetén úgy kell a változást a rendszeren átvezetni, hogy biztosítani kell az egészségügyi intézmény számára, hogy a szükséges tevékenységet A-6-007 visszamenőlegesen is elvégezhesse oly módon, hogy rá nézve negatív következményekkel vagy anyagi kárral ne szolgáljon. Ebben az esetben törekedni kell a lehető legegyszerűbb adatbevitel biztosítására. Az informatikai szállítónak biztosítania kell, hogy a szerződés megszűnése után a tárolt A-6-008 adatok a jogszabályi előírásoknak megfelelően díjmentesen visszakereshetők maradnak. Az ajánlatban részletes leírást kell a megvalósítás módjáról adni 44. Működtetéssel kapcsolatos dokumentáció Az átadás átvétel során minimálisan az alábbi rendszergazdai dokumentumokat kell A-7-001 átadni olyan részletezettséggel, hogy egészségügyi intézmény szakemberei a dokumentáció alapján az üzemeltetéssel kapcsolatos feladatokat el tudják látni o Logikai rendszerterv A-7-001-1 o Fizikai rendszerterv A-7-001-2 A-6-002-6

A-7-001-3

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

43 53/2007 (XII: 7.) EüM rendelet a gyógyszerrendeléshez használandó számítógépes program minősítésének szabályairól 44 A jelenlegi a virtualizált szoftverkörnyezetben történő adatmegőrzés tűnik a legmegfelelőbb megoldásnak. Ezért a megoldásszállítónak segítenie kell a szerződés megszűnése után a szervereken tárolt alkalmazások virtualizált környezetbe történő áttelepítésében.


29


A-7-001-4

o Adatbázis szerkezet leírás 45

A-7-001-5

o Interfész specifikációk 46

A-7-001-6

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

A-7-001-7

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

A-7-001-8

o Mentési visszaállítási terv 47

A-7-001-9

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

A-7-00110

o Felhasználói kézikönyvek

A-7-00111

o Üzemeltetési kézikönyv és szolgáltatási szint leírás

A-7-00112

o Informatikai biztonsági szabályzat

A-7-00113

o Migráció leírás

A-7-00114

o A működtető szervezet installációs és konfigurációs tevékenységeire vonatkozó kézikönyv

A-7-00115

o Az illesztett rendszerek illesztési protokolljának leírása 49

A-7-00116

o Távoli menedzsment kialakításának paraméterei (pl: VPN)

A-7-00117

o Felhasználói kézikönyv (modulonként)

A-7-00118

o Vészhelyzeti működési szabályzat

A-7-00119

o Az üzemeltetési szabályzat feladatlistájának részletes összeállítása 50

A-7-00120

o Minőségellenőrzési jegyzőkönyvek

A-7-00121

o Megvalósítási dokumentáció 51

A-7-00122

o Változáskezelést rögzítő dokumentáció mely a projekt teljes életszakaszában vezetendő dokumentum 52

A-7-002

Az Ajánlatevő köteles olyan részletezettségű dokumentációt biztosítani minden átadott modulhoz, amely alapján az egészségügyi intézmény szakemberei az elvárt

45

Az ellenőrzések a lekérdezések és az adatmigráció érdekében elkerülhetelen az adatbázis logikai, szerkezeti felépítésének dokumentáltsága. 46 Részletesen lásd – Architekturális követelmények – Általános architekturális követelmények 47 Részletesen lásd – Architekturális követekmények ‐ Mentési, archiválási, visszatöltési követelmények 48 A telepítési útmutatóknak minden rendszerbe integrált eszköz és szoftver telepítési, paraméterezési beállítását tartalmaznia kell. A változáskezelésben frissíteni szükséges. 49

Lásd az archuterturális követelmény leírásoknál megfogalmazottak 50 Ez az egészségügyi intézmény és az Ajánlattevő közös feladata. 51 Ennek a dokumentumnak tartalmaznia kell a rendszer minden állítható paraméterének éles induláskori értékét 52 Ez az egészségügyi intézmény és az Ajánlattevő közös feladata.


30


A-7-003

működtetési feladatokat el tudja végezni. A dokumentációkat elektronikus és minimum egy nyomtatott példányban is át kell adni. Ez alól kivételt képeznek az oktatási dokumentumok 53.

4.2 Az egészségügyi ellátási szintek specifikus követelményei

4.2.1 Az alapellátás specifikumai Az alapellátás fogalma: társadalmilag, bizonyos funkcióval szervezett egészségügyi ellátás lakosság közelébe vitt formája. Az egyes alfejezetet a fontosság sorrendjében tárgyaljuk. Az informatikai követelményeket úgy határozzuk meg, hogy az alapkövetelményeken (biztonság, megbízhatóság, stb.) felül milyen elvárásai vannak a rendszereket kezelő orvosoknak, asszisztenseknek, az ellátottaknak, a szakmai (kereskedelmi) felügyeletet gyakorlónak és a finanszírozónak. Az informatika feladata: az egészségügyi ellátás alapellátói (orvosok, szakdolgozók) tevékenységeinek kiszolgálása az informatika eszközeivel, a betegellátás minőségének és hatékonyságának emelésével. Napjainkban az alapellátók szinte kivétel nélkül alkalmaznak informatikát. Az informatikai rendszerekkel szembeni követelményeket az általános információskommunikációs technológiai jellegű követelményeken kívül aszerint csoportosítjuk, hogy hogyan szolgálják ki a rendszerek által érintett személyeket és szervezeteket. Még mielőtt az egyes alapellátók rendszereit tárgyalnánk, általános – minden ilyen rendszerre érvényes – követelményeket fogalmazunk meg. Az alapellátás szintjéhez tartozó ellátási rendszerek közül a betegellátással foglalkozókra – háziorvosi ellátásra (felnőtt, vegyes, gyermek és ügyeleti ellátások), a foglalkozás és üzemegészségügyi ellátásra, a védőnői szolgálatra – vonatkoznak a definiált specifikumok. Az alapellátáshoz tartozó többi ellátással, közöttük a preventív és karitatív szolgálatokkal (a fogorvosi ellátás és az iskola egészségügyi ellátás, ifjúság és gyermekvédelem, a szociális betegellátás és intézményei), a gyógyszertárakkal a jelenlegi követelmény rendezés nem foglalkozik, de szükség szerint megjelöli az információrendszerek közötti kapcsolatokat.

4.2.1.1 Háziorvosi‐, házi gyermekorvosi rendszerek A háziorvosi ellátás társadalom egészségügyi konszenzusokon alapuló rendelkezések szerint meghatározott lakosságcsoport – praxis – ellátásra szerveződött ún. orvosi munkahelyen, illetve orvosi munkahelyek hálózatán, azaz az orvos – beteg találkozások színhelyén (a rendelőben, a helyszínen) történik. Az orvosi munkahely adminisztratív megjelölése a háziorvosi rendelő (rendelők csoportja, hálózata), az ellátandókat a praxis jelöli (beleértve az ellátás különböző módon és formában szabályozott formáját).

B-1-001

Az információrendszereknek az orvosi munkahelyeken, így a háziorvosi rendelőben is a gyógyító – megelőző ellátás alapvető folyamatba rendezett tevékenységeit – az egészségi állapot azonosítását, a diagnosztikai vizsgálatokat, a diagnózis felállítását, a terápiát és kezeléseket valamint az értékelő, minősítő tevékenységeket – kell támogatnia. A tevékenységi sorhoz tartozik a rehabilitáció és a gondozás.

B-1-002

A háziorvosi ellátás információ technológiai és kommunikációs (a továbbiakban: IKT) rendszer alap konfigurációja a személyes interaktív kapcsolatokért felelős perifériák

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


31


(képernyő, klaviatúra, egér, tárkiegészítők, intelligens kártyák hagyományos és WiFi változatai) mellett tartalmazzon opcionális lehetőségeket az egyéni mobil eszközök befogadására (okostelefon, i-phone, i-pad, NFC eszközök stb.).

B-1-003

A konfigurációnak rendelkeznie kell olyan nyomtatási lehetőséggel, amely alkalmas a jogaszályokban előírt papíralapú dokumentációk előállítására (nyomtatására, kitöltésére) és helyet kell kapnia a rendszerben az elektronikus adathordozók (kártyák, CD, DVD olvasók, pendrive-ok) mellett papíralapú dokumentációkat beolvasó eszköznek is.

B-1-004

A háziorvosi rendszer orvosi munkahelyet kiszolgáló konfigurációja önálló működésre legyen alkalmas, de hálózatba is köthető legyen (intranet) és rendelkezzen szélessávú internet eléréssel, valamint sokoldalú elektronikus információ (jel, szöveg, hang, kép) továbbítási levelezési lehetőséggel (extranet, internet).

B-1-005

A rendszer hálózati, internet kapcsolatának sávszélessége és sebessége (műveleti sebessége) feleljen meg a konfigurációban alkalmazott IKT eszközrendszerek (alapszoftverek, középréteg kiszolgáló szoftverek, az alkalmazói réteg szoftverei) működési és felhasználói előírásának.

B-1-006

A munkaállomás (-ok) architektúrája alkalmazkodjon a befogadó környezethez és a telepített futtató környezethez (Windows, Linux, stb.).

B-1-007

A rendszerben alkalmazott IKT szoftverek legyenek jogtiszták, támogatottak, és legyen biztosítva a verziókövetésük, megfelelő, az orvosi munkahelyek működését folyamatosan biztosítani képes támogatásuk (medical support).

B-1-008

A háziorvosi rendszer dedikált adatrendszereiről, a páciens, a gyógyító - megelőző tevékenységek információról, az ellátási kimenetek adatairól meghatározott rend szerint biztonsági másolatoknak kell készülniük. A másolatok fizikai elkülönítéséről az IKT előírásokat figyelembe véve kell gondoskodni.

B-1-009

A rendszer, a teljes IKT konfiguráció legyen biztosított a fizikai védelme, legyen vírusés behatolás védett. A rendszer működése (adat és adatbázis kezelése, dokumentáció kezelés, a páciensek személyiség védelme) feleljen meg a hatályos hazai és nemzetközi adatkezelési jogszabályoknak.

B-1-010

A háziorvosi ellátás a praxisban körülhatárolt lakosságcsoport alapellátás szintű egészségügyi ellátását jelenti, amelyet a háziorvosi információrendszernek – a praxis információrendszernek – kell kiszolgálnia, lehetőség szerint teljes körűen. A praxis információrendszer (praxis rendszer) működése feleljen meg a háziorvosi ellátást szabályozó működési rendnek, jogszabályoknak 54.

B-1-011

A praxis ellátását kiszolgáló információrendszer („praxis-rendszer”, „praxis-szoftver”) tulajdonosa, felhasználója, alkalmazója és az informatikai rendszer szállítója (fejlesztője, az IKT karbantartója, a folyamatos support fenntartója) között olyan szerződéses jogviszonynak kell lennie, amelynek garantálnia kell a rendszer zavartalan működését. A fontosabb elvárásokat a következő sorok tartalmazzák.

B-1-012

Legyen a praxis-szoftver olyan, hogy az egyszemélyestől a csoportos praxisig képes

54

Az alapellátás feladatait, szervezeteit, működési rendjüket a hatályos törvények és jogszabályok keretében kialakított küldetésük, az orvostudomány és a társtudományok mindenkori elmélete és gyakorlata határozzák meg. A fentiek köré csoportosított rendező elveket különféle szervezeti és működési szabályzatok, hatásköri kompetenciák, orvosi protokollok és más dokumentumok tartalmazzák. Miután az alapellátást kiszolgáló egészségügyi informatika a klinikum, az orvosi munka szerves része, az alapellátás – és ezen belül a háziorvosi ellátás – információrendszereinek ezt az elméletet és gyakorlatot kell támogatniuk azzal, hogy rájuk vonatkoznak az alkalmazott informatika elméleti és módszertani szabályai is.


32


legyen kiszolgálni az háziorvosi munkahelyeket. B-1-013

Legyen a praxis-szoftver felkészítve a praxisban használt legáltalánosabb – informatikai összeköttetésre alkalmas – orvosi eszközök, osztott intelligenciájú műszerek (holter, EKG, spirometer, audiometer, telemetriás és ambiens-intelligens eszközök, stb.) interaktív kezelésére.

B-1-014

Legyen a háziorvos és a praxis-szoftver fejlesztője között rendszeresített információs csatorna (ügyfélszolgálati célú), amelyen keresztül az észlelt rendellenességek jelezhetőek. Minden észlelt és valós szoftver hiba javítása az összes praxis-szoftver számára legyen automatikusan elérhető

B-1-015

Legyen a praxis szoftver verziókövetett, az akkreditált frissítések lehetőleg automatikusan történjenek egy help-centerből, de legalább a verziók a háziorvosok számára on-line vagy adathordozón legyenek elérhetőek.

B-1-016

Alapvető követelmény a praxis-szoftverben az elektronikus betegazonosítás, a TAJ és más egészségbiztosítási jogosultság, jogviszony ellenőrzés on-line megvalósítása a praxis telephelyén, telephelyein.

B-1-017

A rendszerbe csak a csak a jogosult felhasználók léphetnek be, érhetik el és kezelhetik a praxis-szoftver betegadatait 55. Ehhez a hozzáférési jogosultság legyen beállítható és minden jogosultsági tranzakció legyen követhető digitálisan.

B-1-018

A praxis-szoftver legyen képes exportálni a különböző formátumú tartalmakat – többek között táblázatos formátumúakat – a külső felhasználás számára.

B-1-019

A betegek esettörténetében szereplő adatok kezelését naplózni kell olyan adattartalommal, amelyből az adatkezelés reprodukálható és ezzel együtt működjön a biztonságos és funkciók szerinti mentés. A rendezett archívum a praxis-szoftver alapvető szolgáltatása.

B-1-020

A praxis-szoftver rendelkezzen különféle szolgáltatásokkal a páciensek irányába. Nevezetesen legyen időpont foglalási lehetőség a betegek számára, legyen beteghívó lehetőség és rendelkezzen a kommunikáció technológiai eszközeivel (

B-1-021

Legyen lehetőség a beteggel elektronikus úton érintkezni (elektronikus kapcsolat a beteggel: email, sms, okos telefon, stb.). Emellett rendszer tartalmazzon olyan opciókat, amellyel a beteglátogatáskor az orvos munkája közvetlenül támogatható (okostelefon, laptop, notebook, iPod, tablet, stb.)

B-1-022

Szükség esetén a képernyő tartalma és a billentyűzet adatbeviteli szolgáltatása legyen mind az orvos, mind pedig az asszisztencia számára egyszerre elérhető, azaz szinkronban szolgálja ki az orvost és az asszisztenciát.

B-1-023

A rendszer legyen képes több telephelyen – akár egyidejű – működésre és rendelkezzen a helyettesítés lehetőségével A praxisban működő rendszerek között legyen olyan interaktív adatkapcsolat, amely lehetővé teszi az eredmények kölcsönös lekérdezhetőségét.

B-1-024

A horizontális, alapellátáson belüli hálózaton kívül a rendszer legyen alkalmas a magasabb ellátási szintekkel (szakorvosi járó és fekvőbeteg ellátás, szakosított szakellátás intézményei) való interaktív adat, lehetőség szerint jel és képtovábbító

55 A „betegadatok”, gyakran használt kifejezés, azonban ez szélesebb értelemben értendő a gyógyító – megelőző ellátás különféle rendszereit kiszolgáló információrendszerek esetében. Magába foglalja a páciens egészségi állapot tisztázásával, a diagnózishoz vezető vizsgálatokkal, a diagnózisokkal, az invazív és non invazív terápiákkal, a kimenetel és a minőség elemzésével kapcsolatos információkat. A „betegadminisztráció” kifejezés a betegadatok kezelését jelenti.


33


kapcsolatra valamint teljesítésére.

a

telemedicina

kompetenciáihoz

tartozó

szolgáltatások

B-1-025

A rendszernek legyen a jelentési kötelezettségeket is kiszolgáló állandó interaktív kapcsolódási lehetőségei az ágazati beszámoltatási jelentéseivel, adatbázisaival, az egészségügyi közhiteles adatbázisokkal és kódszótárakkal (ÁNTSZ, OEP, GYEMSZI) valamint lehetőleg nemzetközi tudásbázisokkal (pl.: bizonyítékon alapuló orvoslás).

B-1-026

A felügyeleti szervekkel és nem ágazati közigazgatási szervekkel legyen lehetőség elektronikus kapcsolat felépítésére és a jogszabályokban, az ágazati beszámoltatási rendszerben előírt jelentéseket a rendszer automatikusan szolgáltassa.

B-1-027

Legyenek epidemiológiai statisztikák elérhetőek és generálhatóak a rendszerben valamint a praxis kiszolgálásához, szakmai támogatásához szükséges hazai (szakmai kollégiumok, tudományos társaságok, kutató intézetek) és nemzetközi (WHO, OECD, nemzetközi társaságok) tudásbázisok és szótárak (BNO, FNO, OENI, stb.) szolgáltatásaikkal együtt legyenek hozzáférhetők.

B-1-028

Legyenek a legfontosabb népbetegségek kezelésére és ellátására vonatkozó protokollok elérhetőek a háziorvos számára olyan módon, hogy az a gondozási feladatait támogassa.

B-1-029

Az alapellátási információrendszereknek – így a háziorvosi rendszernek is – a meghatározó bázis rendszereleme a páciens rekord, pontosabban az elektronikus beteg rekord 56. Épp ezért a betegadminisztrációban és a praxis-rendszer minden moduljában biztosítani kell a páciens rekord kezelését, a páciens-orientált rendező elv érvényesítését.

B-1-030

A beteg megjelenésének, és ellátásának adminisztrációja legyen folyamatszerűen megoldva, beleértve az OEP jelentések (változás-, TAJ-, ambuláns-, szűrési és tételes forgalmi jelentések) on-line szolgáltatásait is. A rendszer legyen képes a törzskartonhoz dokumentumokat, OLE objektumokat (kép, video, hang) csatolni.

B-1-031

A betegadminisztráció legyen képes dokumentálni a beteg egészségi állapotát, annak változását meghatározó – a háziorvos tudomására került – jellemzőit, leírását: a beteg törzskartonját.

B-1-032

A betegadminisztráció legyen képes a beteg adatai között lekérdezést végezni betegségre, betegségcsoportra, ellátási időszakra, alkalmazott terápiára, diagnosztikára, a manuális törzskarton adatainak kezelésére.

B-1-033

A háziorvosi rendszer legyen képes a rendelés folyamatát kezelni, az ott felmerült aktivitásokat dokumentálni, vizsgálatkérő lapo(ka)t és konzílium kérés(eke)t előállítani nyomtatott formában, de állítsa elő elektronikus formában is, amennyiben a másik egészségügyi szolgáltatónál megvannak a fogadás feltételei.

B-1-034

A rendszer legyen képes a háziorvos praxisában lévő gondozottakkal, veszélyeztetettségük miatti megfigyelést igénylőkkel való kötelező tevékenységeket tervezni, követni, ezzel kapcsolatosan figyelmeztetni.

56

Az egészségügyi információrendszerek – mindazok, amelyek a populáció gyógyító‐megelőző ellátását támogatják, illetve annak szerves részét alkotják – a páciensek, a betegek páciens‐orientált informatikai struktúrát, rekordot használnak az ellátás, a diagnózisok, az eredmények, terápia értékhordozó információinak rögzítésére, kezelésére, követésére. A szinonim elnevezések: elektronikus beteg vagy páciens rekord, kórlap, kórtörténet, leggyakrabban használt nemzetközi elnevezés: electronic medical record [EMR]. A személyre szabott egészségügyi ellátás terjedésével (personalized health) egyre gyakrabban jelenik meg a probléma orientált portábilis páciens rekord fogalma (az „elektronikus” jelzőt beleértik az alapelnevezésbe, magától értetődőnek tartva azt).


34


B-1-035

Legyen a rendszer képes mindenfajta – a praxisban dolgozó orvos számára megengedett készítményt előírását tartalmazó – rendelvény (vény) előállítására (nyomtatására); opcionálisan a vény elektronikus feltöltésére a központi eRecept felületre.

B-1-036

A praxis-szoftver legyen képes a háziorvosi rendszer ügyeleti szolgálatát támogatni, a jelentkező betegek ellátási eredményeit rögzíteni, a szükséges – a sürgősségi ellátás szempontjából fontos – információkat értékelni és kezelni.

B-1-037

A praxis-szoftver rendelkezzen a terápiát, a gyógyszerelést segítő adatbázis hozzáférésekkel, az esetleges tele-konzilium opcionális alkalmazásával.

B-1-038

Az ügyeleti rendszer modul legyen képes az ügyeleti működésről szóló jelentéseket, elemzéseket, értékeléseket hagyományos és elektronikus formában elállítani és továbbítani.

B-1-039

A program automatikusan állítsa elő az ügyeleten történt ellátások leletteit és ezeket elektronikus formában juttassa el az ügyeleti ellátáshoz területilag kapcsolódó praxisokhoz.

4.2.1.2 Gyógyszertári rendszerek Bár elméletileg a gyógyszertári rendszerek nem a klasszikus alapellátás részei, viszont a a gyógyszertárak szervezése, lakosság-közelisége, számossága és fontossága azt kívánja, hogy itt tárgyaljuk. A gyógyszertár egészségügyi szolgáltató és kiskereskedelmi tevékenységet végző egészségügyi intézmény. Gyógyszertár közforgalmú-, intézeti-, fiók- és kézigyógyszertári formában működhet. A gyógyszertár egészségügyi feladata a lakosság gyógykezeléséhez kapcsolódó gyógyszerek kiszolgáltatása, valamint az e gyógyszerekkel kapcsolatos, a betegségek megelőzését szolgáló, a betegekkel történő együttműködést megvalósító felvilágosító, tanácsadó szolgáltatás. Mivel a gyógyszerterápia elrendelői és annak kiszolgálói egyaránt korszerű információs rendszereket használnak, időszerű a közöttük való kommunikáció – legfőképpen az e-Recept szolgáltatás – kiépítése. A gyógyszertári rendszereket jelen dokumentum kizárólag egészségügyi szempontból tárgyalja, nem foglalkozunk a gyógyszertárak kereskedelmi, gazdálkodási, pénzügyi elvárásaival. B-2-001

A gyógyszertári rendszer értelemszerűen feleljen meg a hatályos egészségügyi jogszabályoknak és egyúttal támogassa a fiók-gyógyszertári, valamint kézigyógyszertári készletek kezelését.

B-2-002

A rendszer segítségével legyen elkészíthető az egészségbiztosítási szerv felé a jogszabályokban meghatározott elszámolás (heti) és támogassa az expediálás folyamatát, az ügyfelek számára jelenítse meg a gyógyszervásárlás releváns információit (pillanatnyi összérték).

B-2-003

A gyógyszertári rendszernek biztosítania kell a gazdálkodáshoz szükséges funkciókat: megrendelés, beszerzés, készletgazdálkodás, saját felhasználás, számlázás, számlavezetés, könyvvezetés, nyilvántartások vezetése, pénzügyi bizonylatok kezelése, hulladékkezelés, minőségbiztosítás

B-2-004

A rendszer tartson kapcsolatot a gyógyszer szállítókkal, tartalmazzon paraméterezhető szolgáltatást a gyógyszer készletfogyás figyeléséhez a gyógyszerlejáratok követésével együtt.

B-2-005

A rendszerek tartalmazzák a legfrissebb gyógyszer-helyettesíthetőségi táblázatot, és kontra-indikációs táblázatot és legyen képes a rendszeres gyógyszerelés követésére, a


35


készletek ehhez történő igazítására. B-2-006

A gyógyszertári rendszer működjön együtt az OEP rendszerével, és használja az elektronikus TAJ ellenőrzést és opcionálisan készüljön fel az e-Recept funkció használatára és szolgáltatásaira.

B-2-007

Legyen lehetőség a beteg kérésére gyógyszert rendelni, azaz a rendszer kezelje a készítendő gyógyszerek adminisztrációját (beteg visszahívási szám).

4.2.1.3 Foglalkozás‐egészségügyi rendszerek A foglalkozás-egészségügyi szolgálat feladata hogy (i) felkutassa, folyamatosan ellenőrizze a munkahelyi (fizikai, szellemi, lelki) megterhelést és a munkakörnyezeti kóroki (fizikai, kémiai, biológiai, pszicho-szociális, ergonómiai) tényezőket; (ii), hogy javaslatot tegyen arra, milyen módszerekkel lehet mindezeket az egészséget nem károsító szinten tartani; (iii) hogy testi, szellemi és lelki egészségi állapotuknak megfelelően a munkavállalók képességeihez adaptálja a munkát; (iv) hogy a munkájukkal kapcsolatban ellenőrizze a munkavállalók egészségét. Ezeket a szolgáltatásokat alapszolgáltató, központ és szakellátó szinten nyújthatják. A foglalkozás-egészségügyi rendszerek a fenti feladatot támogatják. B-3-001

A foglalkozás-egészségügyi rendszerek a rájuk vonatkozó hatályos jogszabályoknak megfelelően működjenek, információrendszerük legyen képes a foglalkozásegészségügyi szolgáltató tevékenységét adminisztrálni és dokumentálni, mindenek előtt a páciensek ellátását követni.

B-3-002

Legyen képes a munkaköri, szakmai illetve személyi higiénés alkalmassági vizsgálatot dokumentálni és a foglalkozási betegségek és fokozott expozíciós esetek kivizsgálását az elektronikus páciens rekordban.

B-3-003

Legyen alkalmas szakorvosi, kórházi beutalót, konzíliumkérést, vizsgálati eredményt, és más páciens orientált bizonylatot készíteni hagyományos és elektronikus formában

B-3-004

Az információrendszer folyamatosan kövesse a dolgozók alkalmassági vizsgálatát, megjelenéseit, gondozási-szűrési adatait, tárolja a beutalásokat, vizsgálati eredményeket és a felírt gyógyszereket, továbbá segítségével tételes és számszerű kimutatások, elemző statisztikák készíthetők, akár grafikus formában is és elektronikusan kezelhető módon.

B-3-005

A rendszer végezze el a partner munkahelyek és munkahelyi bejelentők nyilvántartását, dokumentálja az üzemorvosi ellátás minden elemét az anamnézistől, az alapvizsgálatokon, a higiénés adatlap vezetésen, a kötelező vizsgálatokon át, a munkaköri védőoltásokig.

B-3-006

Legyen képes a közúti járművezetők egészségügyi alkalmassági vizsgálatának dokumentálására, jogosítvány adatainak tárolására és segítségével legyen készíthető alkalmassági vélemény, egészségügyi nyilatkozat lőfegyver használati engedélyekhez.

B-3-007

Tartalmazzon adatbázist az egyéni védőeszközökről, legyen képes a munkavégzés egészségkárosító hatásának vizsgálatát dokumentálni, legyenek elemzési, értékelési lekérdezési és statisztikai funkciók.

B-3-008

Legyen a rendszerben olyan informatikai panel, amely alkalmas a munkáltató katasztrófamegelőző, -elhárító, -felszámoló és rehabilitációs tervének kidolgozására.


36


B-3-009

A rendszer legyen opcionálisan képes – a háziorvosi rendszerhez hasonlóan mindenfajta – a sürgősségi ellátás számára megengedett készítményt előírását tartalmazó – rendelvény (vény) elektronikus formában a leendő e-Recept központnak továbbítani.

B-3-010

A rendszer legyen képes a szükséges – jogszabályokban előírt – jelentések elkészítésére hagyományos és elektronikus formában és legyen képes elektronikus úton történő elküldésükre.

4.2.1.4 Védőnői rendszerek A védőnői szolgálat feladata a gyermekágyas nő gondozása, az újszülött-kor, a gyermekkor egészség-menedzselése, a család egészségnevelése, egészség-tanácsadása. Ehhez tartozik a védőoltási rendszer (kötelező, életkorhoz kötött) működtetése, az ezzel kapcsolatos jelentések készítése. A jogszabályoknak megfelelően a védőnők tevékenységének tárgyi feltételei között találjuk a számítógépet (1 db/2 fő), illetve hardver+szoftver+karbantartás követelményét. A rendszerek fenntartásáról a védőnői szolgálatot működtető szervezet biztosítja. B-4-001

A védőnői tevékenységeket támogató információrendszer elégítse ki a szakmai elvárásoknak, védőnőkre vonatkozó hatályos jogszabályoknak megfelelő követelményeket.

B-4-002

A védőnői rendszer adminisztrálja a védőnő tevékenységét, a szükséges ellátásigondozási adatokat (gyermekágyas nyilvántartás, várandós törzslap, gondozási lap, újszülött nyilvántartás, újszülött gondozási lap, gyermek-egészségügyi törzslap, egyedi oltási lap, oltási összesítő).

B-4-003

A védőnői rendszer segítségével ki lehessen mutatni a védőnői ellátás (gyermekágyas anya, újszülött) megfelelőségi indikátorait

B-4-004

A védőnői rendszer segítségével legyen készíthető, módosítható a várandós gondozási terv.

B-4-005

B-4-006

A védőnői rendszer legyen alkalmas a munkakör tevékenységeinek hagyományos adminisztratív támogatására, de rendelkezzen az adatbázisára támaszkodó elektronikus változatokkal is. A rendszer részletes (ki, hol, mit, mikor) és könnyen lekérdezhető tranzakciós és eseménynaplózással rendelkezzen minden tranzakcióról (pl: adat bevitel, módosítás, megtekintés, nyomtatás, törlés, adat továbbítás, adat leválogatás stb.) 57

4.2.2 Az szakellátás specifikumai

4.2.2.1 Tranzakció és eseménynaplózás a HIS rendszerekben A felhasználók az adatbázis-kezelő és az operációs rendszer tevékenységeit naplófájlban kell rögzíteni. Ebből megtudhatjuk mikor ki jelentkezett be és mit csinált a rendszerben. A naplózást lehetőség szerint úgy kell beállítani, hogy minél szélesebb körű legyen a tevékenységek naplózása. C-1-001 58

57 58

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

A HIS rendszerben működő minden eszköz időszinkronizálását ugyan arról a helyről kell megvalósítani. EuroRec: EU002863.02


37


C-1-002 C-1-003 59 C-1-004 C-1-005 C-1-006 C-1-007 C-1-008 C-1-009 C-1-010 C-1-011 C-1-012 C-1-013 C-1-014 C-1-015 C-1-016 C-1-017 C-1-018

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

59

EuroRec: EU002856.03 A HIS rendszerben működő minden eszköz időszinkronizálását ugyan arról a helyről kell megvalósítani. 61 A rendszert fel kell arra készíteni, hogy a páciens bármely kűlső azonosítóinak megváltozása esetén is a rendszerben az azonosítás, megfeleltetés egyértelműen megadható legyen 62 Lehetőséget kell biztosítani paciens adatok összefűzésére és szétválasztására (lásd a késöbbiekben) 60


38


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

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

C-2-002 65

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.

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

C-2-004 66

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

C-2-005

67

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

C-2-006 68

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

C-2-007 69

A rendszer minden adatbeviteli képernyőn ki kell jelezni a páciens intézményen belüli egyedi azonosítóját az adott kezeléshez tartozó egyedi megrendelés azonosítót és a páciens nevét.

C-2-008 70

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

C-2-009 C-2-010 71

A rendszergazdai tevékenységeket megváltoztathatatlanul naplózni kell. A rendszer felhasználóinak és adminisztrátorainak olyan szintű képzést kell kapniuk 72,

63

A tűzfalak és a vírusvédelem specifikációjával és minimális elvárásaival jelen anyag nem foglalkozik. EuroRec: EU002283.06 65 EuroRec: EU002856.03 66 EuroRec: EU002659.03 67 EuroRec: EU002660.03 68 EuroRec: EU002661.02 69 EuroRec: EU003585.01 70 EuroRec: EU002831.04; EU003903.01 71 EuroRec: EU002836.02 64


39


hogy a feladataikat önállóan el tudják végezni. C-2-011 73

Az egészségügyi adatokhoz való hozzáférést minden esetben meg kell előznie a megfelelő azonosításnak.

C-2-012

A felhasználó orvos/szakdolgozó csak azokhoz az adatokhoz férhet hozzá, amelyekhez jogosultsága van.

C-2-013 74

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

C-2-014 76

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

C-2-015 78

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

C-2-016

A rendszernek meg kell felelni a hazai informatikai szabványok szerinti kommunikációnak 79.

C-2-017

A rendszernek meg kell felelni a vonatkozó hazai és nemzetközi adatvédelmi jogszabályoknak.

4.2.2.3 Az alkalmazásokkal kapcsolatos jogosultság kezelés

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

C-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:

72

Részletesen lásd az oktatásoknál. EuroRec: EU002837.03 74 EuroRec: EU003304.05 75 A jogosultságot még idő és hozzáférési hely szerint is lehet paraméterezni. 76 EuroRec: EU002850.06 77 Törvény által szabályozott esetekben. 78 EuroRec: EU003885.02 79 EHR extract generálás, fogadás és kommunikáció (CEN 13606, MSZ 22800) 73


40


C-3-002-1 C-3-0022 80 C-3-0023 81 C-3-0024 82 C-3-002-5 C-3-0026 85 C-3-002-7 C-3-0028 86 C-3-003 C-3-003-1 C-3-003-2 C-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 mindenkinek magának meg kell tudni változtatni o A jelszót 1-3 havonta 83 legyen kötelező megváltoztatni, a változtatásra a rendszernek a lejárat előtt XX 84 nappal és ezután minden hozzáférésnél újra figyelmeztetnie kell a felhasználót. A rendszer figyelje az előző jelszavakat és ne engedjen előzőleg már használt jelszót használni a felhasználónak. o Amennyiben a jelszó lejár, új, egyszer használatos jelszót kell kérni a rendszeradminisztrátortól, amelyet azonnal meg kell változtatni. o A jelszavakat csak vissza nem fejthető formában szabad tárolni o Jelszót tilos telefonban, e-mailben, szóban, vagy bármely más nem titkosított csatornán közölni, 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-egy személyhez hozzákapcsolni vagy elvenni o Legyen mód szerepkörökhöz kötődő másolható sémák létrehozására, amelyet az adott felhasználó adatainak beállításával lehessen személyre szabni. o A felhasználók HIS alkalmazáshoz történő hozzáférési jogosultságát személyre és szerepkörre szabottan (egy természetes személy több szerepkörben is lehet és az adatvédelmi törvény miatt ehhez különböző jogosultságok tartozhatnak) lehessen megadni.

C-3-004

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

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

C-3-006

A rendszer használatára jogosult felhasználók tevékenységéről a felhasználó által szabadon paraméterezhető napló állományt kell tudni készíteni.

C-3-007

A megajánlott rendszer rendelkezzen olyan jogosultságmátrix kezelő rendszerrel, amelyben legyen mód egy-egy felhasználó hozzáférési jogosultság beállításával kapcsolatos összes funkció és opció beállítást, tevékenységek végzésével kapcsolatos minden jogosultságot lehetőség szerint egy funkción belül beállítani (új felvétel,

80

EuroRec: EU002831.04; EU003903.01 EuroRec: EU002831.04; EU003903.01 82 EuroRec: EU002831.04; EU003903.01 83 Legyen a rendszerben szabadon paraméterezhető. 84 Legyen a rendszerben szabadon paraméterezhető. 85 EU002831.04; EU003903.01 86 EuroRec: EU002835.01 87 Például konzíliárusok számára 81


41


megtekintés, megnyitás, szerkesztés, módosítás, nyomtatás, átemelés, validálás,stb.). A rendszernek a jogosultság beállításokat naplózni kell. C-3-008

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

Digitális aláírás, hitelesítés A rendszer legyen felkészítve az egészségügyi üzenetek digitális aláírásának megvalósítására és a finanszírozó által támogatott elektroniokus hitelesítési eljárásokra. A rendszernek támogatnia kell az OEP által támogatott elektronikus orvosi-, és C-4-001 88 szakdolgozói hitelesítési és azonosítási módokat, valamit az elektronikus TAJ-kártya használatát. A megajánlott rendszer legyen képes digitális aláírással ellátott beérkező C-4-002 dokumentumok fogadására és időpecséttel történő ellátására és a rendszerben történő tárolására. A megajánlott rendszer legyen képes kimenő dokumentumokat digitális aláírással C-4-003 ellátni és archiválás céljából eltárolni. A használni kívánt digitális aláírásnak kétszintűen kell működnie: o A természetes személy 89 digitális aláírása (minősített) C-4-003-1 C-4-003-2 C-4-004

C-4-005

C-4-006

o A természetes személy aláírását felülhitelesítő intézmény 90 aláírása (fokozott) Az aláírásokat és az esetleges XML szintű adat rejtjelezést 91 kezelő komponenseket a vonatkozó nemzetközi szabványoknak megfelelően és az EU által definiált algoritmusokkal kell megvalósítani. A megajánlott rendszer legyen felkészítve digitális aláírás modul használatára annak érdekében, hogy az aláírásra kijelölt végpontokon és folyamatlépésekben lehetőség legyen az ezt elváró rendszerek felé küldendő dokumentumok megjelenítésére és aláírására valamint időpecséttel való ellátására. Az üzenetek aláírásával kapcsolatban az MSZ 22800 szabványban előírtak a mérvadóak 92. Az üzenetek létrejöttekor biztosítani kell, hogy az egész üzenetet többen is elláthassák aláírással, illetve, hogy egy aláírt üzenet része lehessen egy másik, szintén (akár többszörösen) aláírt üzenetnek. Lehetővé kell tenni egyrészt egyenrangú aláírások, egymástól független elhelyezését, másrészt a már aláírt üzenetet egészében (a korábbi aláírással együtt) tanúsító aláírások elhelyezését. Ez utóbbi mechanizmus tetszőleges mélységben egymásba ágyazható szerkezetet hoz létre.

4.2.2.4 Interoperabilitás Lásd a 1.1 fejezetben

4.2.2.5 ISO OID (Object IDentifier – egyedi azonosító) rendszer használata C-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

88

EuroRec: EU003925.01 pl: orvos, informatikus 90 pl:intézményi célalkalmazás 91 pl: XAdES szabvány(XMLDSIG és a különböző XAdES formátumok) 92 Egyenrangú üzenet‐aláírás, beágyazó üzenet‐aláírás, kombinált üzenet‐aláírás 89


42


ITU-T ajánlás tartalmazza. Mivel a hazai és nemzetközi egészségügyi szabványok kötelező attribútumaikban alapvetően építenek az OID-k rendszerére 93, a szabványos kommunikáció és dokumentumok kialakításához szükséges az egészségügyi informatika területéhez kapcsolódó OID-rendszer használata.

C-5-002

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

C-5-003

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

C-5-004

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

C-5-005

Az egységes ágazati dokumentációs rendszer során használni kell a magyar ISO OIDket.

C-5-006

Az egységes ágazati kommunikációs- és jelentés-rendszer során használni kell a magyar ISO OID rendszerben publikált kommunikációs szabványokat és protokollokat.

C-5-007

Az egységes ágazati EHR kommunikáció során használni kell a magyar ISO OID rendszerben publikált EHR archetípusokat.

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

C-6-001 94

C-6-002 95

A megajánlott rendszer minimálisan verziózva tartalmazza: o az egészségügyben az orvosi, ápolási és a finanszírozási adatok leírásához szükséges kódszótárakat (BNO, OENO, HBCS, stb.), o a működtetéshez szükséges közhiteles kódszótárakat (pl: orvoskódok) o a beküldő egészségügyi intézményekkel kapcsolatos azonosítókat (pl. háziorvosok azonosítói, stb.) A megajánlott rendszer tartalmazza és kezelje a szakellátásra vonatkozó aktuális törzsadatokat és szabályzatokat 96 o

93

A HL7 közösség – saját használatára – 2001. óta mintegy 4800 OID‐t regisztrált a 2.16.840.1.113883 (joint‐iso‐itu‐ t.country.us.organization.hl7) node alatt. http://www.hl7.org/oid/index.cfm 94 EuroRec: EU002853.05 95 EuroRec: EU002853.05; EU003164.04 96 pl: HBCS besorolási szabályok, járó szabálykönyv,stb.


43


C-6-003 97 C-6-003 98 C-6-004 C-6-005 C-6-006 C-6-007

A kódrendszerek verziókövetését támogatni kell a rendszernek. A megajánlott rendszerbe az egészségügyi intézet kérésére szakma specifikus és egyéb (pl: Európai szakmai társaságok kódrendszerei) és intézet specifikus kódszótárak valamint marker kódok legyenek illeszthetők kialakíthatók. 99 A megajánlott rendszer legyen időgép, amely a kódszótárakat verzió szerint tudja kezelni (érvényesség kezdete, érvényesség vége) úgy, hogy a megjelenítéskor mindig az adott időpontnak megfelelő adattartalom kerüljön kijelzésre illetve kinyomtatásra. A kódszótárakban lehessen kódra és szótöredékre keresni. Lehessen a szótárban előforduló mezőkre növekvő illetve csökkenő sorrendbe rendezni. Amelyik szótár egyedi egyéb rendszerezési móddal is rendelkezik annál azt a módot is meg kell tudni jeleníteni 100 (pl. BNO) A megajánlott rendszerben használt közhiteles kódszótárakat és a velük kapcsolatos használati útmutatókatlegyenek mindig szinkronban a közhiteles publikáció szerintivel.

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

A rendszer alkalmas legyen a személyi adatok idősoros követésére 103 (pl. névváltozás, igazolvány szám változás, lakcím megváltozása, telefonszám változás, stb.)

C-7002 104

A rendszernek tárolnia kell tudni igény alapján legalább egy kapcsolattartó személyt a kapcsolattartó információval. (telefon, e-mail)

C-7003 105

Minél több természetes azonosító 106 alapján lehessen keresni (minimális elvárás: vezetéknév, keresztnév, anyja neve, születési dátum, nem, lakhely, lakcím) Minél több nem természetes azonosítót lehessen a rendszerbe rögzíteni és a rögzített azonosítók alapján keresni: o központilag generált egyedi azonosítók, pl. TAJ szám, 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.)

C-7-004

C-7-005

97

EuroRec: EU002853.05 EuroRec: EU002667.02 99 Amennyiben az egészségügyi intézmény egyedi adatok rendszerbe integrálását kéri abban az esetben is meg kell adni az adat forrását. 100 (pl. fejezetek szerinti tagozódás, fogalmi hierarchia, kereszthivatkozások, külső hivatkozások stb.) 101 Lásd: 1992. évi LXIII. Törvény 1. fejezet 2. § 1‐2 pont 102 EuroRec: EU003567.01; EU003568.01 103 A log állományokból megtekinthetők legyenek az előző verziók a módosító személye és a módosítás dátuma. 104 EuroRec: EU003569.02 105 EuroRec: EU003566.03 106 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. 98


44


C-7-010

Az On-line jogviszony ellenőrzésre legalább két független módon legyen lehetőség (pl: Interneten és mobil net). Műszaki hiba esetén a rendszer automatikusan váltson át a tartalék megoldásra 107. On-line jogviszony és jogosultság ellenőrzés 108 biztosítása mindenhol ahol a törvényi előírások elvárják. A megvalósított rendszerben meg kell oldani, hogy naponta egynél többször ne legyen egy betegnél TAJ szám ellenőrzés (TAJ szám proxy kialakítása). Betegmozgás adatok naplózása 109 (felvétel, távozás, áthelyezés, elbocsátás, más intézetbe helyezés, átvétel más intézettől, elhalálozás, adaptációs szabadság stb.) Legyen mód beteg adatok összefűzésére és szétválasztására.

C-7-011

Sürgős esetben legyen egyszerűsített felvételre lehetőség 110

C-7-012

Paciensek közötti kapcsolat lehessen rögzíteni (pl:anya-gyerek(ek), gyámság stb.).

C-7-006 C-7-007 C-7-008 C-7-009

C-7013 111 C-7014 112 C-7-015 C-7-016 C-7017 114

A betegadminisztrációs rendszer folyamatosan bővíthető dokumentumsablon tárat tudjon kezelni (új beillesztése, módosítás, törlés stb.). 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 113 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ó).

4.2.2.8 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. C-8-001 C-8-002 C-8003 115 C-8-004

Legyen mód járó-fekvőbe, fekvőből-járóba való átminősítésre. Személyhez (pácienshez) köthető orvosi adatok rögzítésére legyen lehetőség (pl: rizikófaktorok, allergia, gyógyszerérzékenység, igazolvány számok és érzékenység, stb.). Az adott orvosi szakterület által használt és a finanszírozáshoz szükséges kódszótárak biztosítása a rendszer használata során. A kódszótárak használatát verziókezeléssel kell ellátni 116

107

Ennek a követelménynek a technikai megvalósítása nem az Betegadminisztrációs rendszer feladata. Műszaki hiba esetén a törvényi előírásoknak megfelelő időszakon belüli automatikus ellenőrzés. 109 pl: intézet, telephely, rendelő, osztály, nővérpult, szobaszám, ágy, … 110 A sürgősségi műveleteket nevesíteni és naplózni kell. 111 EuroRec: EU002854.02 112 EuroRec: EU002854.02 113 pl: beteg behívó rendszer 114 EuroRec: EU002860.02 115 EuroRec: EU002853.05 116 Az adatok lekérdezésekor, megjelenítésekor mindig az adott időszakhoz tartozó érvényes kódokat kell megjeleníteni! 108


45


C-8-005 C-8-006 C-8-007

C-8-008

C-8009 118

C-8010 119 C-8011 120 C-8011 121 C-8012 122

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álni 117 é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 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.

C-8-015

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

C-8-016

Finanszírozási adatok egy képernyőn történő rögzítési lehetősége legyen megvalósítva.

C-8-013 C-8-014

C-8-017 C-8-018 C-8-019

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.

117

Pl: szakmai kollégiumok vagy nemzetközi társaságok által kiadott kódszótárak. EuroRec: EU003059.05 119 EuroRec: EU003128.06; EU003129.03 120 EuroRec: EU003144.04 121 EuroRec: EU003182.02 122 EuroRec: EU002855.01 118


46


4.2.2.9 Megrendelésekkel kapcsolatos általános elvárások C-9-001

C-9-002

C-9-003

C-9-004 C-9-005

C-9-006

C-9-007

4.2.2.10

Elektronikus (mind belső mind külső szolgáltatótól) szakmaspecifikus struktúrának megfelelő • labor-kérés és eredmény fogadás • diagnosztikai-kérés és eredmény fogadás • konzílium-kérés és eredmény fogadás Az elektronikus kérőlapok űrlapként 123 szabadon definiálhatóan és szerkeszthetők (adatbeviteli képernyőn szereplő adatbeviteli mezők és nyomtatási kép) valamint verziózhatók legyenek a felhasználó által 124. A kitöltött kérőlapok legyenek nyomtathatók az adott időszaknak (időgép szerű működés elvárt) megfelelő nyomtatási elrendezéssel. A nyomtatás megjelenése a felhasználó által szabadon legyen szerkeszthető (fejléc, kép beemelés (pl. UH kép), adatelemenkénti elhelyezés definiálása, tabulálás, adatbeviteli mező üres karaktereinek levágása, pozícionálás, táblázatos megjelenítés, egyéb a rendszerben tárolt információ egyedi azonosító nyomtatás, betűtípus, betűméret, üres adatmezők elnyomása). A kitöltött illetve a kinyomtatott kérőlapok verziózva, egyedi azonosítóval ellátva reprodukálható módon tárolódjanak el a rendszerben. A rendszerbe rögzített elektronikus vizsgálatok és diagnosztikai kérések mindegyikéből automatikusan lehessen HL7 v3 verziójú munkalistát előállítani és kétirányú adatkommunikációt megvalósítani. Képi vizsgálatkérések esetén a képtároló és archiváló rendszerben tárolt (PACS) DICOM szabvány szerinti álló és mozgóképet lehessen egy direkt URL-el megcímezni és a rendszerből való kilépés nélkül egy külön ablakban megjeleníteni vagy egy ingyenes megjelenítő szoftverrel vagy az Megrendelőnél erre a célra alkalmazott speciális képmegjelenítő szoftverrel. Amennyiben a képi vizsgálatkérések közül megtekintésére kijelölt képek (álló és vagy mozgó) már archívumban vannak a HIS rendszernek alkalmasnak kell lennie az archívumból történő visszatöltés automatikus elindítására is a megtekintő jóváhagyása után.

Labor kommunikációval kapcsolatos alapvető elvárások

A következő táblázatban összefoglaljuk a labor kommunikációval kapcsolatos alapvető elvárásokat. Az anyag mellékletében összefoglaljuk az ezen moduloktól elvárt minimálisan funkcionalitást. C-10-001 C-10-002 C-10-003 C-10-004

Az egészségügyi intézmény szakmai igényeknek, az „Orvosi Laboratóriumi Vizsgálatok Szakmai Kollégiuma” előírásainak és a laboratórium struktúrájának megfelelő kérőlapok legyenek kialakíthatók a rendszerben. Az egészségügyi intézmény szabadon definiálhasson kéréscsoportokat működési egységenként. 125 A kéréscsoport feladásakor ne legyen kötelező a csoport minden elemét megrendelni. Lehessen annak megrendelendő elemeit szabadon kiválasztani. Legyen mód egy darab vizsgálat feladására is. Legyen mód a kéréscsoport kiegészítésére is. A rendszer legyen felkészítve különböző típusú és rendszerű vonalkódok használatára a

123

Az űrlapokkal kapcsolatos elvárások ezen anyag részét képezik. A felhasználó tudjon az adatmodellben létrehozni új kulcs érték párokat melyeket elhelyezhet az űrlapon illetve a nyomtatáson. 125 Pl: osztályonként, nővérpultonként, ambulanciánként, stb. 124


47


C-10-006

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.

C-10-007

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

C-10-008

A kéréseket lehessen priorizálni (Normál, Sürgős)

C-10-005

C-10-009

C-10-010 C-10-011 C-10-012 C-10-013 C-10-014 C-10-015 C-10-016 C-10-017 C-10-018 C-10-019 C-10-020 C-10-021 C-10-022 C-10-023 C-10-024 C-10-025 C-10-026 126

Legyen mód a kéréscsoportot plusz kérésekkel kiegészíteni a labor részéről amennyiben az elvégzett vizsgálatok eredményeként a szakma szabályai szerint 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, megjelenítése és nyomtatása (pl: protrombin lista). 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 kerüljön feltüntetésre a mintavételi edény típusa. Egyes vizsgálatkérések megrendelését lehessen jogosultsághoz (pl. személyhez, végzettséghez, stb. ) kötni. Minden vizsgálatnál lehessen beállítani figyelést, amely figyelmeztetést küld akkor, ha 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 mintavételi listát nyomtatni, amely egyben anyag „átadás-átvételi” kísérő listaként is funkcionál. A kérés és a validált eredmény automatikusan töltődjön át a rendszerek között (egészségügyi intézményi rendszer - Labor). Legyen mód vizsgálatokat előre megrendelni. A finanszírozási adatok automatikusan kerüljenek át a labor rendszerből az egészségügyi intézményi rendszerbe. Legyen mód a labor vizsgálatok eredményét a páciens dokumentumaiba beemelni 126. 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. Legyen mód egy páciens 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 vizsgálatonként, beküldő orvosra és szervezetre bontva is. Legyen mód egyes vizsgálatok elvégzését ütemezni. (pl: ha TSH csak 2 hetente kerül elvégzésre) A labor eredményekkel együtt kerüljön át a labor programból az egészségügyi intézményi rendszerbe az adott betegnek (kor, nem) megfelelő referencia tartomány. Legyen lehetőség a kóros eredmények figyelemfelkeltő jelölésére. (pl.*) Az egészségügyi intézményi rendszerbe átkerült labor leleten jelenjen meg a leletet validáló személy neve, beosztása.

Részleteket a dokumentumszerkesztésnél


48


C-10-027

Megfelelő tagolással lehessen megjeleníteni a több frakciós vizsgálatok eredményeit.

C-10-028

Minden vizsgálati eredménynek lehessen számszerű és szöveges eredménye is.

C-10-029

Külső labor eredményeit manuálisan is lehessen a rendszerbe rögzíteni.

C-10-030 C-10-031

4.2.2.11

Legyen mód összehasonlító és összegző listák készítésére a kért és elvégzett vizsgálatokról. A megajánlott rendszer rendelkezzen külső labor illesztéséhez kidolgozott szabványos illesztési felülettel

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

A következő táblázatban összefoglaljuk az egészségügyi dokumentum kezeléssel és kommunikációval kapcsolatos alapvető elvárásokat. Az anyag mellékletében (4.2.7 fejezet) összefoglaljuk az ezen modultól elvárt minimálisan funkcionalitást. C-11-001 C-11-002 C-11-003 C-11004 127 C-11-005 C-11-006 C-11-007 C-11-008 C-11-009 C-11010 128 C-11-011 C-11-012 C-11-013 C-11-014

127 128

A dokumentum szerkesztő szoftver az irodai alkalmazások piacán megszokott grafikus kezelői felülettel rendelkezzen. 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ére. 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” lehessen 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. A dokumentum mintákat lehessen kötni intézethez, osztályhoz, részleghez, ambulanciához, orvoshoz. A nyomtatási kép összeállítása szabadon definiálható legyen (olyan 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ám. A megszerkesztett dokumentumok verzió kezelése legyen a rendszerben megoldva. A dokumentumok minden módosított verzióját tárolni kell. A megszerkesztett dokumentumok nyomtatási verzió kezelése legyen a rendszerben megoldva. A dokumentumok minden nyomtatott egyedi azonosítóval kell ellátni és minden verzióját tárolni kell. A dokumentum szerkesztésével kapcsolatos jogosultságok legyenek személyhez kötötten beállíthatók (minimális elvárt jogok: olvasás, új dokumentum létrehozása, módosítás, jóváhagyás, nyomtatás, törlés). A dokumentum szerkesztésével kapcsolatos események legyenek követhetők, verziózottak. Dokumentumszerkesztés közben a pácienssel kapcsolatos a rendszerben tárolt dokumentumok, képek, leletek legyenek megtekinthetők (zárójelentés, leletek,

EuroRec: EU003202.01 EuroRec: EU003598.03


49


C-11-015 C-11-016 C-11-017 C-11-018 C-11019 130

szakvélemény, stb.). A megtekintés során, egyszerű módon legyen lehetőség a megtekintett szövegrészek és képek átemelésére. Legyen mód a rendszerben tárolt leletek és eredmények automatikus, de rendszerezett módon történő csoportos beemelésére 129. A leleteket az egészségügyi intézménnyel egyeztetett módon kell tudni a dokumentumokba beemelni. Legyen mód a rendszerben tárolt eredmények táblázatos módon történő megjelenítésére. Legyen mód lelettípusonként különböző leletbeemelési módot kiválasztani. A diagnosztikus munkahelyek vizsgálati eredményeit diagnosztikák szerinti 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.

C-11-023

A rendszerből kinyomtatandó dokumentumokban lehessen grafikus elemet 131 is elhelyezni. 132 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. 133 A létrehozott elektronikus dokumentumok legyenek validálhatók.

C-11-024

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

C-11-020 C-11-021 C-11-022

C-11-025 C-11-026 C-11-027 C-11-028

A makrók különböző csoportjai legyenek képezhetők (intézeti, osztályos és orvosonként egyedi). 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ára134.

C-11-030

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.

C-11-031

Nyomtatás előtt lehessen a kész dokumentumot megtekinteni (nyomtatási kép).

C-11-029

C-11-032 C-11-033

A megajánlott rendszer legyen felkészítve az egészségügyben használatos szokásos 135 és speciális nyomtatásra 136. A nyomtatási funckó legyen rugalmas papírméret, nyomtatási terület beállíthatósága tekintetében pl: legyen mód nyomdai úton előre nyomtatott fejléces

129

pl. az összes kémiai labor leletet lehessen vizsgálat típusonként dátum szerint csoportosan emelkedő sorrendbe beemelni EuroRec: EU003181.05 131 A beillesztett grafikus elem felbontása meghatározza, hogy milyen felbontású és technikájú nyomtató szükséges a beillesztett elem megfelelő minőségű kinyomtatásához. 132 pl: fejlécben embléma, ultrahangos kép, rajz, stb. 133 beutalók, kérőlapok, igazolások, nyilatkozatok, stb 134 Az űrlapokkal kapcsolatos elvárások ezen anyag részét képezik. 135 leporelló, A4, A5 136 Új és régi recept,egyedi etikett, csuklópánt, karton nyomtatás, CD lemez feliratozás 130


50


C-11-034 C-11-035 C-11-036 C-11-037 C-11-038

4.2.2.12

papírra nyomtatni. A dokumentumokat lehessen file-ba nyomtatni. A dokumentumokhoz beállítható legyen, hogy mikor tekintjük őket véglegesnek. A végleges dokumentumokat lehessen egy erre a célra kialakított tárházba (repositoryba) exportálni. Az exportálás szerkezetét lehessen beállítani. Az exportált repozitoriban arra jogosultsággal rendelkező személyek tudjanak keresni és nyomtatni. A repository-ban a dokumentumhoz csatolva kerüljenek exportálásra (pl: HL7 formátomban) a dokumentum keletkezéséhez kapcsolódó, valamint az ellátási adatok is.

Statikus és dinamikus űrlapok

A statikus űrlapok és dinamikus űrlapok használatával az eddig papír alapon rögzített űrlap adatok elektronikus úton történő előállítását, kinyomtatását, mentését és az űrlapokon rögzített információk adatbázisba kerülését kívánjuk megvalósítani. Az űrlapokat önálló dokumentumokként is lehessen használni (dokumentum C-12-001 típusokhoz rendelni vagy dokumentumokba beágyazni) és tárolni. Előre meghatározott módon, már adatbázisban tárolt adatok automatikusan C-12-002 megjeleníthetők legyenek egy új űrlap szerkesztésének kezdetekor. C-12-003 Az űrlapok egyes előre meghatározott mezőit lehessen default értékkel feltölteni. C-12-004 Az űrlapok mezőihez lenyíló menüs választásban kódszótárakat lehessen rögzíteni. C-12-005 C-12-006 C-12-007 C-12-008 C-12-009 C-12-010 C-12-011 C-12-012

C-12-013

Az űrlapokra minden olyan adat „felhelyezhető” legyen, amely az egészségügyi adatbázisban szerepel (Adat bekérés, A rendszerben tárolt eredmény megjelenítés). Az adatlap kitöltése során bevitt adatok felhasználásával előre definiált matematikai képlet (ek) alapján számítási műveletek végződjenek el (pl. testfelszín számítás). A számított értéket tartalmazó mezőben a számításban résztvevő adatok kitöltése után azonnal jelenjen meg a számított érték. A képernyőn el kell helyezni egy „számol” gombot melynek segítségével a számolást újra el lehet végezni. Az űrlap előre definiált mezői, ha egy meghatározott értéket vesznek 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 ű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. Az űrlapba lehessen képet beemelni. Az űrlapszerkesztés közben (kilépés nélkül) legyenek elérhetők és megjeleníthetők az intézeti PACS rendszerben tárolt álló és mozgóképek. Ez a szolgáltatás feltételezi egy DICOM konverter vagy egy gateway szolgáltatást nyújtását, lehetővé téve ezáltal licenszdíj nélküli megtekintő használatát. Az informatikai szállító feladata a megvalósítás kezdeti fázisában a szervezeti működési struktúrában szereplő összes egység statikus és dinamikus űrlap igényét 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.


51


4.2.2.13

Recept

A recept írás az egészségügyi alkalmazások sajátossága. A recept író szoftvereket auditáltatni kell a jelenleg érvényes törvények értelmében. A jelenlegi törvényi előírások ki fognak bővülni az e-recept kialakításával kapcsolatba. A recept író szoftverek újbóli auditja szükséges. C-13001 137

A receptíró szoftver megajánlott verziója rendelkezzen a törvény által előírt szervezet auditjával.

C-13002 138

Lehessen a jogszabályi előírásoknak megfelelő receptet nyomtatni (formai és tartalmi megfelelőség, extra vonalkód, stb.).

C-13-003 C-13-004 C-13-005 C-13-006 C-13-007 C-13-008 C-13-009 C-13-010 C-13-011 C-13012 139 C-13013 140

A szoftver által használt gyógyszertörzs frissítési technológiája és folyamata biztosítsa az OEP által közzétett gyógyszertörzzsel való tartalmi egyezőséget. 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árt. 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 szoftver a megszokott színek alkalmazásával segítse a helyes gyógyszerválasztást 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 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. Lehessen az Ajánlatkérőre jellemző specifikus magisztrális készítményeket rögzíteni. A kitöltött illetve a kinyomtatott receptek szakorvosi javaslatok és azok tartalmi elemei (név, adagolás, stb.) verziózva, egyedi azonosítóval ellátva reprodukálható, másolható módon tárolódjanak el a rendszerben. A receptírás legyen sablonokkal támogatott.

C-13014 141

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

C-13015 142

A már felírt recepteket lehessen másolni.

C-13016 143

A rendszer minden gyógyszer felírásnál jelezze a gyógyszer teljes árát és a páciens által fizetendő árat.

C-13017 144

Egy gyógyszer felírásánál a rendszer ellenőrizze és jelezze ki a felíró jogosultságát az adott szer felírására, a páciens jogosultságát a gyógyszer igénybevételére és az

137

EuroRec: EU003174.06 EuroRec: EU003185.03 139 EuroRec: EU003059.05 140 EuroRec: EU003188.03 141 EuroRec: EU003304.05 142 EuroRec: EU003186.03 143 EuroRec: EU003512.03 138


52


C-13018 145 C-13019 146 C-13020 147 C-13021 148 C-13022 149 C-13023 150 C-13024 151

4.2.2.14

esetleges költség limiteket. A rendszer figyelmeztesse a felhasználót amennyiben a jogosultságokat, ill. a limiteket nem tudta ellenőrizni. A gyógyszer adatbázist meghatározott időközönként (jelenlegi jogszabályi előírás 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 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 történt változtatásokat illetve megszüntetéseket és azok okát.

Erőforrás ütemezés

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

C-14-003

Az erőforrás ütemező modul a HIS rendszerbe legyen integrálva (közös adatbázisok, kódszótárak). Legyen lehetőség az erőforrások feltérképezésére és az erőrrás ütemezéséhez szükséges adatok rögzítésére Minden olyan eszközre, vizsgálatra, konzíliumra, műtétre, diagnosztikai vizsgálatra, helységre illetve személyre lehessen kialakítani olyan házon belüli ütemező rendszert, amely lehetségessé teszi: • A rendelkezésre álló kapacitások rögzítését • A rendelkezésre álló erőforrás kvótázását • Foglalást • Foglalás törlését 152 • Foglalás átütemezését

144

EuroRec: EU003516.03 EuroRec: EU003520.01 146 EuroRec: EU003544.04 147 EuroRec: EU003189.04 148 EuroRec: EU003189.04 149 EuroRec: EU003318.03 150 EuroRec: EU003328.04 151 EuroRec: EU003193.04 152 Foglalás törlése esetén automatikusan szabaduljon fel a lefoglalt időkeret 145


53


C-14-004 C-14-005 C-14-006 C-14-007 C-14-008 C-14-009

4.2.2.15

• A foglalás átütemezése esetén a foglaláshoz kapcsolódó vizsgálatok és diagnosztikai kérések átütemezését Az erőforrás ütemező modulnak legyen webes kapcsolata (erőforrás kiajánlás, erőforráskérés fogadás, erőforrás kérés visszaigazolás, erőforrás kérés átütemezés). Az erőforrás ütemező rendelkezzen önálló jogosultság kezelő rendszerrel. Az erőforrás ütemező modul egy-egy erőforrásra vonatkozóan rendelkezzen több (minimum 3) kvótázási lehetőséggel. A kvótákat különböző jogosultsággal lehessen elérni. Az erőforrás ütemező modul rendelkezzen olyan outputtal, amely segítségével az adott erőforráshoz ütemezett adatok megjeleníthetők és kinyomtathatók 153. Az erőforrás ütemezőbe rögzített adatok alapján lehessen kiértesítő levelet és borítékot nyomtatni vagy 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én 154 átütemezhetők legyenek egy másik időpontra.

Lekérdező modul

A HIS rendszerben tárolt adatok tetszés szerinti feltétel rendszer szerinti lekérdezhetősége, elengedhetetlenül fontos az egészségügyi intézmény menedzsmentje, szakmai munkájának áttekintése, tudományos jellegű munkák adatgyűjtése érdekében. C-15-001 C-15-002 C-15-003 C-15-004

A megajánlott eszköz tegye lehetővé az Ajánlatkérő HIS adattárában szereplő információk adatbázison belül történő feldolgozását 155. Az adatok lekérdezése során ne legyen szükség az adatok mozgatására a különböző adattároló eszközök között. Legyen lehetőség a felhasználó számára időzített és ütemezett lekérdezések konfigurálására. Legyen lehetőség a lekérdezések grafikus megjelenítésére.

C-15-006

A lekérdezés során előállt adatok szabványos adatformátumban 156 legyenek kimenthetők további feldolgozás céljából. Az Ajánlattevő alakítson ki az egészségügyi intézmény specifikus lekérdezéseit.

C-15-007

A lekérdezést lehetővé kell tenni minden rendszerben tárolt adatra.

C-15-008

Legyen lehetőség az időzített lekérdezési eredmények levélben történő továbbítására.

C-15-005

153

A megjelenítés és a nyomtatási képen megjelenő adatok legyenek felhasználó által szabadon változtathatók, paraméterezhetők. 154 A képernyő elhagyása nélkül felugró ablakok és egér segítségével lehessen az átütemezést elvégezni. 155 A hozzáférések számát az adott intézet határozza meg. A hardvereszközök méretezésénél az általános lekérdező modul teljesítményigényével is kalkulálni kell. 156 pl: txt, csv, xls


54


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

55


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

56


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


57


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

58


f. g. h. i. j. k.

TAJ ellenőrzés TAJ ellenőrzés hiányáról hibalista Havi tetszőleges számú HBCS elő besorolás futtatásának biztosítása HBCS optimalizálás Határnap figyelés. Garanciális idő figyelés

Fekvőbeteg dokumentumok kezelése (szerkesztés és nyomtatás) 21. Az Ajánlatkérő elvárásai szerint tudjon a rendszerbe új dokumentumokat, statikus és dinamikus űrlapokat szerkeszteni, beilleszteni, funkcióhoz csatolni. 22. A dokumentumot lehessen funkcióhoz esetleg munkaállomáshoz kapcsolni. 23. A jelenleg használt dokumentumok elkészítése az Ajánlattévő feladata (pl:kórlap, beleegyező nyilatkozatok, zárójelentés, kérőlapok, diagnosztikai kérések, konzílium kérések, vér rendelés, a visszaérkezett eredmények listái, stb.). PACS illesztés: 24. Az intézeti PACS rendszerben tárolt képek legyenek elérhetők a szakrendelői programból. 25. A PACS rendszerben tárolt képek leletbe történő illesztésére és nyomtatására legyen engedélyezet 4.2.6 Az elektronikus kórlaptól és lázlaptól elvárt minimális funkcionalitás 1. 2. 3.

4.

5.

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 9 Elrendelő neve, beosztása 9 Az elrendelt feladat neve és kódja 9 Gyakoriság, időpont 9 Dózis 9 Beadás módja 9 Intervallum 9 Felfüggesztés, folytatás, csere, elmaradás 9 Indoklás 9 Az elrendelés validálása Vizsgálat és konzílium kérésekkel kapcsolatos adatok rögzíthetők legyenek 9 Elrendelő neve, beosztása 9 Az elrendelt kérés neve és kódja 9 Időpont


59


6. 7. 8. 9. 10.

11. 12.

9 A mintavétellel kapcsolatos információk 9 Szállítás módja 9 Kérés törlése, indoklás 9 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 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.

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


60


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


61


4.3 Intézményi működést támogató informatikai rendszerek általános és specifikus követelményei Az egészségügyi, elsősorban a fekvő- és járóbetegellátó intézményeknél a nem (csak) egészségügyi ellátás specifikus, intézményi működést támogató informatikai rendszerek bevezetésénél, az alábbi követelménylistát javasoljuk alkalmazni, amely elsősorban az adott informatikai megoldás szállítójára, annak termékének és szolgáltatásának funkcionálisan és informatikailag elvárt követelményeire vonatkozik: 4.3.1 Intézményi működést támogató informatikai rendszerek általános követelményei (valamennyi ilyen típusú megoldásnál) D-1-001 Magyar szabályozási környezetnek megfelelő működés. D-1-002

Adatvédelem maximális szintű biztosítása (lásd 8.2. fejezet)

D-1-003

A rendszer rendelkezzen működéshez szükséges strukturált jogosultságkezeléssel.

D-1-004

A rendszer az intézményekkel működő más informatikai rendszerekkel kompatibilis

D-1-005

Központi címtárak (ActiveDirectory), alkalmazása Egységes jogosultság kezelő központ alkalmazása, amely minden felhasználó számára felhőszerűen, redundánsan elérhető A rendszer képes a felhasználók jogosultságával kapcsolatos ellenőrzések meghatározott időközönként való lefolytatására. Felhasználók skálázhatósága.

D-1-006 D-1-007 D-1-008 D-1-009 D-1-010

D-1-011 D-1-012 D-1-013 D-1-014 D-1-015 D-1-016 D-1-017

Bővíthetőség, a későbbi igények rugalmas kielégítése. A rendszer / megoldás legyen integrált (kétirányú adatkommunikációra képes) az intézménynél már megtalálható vagy egyidőben bevezetésre kerülő többi informatikai rendszerrel, alkalmazással. Az alkalmazások felhasználói interfészét az egyes alkalmazások esetében úgy kell kialakítani, hogy azok biztosítsák az alkalmazás képernyők, oldalak elvárható sebességű, elérhetőségét az általánosan elterjedt, kereskedelmi forgalomban rendelkezésre álló szélessávú internet kapcsolatokon keresztül. A rendszer használható felületeinek nyelve magyar legyen. A rendszer adminisztrációs felületeinek nyelve és a szoftver dokumentációja magyar legyen. Rendelkezésre áll a rendszerhez magyar nyelvű felhasználói dokumentáció. A rendszer valamennyi felhasználója részesüljön a megoldás szállítójától, vagy más módon (pl. a TÁMOP 6.2.7 projekt - lásd 3.1.7 fejezet - keretein belül) képzésben, betanításban. A bevezetendő alkalmazás szállítójának legyen működő referenciája az adott funkcionális területen. A rendszer fejlesztője / szállítója terméktámogatást legalább 5 évig.

biztosítson

magyar

nyelven

elérhető

4.3.2 Intézményi működést támogató informatikai rendszerek specifikus követelményei (a releváns megoldásoknál)


62


4.3.2.1 Intézményi gazdálkodást támogató rendszerek követelményei: Pénzügyi-számviteli rendszerek A pénzügyi-számviteli rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő egyéb gazdasági rendszerekkel (különösen a beszerzési, készletgazdálkodási, logisztikai és a HR, bérszámfejtési megoldásokkal) integráltan: • a számviteli-. ÁFA- és egyéb releváns törvények elvárásainak megfelelően folyamatosan kövesse az intézmény gazdasági- és pénzügyi eredményességét, valamint megfelelő könyvvezetést; • folyamatosan aktuális állapotot mutasson az intézmény pénzügyi kötelezettségeiről és vevői követeléseiről, továbbá a rövid- és hosszabb távú likviditási tervek készítésével támogassa az intézmény pénzügyi stabilitását. • segítse az eszközgazdálkodás optimalizálását, az intézmény tulajdonában lévő tárgyi eszközök értékelését; • Segítse a pénzügyi-számviteli munkatársak munkáját, csökkentve a szükséges munkaerő ráfordítást; • lehetővé tegye a pénzügyi és számviteli munkafolyamatok automatizálását, támogassa azok végrehajtását; • fentiek révén segítse az intézmény működési hatékonyságának növekedését. D-2-001 Főkönyvi analitika készítése. D-2-002

Költségnemek és költséghelyek könyvelése.

D-2-003

Adóanalitikák és kimutatások készítése, ÁFA és egyéb adók kezelése.

D-2-003

D-2-006

Tárgyi eszközök, azok állományváltozásainak nyilvántartása. Szállítói és (amennyiben releváns intézményi, szervezeti, vállalati) vevői (ügyfél) folyószámlák kezelése, nyilvántartása (iktatás, könyvelés, készítés). Beszámolók (pl. mérleg, eredménykimutatás) készítése negyedéves, féléves, éves zárási lehetőségekkel. Bankszámlakezelés.

D-2-007

Pénztárkezelés.

D-2-008

Tevékenység alapú költségelemzés, költségtervezés.

D-2-004 D-2-005

Központilag előírt költségvetési specifikációhoz való illeszkedésre való alkalmasság A pénzügyi- számviteli rendszer támogatja az államháztartás felé jelentési kötelezettséggel bíró operatív gazdálkodási folyamatait, tranzakcióit és biztosítja az D-2-010 egészségügyi intézményeknél alkalmazott szakrendszerek által a pénzügyi-számviteli rendszer felé kezdeményezett pénzügyi/gazdasági tranzakciók elektronikus kezelését. A rendszer támogatja az egészségügyi szakrendszerekből továbbított adatok digitális D-2-011 aláírását. A rendszer támogatja az egészségügyi szakrendszerekből továbbított adatok naplózását D-2-012 és visszakereshetőségét. Beszerzési rendszerek A beszerzési rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő egyéb gazdasági rendszerekkel (különösen a készletgazdálkodási és pénzügyi-számviteli megoldásokkal) integráltan: • segítse a beszerzési feladatokat ellátó munkatársak munkáját, csökkentve a szükséges munkaerő ráfordítást; • lehetővé tegye a beszerzési munkafolyamatok automatizálását, támogassa azok D-2-009


63


végrehajtását; • a fentiek és a beszerzendő termékek és szolgáltatások árazásának optimalizálásával segítse az intézmény működési hatékonyságának növekedését. D-3-001 Egészségügyi ellátásból érkező előrejelzések kezelése. D-3-002

Készletgazdálkodási adatok alapján a rendelési mennyiség optimalizálása.

D-3-003

Ajánlatkérések támogatása.

D-3-004

Beszerzési partnerek adatainak kezelése.

D-3-005

Beszerzési partnerek termékeinek, szolgáltatásainak nyilvántartása.

D-3-006

Beszerzési árlista kezelése (ügyfelenként, termékenként, tevékenységenként).

D-3-007

Beszerzési kedvezmények (mennyiségi, időszaki, egyedi) kezelése.

D-3-008 Beszerzési partnerek szerződéseinek, kötelezettségeinek nyilvántartása. Készletgazdálkodási, logisztikai rendszerek A készletgazdálkodási-logisztikai rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő egyéb gazdasági rendszerekkel (különösen a beszerzési és pénzügyi-számviteli megoldásokkal), valamint az egészségügyi ellátást, szolgáltatást támogató megoldásokkal integráltan: • segítse a készletgazdálkodási, logisztikai feladatokat ellátó munkatársak munkáját, csökkentve a szükséges munkaerő ráfordítást; • lehetővé tegye készletgazdálkodási, logisztikai munkafolyamatok automatizálását, támogassa azok végrehajtását; • fentiek révén segítse az intézmény működési hatékonyságának növekedését. D-4-001 Anyagok, készletek mennyiségben, értékben történő nyilvántartása. D-4-002

Készletgazdálkodás elemzése.

D-4-003

D-4-005

Minimális készlet, biztonsági készlet meghatározása, figyelése. Készletszint figyelése, kezelése az egészségügyi ellátási rendszerből érkező adatok, előrejelzések alapján. Raktárirányítás, több raktár kezelése.

D-4-006

Leltározás.

D-4-007

Selejtezés.

D-4-008

Visszárukezelés.

D-4-009

Gépjármű üzemeltetés támogatása (pl. menetlevelek kezelése).

D-4-010

Betegmozgatás támogatása.

D-4-011

Betegelhelyezés irányítása, kezelése (fekvőbeteg ellátó intézmények esetén).

D-4-004

Műtéti anyagfelhasználás optimalizálása (fekvőbeteg ellátó intézmények esetén). Élelmezési, dietetikai intézményi folyamatok / feladatok támogatása (fekvőbeteg ellátó D-4-013 intézmények esetén). D-4-014 Ebédjegy kezelés (amennyiben releváns az intézménynél) HR, bérszámfejtési rendszer A HR, bérszámfejtési (vagy munkaügyi) rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő egyéb gazdasági rendszerekkel (különösen a pénzügyi-számviteli megoldással) integráltan: • segítse a HR osztály vagy a humánpolitikai feladatokat ellátó munkatárs munkáját, D-4-012


64


csökkentve a szükséges munkaerő ráfordítást; • lehetővé tegye a munkaügyi munkafolyamatok automatizálását, támogassa végrehajtását; • fentiek révén segítse az intézmény működési hatékonyságának növekedését. D-5-001 Személyzeti törzsadatok kezelése. D-5-002

azok

Képzettségek, képzések nyilvántartása és nyomon követése.

Munkaszerződések, munkaköri leírások nyilvántartása. Bérezéssel, fizetésékkel kapcsolatos nyilvántartás (alapbér, túlórapótlék, táppénz, D-5-004 jutalom). D-5-006 Munkaadói, cafeteria juttatások adminisztrálása. Időgazdálkodás menedzsment (ügyeletek, távollétek, helyettesítések, többletmunkák, D-5-007 szabadságolások, teljesített munkaórák). Központi HR monitoring rendszer felé (amennyiben az is rendelkezik ilyen D-5-008 kapcsolódási képességgel, vagyis nyitott lesz a közvetlen adatkommunikációra) interface kialakítása Beléptetési, dolgozói regisztrációs adatok kezelése. D-061 Ügyfélkapcsolati (CRM) rendszerek Az ügyfélkapcsolati (CRM) rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő egyéb gazdasági rendszerekkel (különösen a beszerzési megoldással), valamint a külső intézményi portállal (weblappal) integráltan: • segítse a betegek időpontfoglalásával, az egészségügyi szolgáltatást igénybevevő szervezetekkel, vállalkozásokkal, az intézményi ügyfelekkel kapcsolatos feladatokat ellátó munkatárs munkáját, csökkentve a szükséges munkaerő ráfordítást; • lehetővé tegye a külső szervezetek felé irányuló munkafolyamatok automatizálását, támogassa azok végrehajtását; • javítsa az ügyfelek elégedettségét; • fentiek révén segítse az intézmény működési hatékonyságának növelését. Egészségügyi szolgáltatást igénybevevő szervezetek nyilvántartása (személyek, D-6-001 beosztások, szervezeti hierarchia). Ügyfélkezelés támogatása (kapcsolatfelvétel, előtörténet – nem egészségügyi D-6-002 vonatkozásban!). D-6-003 Intézményi Call center vagy diszpécserközpont kezelése. D-5-003

D-6-004

Intézményi Public Relations (PR) feladatok támogatása (rendezvények, meghívók).

D-6-005

Szállítók felé történő hibajelentések kezelése.

D-6-006

Reklamációkezelés.

4.3.2.2 Vezetői információs rendszerek (VIR) követelményei Döntéstámogató rendszerek A döntéstámogató rendszerek olyan szoftverek, szoftver-komponensek, informatikai megoldások, amelyek az intézménynél működő egyéb informatikai rendszerekhez kapcsolódással és / vagy külső adatforrások felhasználásával képesek elemezni és/vagy szimulálni egy vizsgált terület működését, úgy hogy a strukturált és kevésbé strukturált feladatok, a beépített döntési szabályok vizsgálatával, modellek kidolgozásával segítséget nyújtanak a vezetői döntéshez. Képes támogatni olyan komplex problémák megoldását, melyeket hagyományos D-7-001 számítógépes megközelítéssel egyáltalán nem lehetne megoldani, vagy csak sokkal lassabban.


65


D-7-002

A megoldás előre definiált és ad-hoc lekérdezések megtételét is lehetővé teszi.

D-7-003

Egyszerű lekérdezések elkészítésének, illetve testreszabásának támogatása.

D-7-004

Prezentációs felülettel rendelkezés.

D-7-005

Kimutatások felhasználóbarát, illetve vezetői igénynek megfelelő elkészítése.

D-7-006

A rendszer képes terv- és tényadatok összehasonlítására, elemzésére.

D-7-007

Vezetői döntéshozatalt megkönnyítő mutatószámok definiálása.

Modellek segítségével mennyiségi és minőségi analízis készítése. Központi egészségügyi rendszerekhez (pl. kapacitástérkép, amikor az létrejön és D-7-009 működik) való kapcsolódással, más intézmények hasonló lekérdezéseinek összehasonlítása, elemzése. Országos egészségmonitorozási és kapacitástérkép adatbázis közvetlen lekérdezési D-7-010 képessége (amikorra az létrejön) Kontrolling rendszerek A kontrolling rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő gazdasági rendszerekkel, valamint az egészségügyi ellátást, szolgáltatást támogató megoldásokkal integráltan: • segítse a kontrolling, belső ellenőrzési feladatokat ellátó munkatársak vagy az intézmény vezetésének a munkáját, csökkentve a szükséges munkaerő ráfordítást; • lehetővé tegye a releváns munkafolyamatok automatizálását, támogassa azok végrehajtását; • megfelelően előkészítse a vezetői döntéshozatalt a következő időszakokra nézve; • fentiek révén segítse az intézmény működési hatékonyságának növekedését. Különböző adatbázisokból, funkcionális területekről kapott inputok feldolgozásának D-8-001 képessége. A kapott beszámolók exportálása (mentése) tovább-felhasználható formátumokba (pl. D-8-002 xml). D-8-003 Naprakész, folyamatos információk biztosítása. D-7-008

D-8-004

Adatintegrációs, automatizált adatbetöltési funkciókkal rendelkezés.

D-8-005

Kimutatások felhasználóbarát, illetve vezetői igénynek megfelelő elkészítése.

D-8-006

A feldolgozott adatbázisok összehasonlítása (időbeli, terv-tény). Különböző belső intézményi forrásból, funkcionális területről érkező adatok összevetése, elemzése Központi egészségügyi rendszerekhez (pl. kapacitástérkép, amikor az létrejön és működik) való kapcsolódással, más intézmények hasonló adatainak összehasonlítása, elemzése. Változtatási, hatékonyság növelési javaslatok definiálása a vizsgált funkcionális területre vonatkozóan.

D-8-007 D-8-008 D-8-009

4.3.2.3 Munkafolyamatokat támogató rendszerek követelményei Munkafolyamat irányító (workflow) rendszerek A munkafolyamat-irányítási (workflow) rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely alkalmas arra, hogy az intézménynél működő gazdasági rendszerekkel, valamint az egészségügyi ellátást, szolgáltatást közvetlenül támogató megoldásokkal integráltan: • végezze a munkafolyamatok automatizálását; • segítse az intézményen belüli szervezeti egységek munkájának összehangolását. • támogassa, hogy minden folyamat az előírt korlátokon belül, a költségek, a határidők és Összeállította a GYEMSZI szakértői munkacsoportja

66


egyéb paraméterek (pl. a betegellátás színvonalának emelése) betartásával valósuljon meg. • segítse a vezetői áttekintést, a vezetői prioritások érvényesítését, optimalizálja a kockázatkezelést; • fentiek révén közreműködjön az intézmény működési hatékonyságának növelésében. A rendszer tegye lehetővé a szervezeti folyamatok definiálását, támogatását, nyomon D-9-001 követését. D-9-002 Folyamatleltár, folyamattérkép, folyamatábra készítése. Folyamatok, feladatok és erőforrások illesztése, osztályozása. Több funkcionális szervezeti egység és odatartozó alkalmazottak közötti D-9-004 feladatkiosztás, feladatlista kezelése. Az egészségügyi ellátási tevékenységet érintő munkafázisok előre megadott feltételek D-9-005 alapján történő szétosztása az alkalmazottak között. D-9-006 Munkacsoportok, szerepkörök kialakítása. A munkafolyamatok vezérlésének beépített módon való támogatása (delegálás, D-9-007 státuszkövetés). D-9-008 Probléma nyomkövető rendszer (ticketing) használata. Elektronikus iratkezelési rendszerek Az elektronikus iratkezelési rendszer olyan informatikai megoldást jelent, amely segíti az intézmény működési hatékonyságának növekedését úgy, hogy alkalmas: • az intézménynél keletkező, illetve oda bekerülő összes irat minden formájának nyilvántartására, homogén módon történő kezelésére; • az elektronikus tartalmak tárolásával és a papír iratok digitalizálásával egy átfogó tudásbázis kialakítására. D-10-001 Érkeztetés, iktatás, postázás. D-9-003

D-10-002

Minden típusú és formájú irat azonos módon történő kezelése, nyilvántartása.

Elektronikus tárolási forma és digitalizálás biztosítása további egységes tárolással. Papír alapú dokumentumok elektronikus kezelési, tárolási lehetőségének D-10-004 megteremtése. Iratok, ügyek hozzárendelése ügyfelekhez, ellátottakhoz, tranzakciókhoz, szervezeti D-10-005 folyamatokhoz. Iratok és ügyek követése, keresése, elérése a meglévő integrált intézményi informatikai D-10-006 rendszerből. D-10-007 Az iratok teljes életciklusának követése a jogszabályoknak megfelelően. Csoportmunka rendszerek A csoportmunkát támogató rendszer olyan szoftvert, szoftver-komponenst, informatikai megoldást jelent, amely összehangolva és integráltan az egészségügyi ellátást, szolgáltatást közvetlenül támogató megoldásokkal, a munkafolyamat-irányítási rendszerrel (amennyiben az van a szervezetnél), valamint a belső (intranet) és külső intézményi (honlap) portálokkal: • az intézményi belső munkafolyamatokat támogatja; • a szervezeti felépítéséhez illeszkedő, a rendelkezésre álló adatkapcsolatokat felhasználva a lehetőségekhez képest bárhonnan elérhető; • megfelelően kezeli a térbeli és az időbeli elhatárolódást jelentő kapcsolatokat; • fentiek támogatása révén segíti az intézmény működési hatékonyságának növekedését. D-11-001 Webes felhasználói felület támogatása. D-10-003

D-11-002

Biztonságos távoli adatkapcsolat és levelezési lehetőség kiépítése.


67


D-11-003

Webes oldalakon keresztüli kommunikáció lehetővé tétele.

D-11-004

Webes fórumok kialakításának lehetősége.

D-11-005

D-11-007

Szerepkörök kialakításának lehetősége, projektszerű munka támogatásának lehetősége. Feladatok kiosztásának lehetősége, feladatok megjelenítése naptárban, feladatok egymáshoz kapcsolása, feladatok nyomon követése. Csoportos naptárkezelés feladatokkal, mérföldkövekkel, eseményekkel.

D-11-008

Jelenlét-érzékelés.

D-11-009

Osztott információs bázis építésének lehetőségének megteremtése.

D-11-010

Valós idejű csoportmunka megteremtése elektronikus dokumentumokon. Valós idejű üzenetküldés (párbeszéd, csoportos üzenetkezelés) lehetőségének biztosítása. Hangátvitellel történő kommunikáció lehetővé tétele.

D-11-006

D-11-011 D-11-012

4.3.2.4 Intézményi portálok követelményei Intézményi intranet (belső portál) Az intézményi intranet (belső portál) olyan internet technológiát (tipikusan TCP/IP protokoll) használó belső információs hálózatot, illetve a szervezettel kapcsolatos, dinamikusan változtatható tartalommal ellátott lapok összességét jelenti, amelynek tartalmát csak a helyi hálózatra kapcsolt számítógépek érhetik el. Az internetes tartalmakkal ellentétben a hozzáférés csak egy zárt, intézményen belüli felhasználói kör számára adott, az intranet az információk megosztásával, egyéb szolgáltatásokkal számukra nyújt előnyt a hatékony munkavégzés és egészségügyi ellátás érdekében. D-12-001 Intézményi belső kommunikáció támogatása D-12-002

Webes felhasználói felület támogatása.

D-12-003

D-12-005

Dinamikus tartalommenedzsment kialakítása. A közölt információk központi, strukturált elhelyezése, felhasználóbarát felület kialakítása. A szervezeti felépítést tükröző publikációk támogatása.

D-12-006

Kategorizált tartalom elérésének lehetővé tétele.

D-12-004

Közös elektronikus dokumentumtár létrehozása. Minimális tartalmi elem elvárások teljesítése: telefonkönyv, címtár, eseménytár, D-12-008 képgaléria, sajtófigyelés. D-12-009 Dolgozók közötti belső fórum kialakítása. Intézményi külső portál (honlap) Az intézményi külső portál (honlap) olyan a világhálón keresztül elérhető, a szervezettel kapcsolatos, dinamikusan változtatható tartalommal ellátott weblapok összességét jelenti, amelyek egy közös kiinduló pontról érhetőek el, egységes struktúra részét képezik és arculatukban is illeszkednek egymáshoz. A külső intézményi portál kialakításának céljai: • az egészségügyi intézmények honlapon keresztül történő közzétételi kötelezettségeinek törvényileg kötelezően előírt betartása (8.3 fejezet); • az intézmény által közvetíteni kívánt értékek megjelenítése, az intézményi PR támogatása; • az ügyfelek által az interneten keresztül indítható tranzakciók (pl. betegelőjegyzés) számára felület biztosítása. D-12-007


68


D-13-006

Az intézmény jogszabályok által előírt (8.3 fejezet) szervezeti és személyzeti adatainak feltüntetése. Az intézmény jogszabályok által előírt (8.3 fejezet) tevékenységre, működésre vonatkozó adatainak feltüntetése. Az intézmény jogszabályok által előírt (8.3 fejezet) gazdálkodási adatainak feltüntetése. Az intézmény jogszabályok által előírt (8.3 fejezet) közbeszerzési eljárással kapcsolatos adatainak feltüntetése. Az intézmény jogszabályok által előírt (8.3 fejezet) várólistával kapcsolatos adatainak feltüntetése. Online betegelőjegyzés lehetővé tétele (amely intézménynél releváns)

D-13-007

Dinamikus tartalommenedzsment kialakítása.

D-13-008

Elektronikus dokumentum elérési lehetőség megteremtése. Gyakran Ismételt Kérdések (GYIK / FAQ) megjelenítése a portál felületén kérdésválasz formában. A törvényileg előírt alaptevékenységek megjelenítése mellett, azon túl egyéb intézményileg biztosított szolgáltatások részletezése. Valósuljon meg legalább egy idegen nyelven (javasoltan angolul) történő honlap megjelenítés továbbfejleszthető módon. Valósuljon meg az angolon kívül még több idegen nyelven (javasoltan németül is) történő honlap megjelenítés továbbfejleszthető módon.

D-13-001 D-13-002 D-13-003 D-13-004 D-13-005

D-13-009 D-13-010 D-13-011 D-13-012


69


4.4 Intézményközi rendszerszolgáltatások általános és specifikus követelményei Egészségügyi intézményközi információs rendszerek: olyan megfelelő szabványokkal, protokollokkal, interfészekkel és háttérrel felvértezett és létrehozott infokommunikációs rendszerek, amelyek nagyobb számú, különböző feladatkörű egészségügyi intézmény informatikai belső rendszereit egyesítik és kötik össze annak érdekében, hogy az egyes szolgáltatók egymással és a központi rendszerekkel betegadataikat, kórtörténeteiket, vizsgálati eredményeiket, időpontfoglalásaikat stb. egymással elektronikusan megoszthassák, ezáltal hatékonyabb működést és egészségügyi ellátás valósulhasson meg.

A jövőben kiépítendő egészségügyi intézményközi, funkcionálisan integrált információs rendszerekkel kapcsolatosan az alábbi követelménylistát javasoljuk: 4.4.1 Intézményközi rendszerszolgáltatások általános követelményei E-1-001 Magyar szabályozási környezetnek megfelelő működés. E-1-002 A kommunikáció kapcsán az adatvédelem maximális szintű biztosítása. E-1-003 A rendszer rendelkezzen működéshez szükséges strukturált jogosultságkezeléssel. A rendszer képes a felhasználók jogosultságával kapcsolatos ellenőrzések E-1-004 meghatározott időközönként való lefolytatására. E-1-005 A rendszer skálázható, vagyis van lehetőség a felhasználók (userek) számának


70


E-1-006 E-1-007 E-1-008 E-1-009 E-1-010 E-1-011 E-1-012 E-1-013 E-1-014 E-1-015 E-1-016 E-1-017 E-1-018 E-1-019 E-1-020 E-1-021 E-1-022 E-1-023

E-1-024

E-1-025

E-1-026

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


71


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

157

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


72


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

4.5.1.1 Szolgáltatás katalógus menedzsment F-1-001 F-1-002 F-1-003 F-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.

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

4.5.1.2.1 Szolgáltatás szint megállapodás F-2-001 F-2-002 F-2-003 F-2-004 F-2-005 F-2-006 F-2-007

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. Dokumetálni kell a kötelezettségek betartásához kapcsolódó garanciákat, és a mulasztási következményeket.


73


4.5.1.2.2 Az egészségügyben használatos rendszereknél leggyakrabban monitorozandó objektumok

F-3-001

F-3-002

F-3-003

F-3-004

F-3-005

F-3-006

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


74


o o o o o

Telefonos elérhetőségi idő – időtartam E-mail-en történő elérhetőségi idő – igazolt olvasás – időtartam Válaszidő – időtartam Helyreállítási idő – bejelentéstől a helyreállításig hibaszintenként – időtartam Hiba javítás állapotáról értesítési gyakoriság hibaszintenként – időtartam

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

4.5.1.2.4 Szolgáltatásszint mérés és felülvizsgálat F-5-001

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

F-5-002

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

F-5-003

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

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

F-5-005

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

4.5.1.2.5 SLA küszöbérték átlépésének kiértékelési szabályai és következményei F-6-001

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

F-6-002

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

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

F-6-004

Meg kell határozni jogkövetkezményeket

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

F-6-006

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

F-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ő

a

szolgáltatásszint


megsértése

esetén

alkalmazandó

75


4.5.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 F-7-001 kapacitásértékek lekérdezhetőek legyenek A rendszer kapacitásait oly módon kell megszervezni, hogy az elfogadott SLA szintek F-7-002 teljesíthetők legyenek F-7-003 A rendszer kapacitás igényeit, kihasználtságát monitorozni kell F-7-004 A monitorozás során figyelembe kell venni az erőforrásigény időbeli változásait F-7-005 Az adatokat elemezni kell Az elemzések alapján dönteni kell esetleges változáskérelem vagy áthangolás F-7-006 kérdéskörben A változáskezelés döntési folyamataiban a kapacitásmenedzsment adatait figyelembe F-7-007 kell venni A rendelkezésre állás növelésére, az érzékeny alkalmazások biztonságára létrehozott F-7-008 tartalék kapacitásokat még átmeneti időre sem szabad más célra igénybe venni.

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


76


F-8-003

F-8-004

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. A rendelkezésre állási százalékot mindig egy adott időszakra (év, vagy hónap, vagy nap, stb.) vonatkoztatva kell megállapítani 158. Figyelembe kell venni elsősorban az SLA megállapodásokkor, hogy például 99,9%/hó max. 43 perc kiesést jelent havonta 99,9/év max. 8,76 nap kiesést jelent évente, ha egyéb kitétel nem szerepel.

Szerverek: F-8-005 F-8-006 F-8-007 F-8-008 F-8-009 F-8-010 F-8-011 F-8-012 F-8-013 F-8-014 F-8-015

Brand, kiforrott típus választása 159 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ése 160 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 kell 161.

Személyi számítógépek: F-8-016 F-8-017

LAN: F-8-018 F-8-019 F-8-020 F-8-021 F-8-022

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

Aktív eszköz kiválasztásánál megbízhatóságot növelő tényező a megfelelő brand 164, a kiforrott típus választása. Az otthoni felhasználásra szánt eszközök alkalmatlanok az egészségügyben alkalmazott rendszerek kiszolgálására. Aktív eszközök központi menedzselhetősége Az aktív eszközök megfelelő menedzselése, és a forgalmak és a portok folyamatos monitorozása A hálózat passzív elemei egy gyártótól származó garantált minőségűek legyenek Kábelezés esetén az alkalmazásoknak és a környezetnek megfelelő kábelrendszer 165 és kiépítés alkalmazása.

158

Legelfogadottabb a rendelkezésre állás százalékát a számlázási időszakhoz kötni. Ideális eset ha a számla mellékletét képezi az adott időszakra vonatkozó rendelkezésre állás százaléka 159 Ezt legjobban az eszközökhöz igénybe vehető szerviz szolgáltatások, rendelkezésre állás, alkatrész ellátottság és a garanciális feltételek alapján lehet lemérni 160 Pl: firmware frissítések, eszköz meghajtó szoftverek 161 Csak a gyári, szoftveres megoldás elfogadható 162 Ezt legjobban az eszközökhöz igénybe vehető szerviz szolgáltatások, rendelkezésre állás, alkatrész ellátottság és a garanciális feltételek alapján lehet lemérni. Eszköz és operációs rendszer frissítések, BIOS frissítés, távmenedzselhetőség, stb. 163 Pl. az otthoni (home) használatra szánt típusok mellőzése, vékony kliens alkalmazásánk számbavétele 164 Ezen a piacon elérhető az élettartam garancia az eszközökre valamint sok beépített extra szolgáltatás (hálózatfigyelés, vírusvédelem,stb.)


77


F-8-023 F-8-024 F-8-025

Földelé s és villámvédelem 166 WIFI esetén a megfelelő lefedettség és titkosítás biztosítása A hálózat pontos dokumentáltsága

WAN: F-8-026 F-8-027 F-8-028 F-8-029 F-8-030 F-8-031 F-8-032 F-8-033

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

Szoftverek: F-8-034 F-8-035 F-8-036 F-8-037 F-8-038 F-8-039 F-8-040 F-8-041 F-8-042

Megbízhatósági tényező az elterjedt, brand 167 megoldások alkalmazása Biztosítani kell a megfelelő szoftvertámogatást 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 Garanciák előírása Rendszeres szoftverfrissítés és támogatási szolgáltatás megrendelése A szoftverek licencszerű használata A szoftverek erőforrásigényeinek betartása/előírása

Környezet: F-8-043 F-8-044 F-8-045 F-8-046 F-8-047 F-8-048 F-8-049 F-8-050

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 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 Áramingadozási, villám védelem Földelés 168 Az eszközök előírt üzemhőmérsékletének biztosítása

Helyreállíthatóság: F-8-052 F-8-053 F-8-054 F-8-055 F-8-056 F-8-057

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 Archiválási rendszer alkalmazása Kritikus alkalmazások esetén duplikát megoldás alkalmazása

165 A hálózat megfeleőségét mérési jegyzőkönyvvel kell dokumentálni (teljes link mérés+mérési jegyzőkönyves pach kábelek és lengőkábelek) 166 A földelés és villámvédelem jóságát rendszeres időközönként méréssel ellenőrizni kell 167 Jogtiszta, licenszelt és fejlesztett, verziózott 168 A földelés és villámvédelem jóságát rendszeres időközönként méréssel ellenőrizni kell


78


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

4.5.1.5.1 Kockázatelemzés F-9-001 F-9-002 F-9-003 F-9-004 F-9-005 F-9-006 F-9-007 F-9-008 F-9-009 F-9-010 F-9-011 F-9-012 F-9-013 F-9-014 F-9-015 F-9-016 F-9-017 F-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 Meg kell becsülni a kockázatok megvalósulásának valószínűségét Szintekbe kell sorolni és súlyozni a kockázatokat Dönteni kell az egyes kockázatok javításáról a kockázatarányosság figyelembevételével A kockázatjavítási döntés esetén pontos tervet kell készíteni, mely magába foglalja a szükséges tevékenységeket és a várt hatások elemzését. Kockázatjavítás végrehajtása után meg kell határozni a maradvány kockázatokat. Dönteni kell az egyes kockázatok elfogadásáról a kockázatarányosság figyelembe vételével A kockázatokat kezelni kell. Az elfogadott kockázatokhoz kell igazítani a szolgáltatástervezés további tevékenységeit, a szolgáltatás bevezetést és üzemeltetést. A kockázatelemzés folyamatait új fenyegetettség megjelenése esetén ismételni kell A kockázatelemzés folyamatait háromévente ismételni kell

4.5.1.5.2 Biztonsági szabályzat F-10-001 F-10-002 F-10-003 F-10-004 F-10-005 F-10-006

A szervezet vezetésének iránymutatást kell adnia az információbiztonság követelményeivel kapcsolatosan. Ennek lényege olyan szabályzat létrehozása, mely valamennyi alkalmazottra és partnerre vonatkozik Megfogalmazásának feltétele a tartalmi követelmények mellett a közérthetőség Gondoskodni kell a megismertetéséről A biztonsági szabályzatnak minden érintett részére elérhetőnek kell lennie Rendszeres időközönként aktualizálni kell Meg kell határozni a felülvizsgálat felelősét, továbbá a szükséges felülvizsgálatok gyakoriságát, és esetleges eseményhez kötöttségét. (pl. jelentős biztonsági esemény, jelentős szervezeti, technológiai változás stb.)

4.5.1.5.3 Az informatikai biztonság szervezeten belüli menedzsmentje F-11-001 F-11-002

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


79


F-11-003

F-11-004

F-11-005

F-11-006

F-11-007

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

4.5.1.5.4 Informatikai vagyon kezelése

F-12-001

F-12-002

F-12-003

F-12-004

F-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. A szoftverek leltárát oly módon kell vezetni, hogy a kiadás és a visszavételezés mellett a szerzői jogoknak megfelelően a licenc előírásoknak megfelelő használat igazolható legyen. Az informatikai vagyon azonosítása nem minden esetben felel meg a számviteli leltári vagyon fogalmaival. Vagyontárgynak kell tekinteni minden szerzői jog által védett, vagy szellemi értéket képviselő anyagot is, mint rendszerdokumentációt, kezelési kézikönyvet, oktatási anyagot stb. Az informatikai vagyon része az információ is. Az információ nyilvántartásához annak azonosítása, osztályozása, csoportba sorolása szükséges. A csoportképzés alapja lehet az információ típusa, védettségi szintje, a rá vonatkozó elévülési, tárolási előírások (pl. egészségügyi adatok külön szabályai). Az információ osztályozásához hozzá kell kapcsolni a csoportra vonatkozó vagyonkezelési előírásokat a tárolás, másolás, mozgatás, továbbítás, megsemmisítés vonatkozásában. Külön rendelkezni kell a hosszú őrzési idejű adatcsoportok esetleges technológiaváltást követő migrálási megoldásairól. Ide kell érteni az adatkezelő szoftverek váltásának következményeit és a tárolási eljárások váltásának feltételeit.


80


F-12-006

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.

4.5.1.5.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. F-13-001 Biztonsággal összefüggő feladat és felelősségi körök kialakítása Az alkalmazottak vizsgálata a felvételnél. Ellenőrizni kell, hogy a hozzáértés valódi. Szükség esetén ellenőrizni kell a megbízhatóságot. Kiképzetlen új személyzet esetén ki F-13-002 kell dolgozni a betanítás rendjét és felelősségi körét. Folyamatosan kapcsolatot kell tartani a személyzettel. Hirtelen élethelyzet változások, romlások biztonsági problémákat okozhatnak. Az alkalmazottak és közreműködők alkalmazási szerződésben vállalt felelőssége és kötelezettségeinek megfogalmazása, titoktartási nyilatkozat. Az alkalmazási szerződésben kell rögzíteni a biztonsági felelősségeket (többek között pl. a privát mail F-13-003 lehetőségét/tiltását), titoktartási előírásokat. A titoktartásra vonatkozó előírások a szerződésben akár a foglalkoztatás utáni időszakra is vonatkozhatnak. Célszerű szerződésbe foglalni az előírt követelmények megszegésének munkajogi következményeit. F-13-004 A kötelezettségek betartatása F-13-005 A biztonságot megsértők megfelelő szintű számonkérése Alkalmazás/szerződés megszüntetése esetén meg kell határozni a felelősségi körök F-13-006 további sorsát Alkalmazás/szerződés megszüntetése esetén vissza kell szolgáltatni a kezelésben lévő F-13-007 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 hozzáférés jogát. Az F-13-008 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 intézményekben például a F-13-009 központi betegadminisztrációs rendszer esetleges leállása nem befolyásolhatja alapvetően a betegellátást. Minden érintettnek tudnia kell a megfelelő szabályzatok és képzés alapján a tennivalóit ilyen esetben is. Ugyanígy tudnia kell az esemény megszűnését követő tennivalókat is. Meg kell szervezni a biztonsági események jelentésének eljárásrendjét. Nem engedhető meg, hogy egyes esetleg helyben alacsonyabb fokozatúnak ítélt esemény ne F-13-010 kerüljön továbbításra, mert az egyrészről lehetetlenné teszi a válaszlépések kidolgozását másrészről esetlegesen további eseményeket idézhet elő, ami már az alapvető működést, esetleg a betegellátást veszélyezteti.

4.5.1.5.6 Fizikai és környezeti biztonság Területek védelme F-14-001

Azokon a területeken, ahol információt, vagy érintett eszközöket tartanak, biztonsági


81


F-14-002 F-14-003 F-14-004

F-14-005

F-14-006

F-14-007

F-14-008

F-14-009

F-14-010

F-14-011 F-14-012 F-14-013

169

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

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


82


F-14-014

archiválásáról, az eszközről visszaállíthatatlan módon történő törléséről. Vagyontárgyak mozgatása. A vagyontárgyakat csak az adott terület információ biztonságával megbízott felelős ellenjegyzésével lehet áthelyezni, telephelyről kivinni.

4.5.1.5.7 A kommunikáció és az üzemeltetés biztonsága 4.5.1.5.7.1 Üzemeltetési eljárások és felelősségi körök

F-15-001 F-15-002

F-15-003

F-15-004

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

4.5.1.5.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. Biztosítani kell a harmadik fél szolgáltatásnyújtásában a biztonsági előírások F-16-001 betartását. F-16-002 Biztosítani kell a szolgáltatási szintek betartását. F-16-003 A harmadik fél által végzett szolgáltatásokat folyamatosan monitorozni kell. A harmadik fél által végzett szolgáltatások esetében a változáskezelésre, az ahhoz F-16-004 kapcsolódó felelősségi körökre és szabályokra külön megállapodást kell kötni, és azt folyamatosan betartatni. 4.5.1.5.7.3 Rendszertervezés és elfogadás

F-17-001 F-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.

4.5.1.5.7.4 Rosszindulatú szoftverek elleni védelem

F-18-001 F-18-002 F-18-003

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


83


F-18-004

Biztosítani kell a védelem naprakészségét

4.5.1.5.7.5 Biztonsági mentés

F-19-001 F-19-002 F-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..

4.5.1.5.7.6 Hálózat biztonsága

F-20-001 F-20-002

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

4.5.1.5.7.7 Adathordozók biztonsága

F-21-001 F-21-002 F-21-003 F-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ól 171, illetve bármilyen más adatkinyerési eljárástól. Az adathordozók selejtezését oly módon kell elvégezni, hogy a rajtuk lévő adatok visszaállítása ne legyen lehetséges. A dokumentációkat az adatokhoz hasonlóan védeni kell a jogosulatlan hozzáféréstől. 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.

4.5.1.5.7.8 Információcsere

Az egészségügyi rendszerek közötti információcsere már jelenleg is igen nagy szerepet kap mind a központi rendszerek (pl. OEP) felé, mind egymás között (pl. háziorvos-szakellátás, szakellátáslabor közreműködő, szakellátó-szakellátó). Nyilvánvaló törekvés, hogy ezek a kapcsolatok tovább fejlődjenek. Az információcsere biztonsága azonban követelmény. Az információcserében résztvevő valamennyi eszközre, szoftverre ki kell dolgozni a szakmai eljárásokat és biztonsági intézkedéseket. A szabványos eljárásokat kell F-22-001 preferálni, amelyek biztosítják az információ védelmét. Nem engedhetők meg olyan kapcsolatok, melyek során bármelyik fél a szükségesnél magasabb szinten hozzáférhet a másik rendszeréhez, adataihoz. F-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 F-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 veszélyeztetett. F-22-004 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. 4.5.1.5.7.9 Elektronikus szolgáltatások

F-23-001 170 171

Az online tranzakciókat védeni kell lehallgatástól, esetleges jogosulatlan módosítástól,

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


84


F-23-002 F-23-03

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

4.5.1.5.7.10 Monitoring

F-24-001 F-24-002 F-24-003 F-24-004 F-24-005 F-24-006

A felhasználói tevékenységről, kizárásokról, biztonsági eseményekről logot kell vezetni. Külön kiemelendő, hogy a medikai adminisztrációs rendszerekben naplózni kell minden adatmódosítást és adatolvasást is. Ezáltal ellenőrizhetővé téve az esetleges belső jogellenes tevékenységet. Eljárásokat kell kidolgozni a rendszerek használatának figyelésére. Az eltéréseket folyamatosan követni kell, és esetlegesen be kell avatkozni. A naplók védelmét és mentését meg kell szervezni. A naplók őrzési ideje arányos kell hogy legyen a bennük tárolt adatok aktualitásával és a vonatkozó jogi előírásokkal. Például adat jogellenes kiszivárogtatása esetén bizonyítékként szolgál a jogi eljárásban. Naplózni kell a rendszeradminisztrátori tevékenységeket, a rendszerhibákat, az arra adott válaszokat az esetleges anomáliák kiszűrése érdekében A szervezeten belül működő minden rendszer órajelét szinkronizálni kell. Az egyes rendszerek együttműködését az eltérő órajelek veszélyeztetik. Az egészségügyi adminisztrációs rendszereknél az évváltás szinkronizálása kiemelt fontosságú.

4.5.1.5.8 A hozzáférés ellenőrzése F-25-001 A hozzáférést szabályzat szinten kell kezelni. F-25-002 A felhasználók hozzáférés megadását és megvonását regisztrálni kell. 4.5.2 Szolgáltatás bevezetés

4.5.2.1 Szolgáltatási eszköz és konfiguráció menedzsment F-26-001 F-26-002 F-26-003 F-26-004 F-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

4.5.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, hardver 173 és szoftver bővítések vagy csere 174 esetén, új folyamatok belépése, folyamatok módosulása stb. miatt. A változáskezelés célja, hogy a változtatások végrehajtásának sikerességét biztosítsa a káros hatások kizárása, vagy minimalizálása mellett. 172

Kórházi rendszerek, háziorvosi rendszerek, stb. Pl: HDD bővítés, stb. 174 Pl: adatbázis kezelő váltás, kommunikációs könyvtás változtatás, stb. 173


85


F-27-001 F-27-002 F-27-003 F-27-004 F-27-005 F-27-006 F-27-007 F-27-008 F-27-009 F-27-010 F-27-011 F-27-012 F-27-013 F-27-014 F-27-015 F-27-016 F-27-017 F-27-018

Intézményen belüli változtatási folyamatok Egységes változáskezelési rendszert kell működtetni A változáskérelmeket egységesíteni kell és meg kell fogalmazni a kérelmezők jogosultsági rendszerét Ki kell nevezni a változtatási kérelmek elsődleges szűrése jogosult személyzetet Biztosítani kell a változtatások és annak hatásainak felmérését, a rendszerbe integrálhatóság vizsgálatát A változtatások kategorizálása erőforrás alapján A változtatások kategorizálása hatásuk alapján A változtatások prioritásának meghatározása A változtatás jóváhagyása, ütemezése – a változtatást csak az arra kinevezettek hagyhatják jóvá, és csak az ő megrendelésük alapján kezdődhet a létrehozásuk. Ők a felelősek a megfelelő ütemezésről, mely biztosítja a rendszer optimális működését. A változtatást pontosan meg kell tervezni, és létrehozása csak a terv szerint történhet. A változtatást dokumentálni kell. A változtatások tesztelése – a változtatásokat tesztelni csak az éles rendszerrel azonos beállításokkal rendelkező tesztrendszeren lehet. A tesztelés során a funkcionális folyamatteszt mellett tesztelni kell a megbízhatóságot, a biztonságot és a teljesítményigényt is. A változtatások végrehajtásának előkészítése során elvégzendő az oktatás, kezelési anyagok kiadása A változtatások biztonságának előkészítése során gondoskodni kell a mentésekről. A változtatások végrehajtását csak az arra kinevezettek engedélyezhetik, az csak az engedély birtokában hajtható végre. Sürgős változtatási kérelem esetében sem lehet eltekinteni a jóváhagyástól, a minimális teszttől, a mentéstől, a felhasználói értesítéstől, a végrehajtás engedélyezésétől. A dokumentálás, részletes tesztelés, hatáselemzés utólag elvégezendő A változtatások hatásait elemezni kell. Külső szolgáltatóhoz kapcsolódó változtatási folyamatok Abban az esetben, amennyiben a változtatást az intézmény kezdeményezi külső szolgáltató rendszerén, a létrehozás kivételével minden folyamatot be kell tartani Abban az esetben, amennyiben a változtatást külső szolgáltató kezdeményezi rendszerkövetés vagy javítás miatt, a jóváhagyás, tesztelés, végrehajtás előkészítés, mentés, végrehajtás, elemzés az előírás.

4.5.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. Teljes vagy jelentős kiadásnál alkalmazandó Projektmenedzsment (lásd a 1.1 fejezet)

4.5.2.3.1 Konfigurálás F-28-001 F-28-002 F-28-003 F-28-004

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


86


F-28-005 F-28-006 F-28-007

A paraméterezés része a rendszer szótárak létrehozása, panelek létrehozása, a rendszerből kinyerhető dokumentumok paraméterezése is. Szoftver kiadások esetén tesztelni kell a rendelkezésre álló hardver környezetben a szoftver működőképességét. Visszatérési eljárást kell tervezni, mely lehetővé teszi az esetleges sikertelen bevezetés után a korábbi helyzetbe történő visszatérést.

4.5.2.3.2 Kiadás elfogadása F-29-001 F-29-002 F-29-003 F-29-004 F-29-005 F-29-006 F-29-007 F-29-008 F-29-009 F-29-010 F-29-011

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 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 migrációt tesztelni kell A biztonságot 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.

4.5.2.3.3 Telepítés tervezése F-30-001 F-30-002 F-30-003 F-30-004 F-30-005 F-30-006 F-30-007

Ki kell dolgozni a telepítés fázisait Meg kell határozni a telepítés felelőseit, feladataikat Meg kell tervezni a migrálási eljárásrendet Szükség esetén biztosítani kell a telepítés során a zavartalan munkavégzést/betegellátást 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 Biztosítani kell az oktatás tárgyi, helyiség és személyi feltételeit Az oktatás beosztásáról, menetéről, tartalmáról tervet kell készíteni.

4.5.2.3.4 Oktatás F-31-001 F-31-002 F-31-003 F-31-004 F-31-005 F-31-006 F-31-007 F-31-008 F-31-009

Az oktatások során minden kiadásban érintett felhasználót oktatni kell. 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. 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. 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


87


F-31-010 F-31-011

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.

4.5.2.3.5 Telepítés F-32-001 F-32-002 F-32-003 F-32-004 F-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 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. 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.

4.5.2.4 Ismeret menedzsment Az ismeretmenedzsment célja, hogy minden szereplő az adott területen és pillanatban elegendő információval, tudással, készséggel rendelkezzen. F-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 felhasználó F-33-002 rendelkezésére álljanak F-33-003 Biztosítani kell a személyes támogatás rendszerét F-33-004 A szereplő felkészültségét monitorozni kell F-33-005 Biztosítani kell az ismerethiányok megszüntetését F-33-006 Biztosítani kell az ismeretek felfrissítését F-33-007 Biztosítani kell a változásokból adódó ismeretek elsajátítását

4.5.2.5 Szolgáltatás validálás és tesztelés F-34-001

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 F-34-002 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 F-34-003 tervezés során lefektetett elképzeléseknek. 4.5.3 Szolgáltatás üzemeltetés

4.5.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. 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 normális F-35-001 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 F-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ő interfészek F-35-003 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, F-35-004 hőmérsékleti jelzések, táblatér jelzések, tápellátási jelzések, újraindítások. Összeállította a GYEMSZI szakértői munkacsoportja

88


F-35-005 F-35-006 F-35-007 F-35-008 F-35-009 F-35-010 F-35-011 F-35-012 F-35-013

Operációs rendszerek eseményeinek mérései: Meghibásodási jelzések, frissítések jelzései Védelmi rendszerek eseményeinek mérései: Támadások jelzései, behatolási kísérletek jelzései, frissítések jelzései Alkalmazói rendszerek eseményeinek mérései: Írás, módosítás, olvasás esetén: ki, mikor, mit. Hibák jelzései, frissítések jelzései Rendszerek kapcsolatainak, mérései: Adatküldés, adatfogadás honnan hova, mikor, mit. Hibák jelzései. Külső kommunikáció, mail rendszerek mérései: ki, mikor, mit, honnan hová. Hibák jelzései. Az eseményeket pl. naplókban úgy kell tárolni, hogy a tárolási idő megfeleljen a vonatkozó jogszabályoknak. Például az egészségügyi adminisztrációs rendszer hozzáférés naplóit az egészségügyi adatvédelmi törvény szerint. Az eseményeket úgy kell tárolni, hogy bármilyen elemzésre visszamenőleg is alkalmasak legyenek. Pl. jogosulatlan hozzáférés kimutatása bizonyító erejű módon. Meg kell határozni az események feldolgozásának algoritmusát, és a kimeneti szinteket. Kimenetek lehetnek: esemény rekord, incidens rekord, probléma rekord, automatikus válasz, riasztás

4.5.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. F-36-001 Definiálni kell az adott rendszerre az incidens fogalmát. A nem saját fejlesztésű rendszerek/rendszerelemek esetén szerződés műszaki mellékletében részletesen elő kell írni, hogy az adott rendszer mely funkcionalitással, F-36-002 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 kell F-36-003 fogadtatni az incidensek besorolási rendszerét. Az incidensek besorolási rendszerének kialakításakor figyelembe kell venni az incidens hatását a rendszerre, az incidens kiterjedtségét, az érintett rendszerek F-36-004 prioritását, az incidens hatását az SLA-ra. Például egészségügyi intézményeknél egy HIS rendszert alapszolgáltatásaiban érintő incidens prioritása és besorolása más, mint a gazdasági rendszert hasonló módon érintő incidens. F-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: észlelés, F-36-006 bejelentés, kezdet, befejezés, helyreállítás F-36-007 A hibaelhárítási szakaszokhoz meg kell határozni a felelősöket és eljárásrendet. Az incidens menedzsment részére bemeneti interfészt kell biztosítani az F-36-008 eseménymenedzsment felől. Az incidens menedzsmentnek kimeneti interfészt kell biztosítani a F-36-009 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, F-36-010 stb.) szerint az incidens lezárást követő utóélete követhető legyen.


89


4.5.3.2.1 Ügyfélszolgálat F-37-001 F-37-002 F-37-003 F-37-004 F-37-005 F-37-006 F-37-007 F-37-008 F-37-009 F-37-010 F-37-011 F-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

4.5.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 F-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ő incidensek F-38-002 szűrésére, statisztikájára, behatárolására F-38-003 Az incidenseket kategorizálni kell előfordulási gyakoriságuk, hatásuk szerint F-38-004 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 F-38-005 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, F-38-006 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 F-38-007 információt kell szolgáltatni.

4.5.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.) F-39-001 A kéréseket egységesített formába és nyilvántartásba kell szervezni F-39-002 Ki kell alakítani a kérések elbírálásának eljárásrendjét F-39-003 Ki kell jelölni az elbíráló, végrehajtó szereplőket F-39-004 Meg kell határozni a végrehajtási sorrendet alkotó prioritási rendet, és a hozzá tartozó Összeállította a GYEMSZI szakértői munkacsoportja

90


F-39-005

határidőket A teljesített kérésekről meg kell szervezni az értesítési rendet.

4.5.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. Személyazonosság megállapítása – név + egyéb azonosító pl.: születési dátum, F-40-001 törzsszám, orvoskód stb. Személyazonosság ellenőrzése minimum kettős azonosítással pl.: felhasználó név F-40-002 +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ő F-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 kötelező F-40-004 módon F-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 szolgáltatónál például jellemző F-40-006 szerepcsoportok: orvos, ápoló/asszisztens, betegirányító, hr-es, pénzügyi, könyvelő, rendszergazda. Jellemző egyedi szerepek orvosvezető, gazdasági vezető, adatvédelmi felelős. F-40-007 Lehetőséget kell adni, hogy egy személyhez több szerep is kapcsolható legyen Vizsgálni kell az esetleges szerepkonfliktust, azaz ha egy személy több szerepe F-40-008 egymásnak ellentmondó F-40-009 A szerepekhez jogosultságokat kell rendelni A jogosultságoknak ki kell szolgálni a szerephez kapcsolódó minden tevékenységet a F-40-010 teljes/minden rendszerben. A jogosultságoknak meg kell felelnie a szervezet belső szabályainak. Például a F-40-011 rendszergazda nem férhet hozzá védett adatokhoz. A jogosultságoknak meg kell felelni az érvényes jogszabályoknak. Egészségügyi F-40-012 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 F-40-013 tárolni. A felhasználók jogosultsági életciklusának idősorosan követhetőnek és megőrzöttnek F-40-014 kell lennie. F-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 kap, és F-40-016 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 F-40-017 alapján orvos csoportba kerül. A rendszert monitorozni kell, hogy az egyes jogosultságok folyamatosan megfelelnek a F-40-018 szerepköröknek. Meg kell határozni a jogosultsági életciklus felelőseit: igénylés, igény ellenőrzés, F-40-019 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 F-40-020 megszüntetését.

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


91


F-41-001 F-41-002 F-41-003 F-41-004

Ki kell dolgozni a mérési indikátor rendszert Az indikátorokat monitorozni kell 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 tervezés felé a további fejlesztésekre

4.5.3.7 Üzemeltetési szerződésmenedzsment F-42-001 F-42-001 F-42-002 F-42-003 F-42-004 F-42-005 F-42-006 F-42-007 F-42-008 F-42-009 F-42-010 F-42-011 F-42-012 F-42-013

A szerződéseknek illeszkednie kell az egységes üzemeltetési rendszerbe Üzemeltetési feladatok kiszervezése során figyelembe kell venni az érvényes jogi rendelkezéseket (pl. adatfeldolgozást szabályai) Ü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ésedelmes- hibá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 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


92

Pályázati és megvalósítási követelmények

5 A fejlesztési pályázat és a megvalósítási projekt követelményei, minősítése Ebben a fejezetben azokat a követelményeket foglaltuk össze, amelyek 9 egy pályázat sikeres elkészítéséhez, illetve 9 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 9 alternatívaelemzés 9 prioritások meghatározása 9 a jelenlegi helyzet pontos felmérése 9 megvalósíthatósági vizsgálatok 9 pénzügyi-gazdasági elemzések 9 fenntarthatósági elemzések 9 környezeti elemzések 9 a fejlesztés leírása és pontos definiálása az intézmény menedzsmentje és felhasználói számára is 9 a megfelelő szakemberek (informatikai, gazdasági, szakterületi stb.) rendelkezésre állása 9 az intézmény informatikai kultúrája Szeretnénk ebben a részben még rávilágítani az ún. Megvalósíthatósági tanulmány fontosságára, szükségességére. Ezen tanulmány alatt sokan sokféle tartalmat és szempontok elemzését értik, a fejezet szempontrendszerében ezeket kibontva szerepeltetjük. A megvalósíthatósági tanulmány elkészítésének célja, hogy megfelelő információt nyújtson a döntéshozók számára ahhoz, hogy azok megalapozott döntést tudjanak hozni a finanszírozásra és a megvalósítandó projekt elfogadásáról, módosításáról, illetve elvetéséről.


93


A megvalósíthatósági tanulmány feladata a végrehajtandó fejlesztés megalapozottságának és életképességének vizsgálata. A tanulmány elkészítésének eredménye a javasolt projekt relevanciájának, megvalósíthatóságának és fenntarthatóságának értékelése. A második részben a fejlesztést megvalósító beszállító felkészültségére vonatkozóan fogalmaztunk meg követelményeket. A nagyobb fejlesztések legtöbbször szigorú közbeszerzési szabályok keretei között zajlanak, de nem árt már előre felkészülnie az intézménynek, hogy milyen szempontok szerint minősítsen, illetve válasszon beszállítót. Noha az ár döntő lehet, de a különböző ajánlatok „megfelelőségének” (azaz az intézmény céljaihoz és prioritásaihoz való minél nagyobb fokú illeszkedésnek) elbírálása legalább ilyen lényeges. Számos esetben az ajánlattevők „ajánlanak valamit”, aztán majd – utólag, plusz pénzért – hozzáfejlesztik az intézmény igényeihez. Többek között ezt a beszállítói gyakorlatot megelőzendő állítottuk össze a követelményrendszerünk ezen pontjait. A teljesség igénye nélkül a legfontosabb ilyen szempontok: 9 a beszállító szakembereinek (menedzsment, kiemelt szakértők, fejlesztők stb.) felkészültsége 9 a beszállító, mint szervezet felkészültsége (szerepkörök, kompetenciák) 9 a beszállító tervezett (és rendelkezésre álló) erőforrásai 9 a fejlesztés időütemezése 9 az ajánlathoz való illeszkedés kérdései 9 a javasolt megoldás részletezettsége (funkcionális, technológiai, pénzügyi stb.) 9 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 9 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. 9 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ó) 9 a projektindítás (projektalapítás) 9 a megvalósítás 9 az előállított termék (a fejlesztett rendszer) megfelelősége 9 és a megvalósítást követő időszak (garancia) kérdéseivel is foglalkozunk. A fejlesztés előkészítése kapcsán külön hangsúlyozzuk a BPM és BPR (busines process modelling és reengineering) szükségességét. Ezeknek az elmaradása okozza az informatikai fejlesztések bukásának talán legnagyobb részét. Egy informatikai fejlesztés előkészítéséhez jó Összeállította a GYEMSZI szakértői munkacsoportja

94


alapot ad az intézmény folyamatainak, működésének feltérképezése, legtöbbször valamilyen célszoftverrel történő – informatikailag feldolgozható, bementként használható - grafikus megjelenítése, modellezése (BPM). A folyamatok felmérése döntheti el azt a kérdést, hogy részben vagy teljesen újra kell-e gondolni az intézmény – fejlesztéssel kapcsolatos – működését, azaz teljes „mérnöki újratervezés (BPR) vagy csak a jelenlegi folyamatok elemzésén alapuló részleges és fokozatos javítás (Business Process Improvement - BPI) szükséges.

A kedvezőtlen feltételekkel megkötött szerződések kiszolgáltatott helyzetbe hozhatják az intézményeket a szerződéses partnerekkel szemben. Ez egyrészt a vállalkozók monopolhelyzetbe kerülésével gazdasági hátrányt okozhat az intézményeknek. Másrészt akadályozhatja a szervezetek technológia váltását, vagy birtokba kerülését a saját rendszereik vonatkozásában. Ezen helyzetek elkerülése érdekében a fejezet későbbi részében részletezettszempontok beépítése szükséges a szoftvervásárlással és a rendszerfejlesztéssel kapcsolatos szerződésekbe. A szerződésekbe épített elvárásoknak összhangban kell lennie a szerzői jogról szóló törvény szerződéskötéskor érvényes 175 állapotával.

5.1 Az intézmény felkészültségének követelményei

5.1.1 A fejlesztés elhelyezése az intézmény működésében G-1-001

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

G-1-002

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

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

G-1-004

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

G-1-005

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

G-1-006

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

G-1-007

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)

G-1-008

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

G-1-009

Az egyes fejlesztési alternatívákat tanulmányok/állásfoglalások rendelkezésre állnak informatikai stb.

G-1-010

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.

G-1-011

Előzetes pénzügyi elemzés készült (költségvetés megalapozottságának és realitásának

175

megalapozó/megerősítő (szakmai, menedzsment,

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


95


vizsgálata, a projekt pénzügyi érzékenység vizsgálata, pénzügyi-gazdasági megtérülés kiszámítása stb.) G-1-012

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

G-1-013

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

G-1-014

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

G-1-015

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

G-1-016

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

G-1-017

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.

G-1-018

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

G-1-019

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

G-1-020

Készült logikai rendszerspecifikáció.

G-1-021

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

G-1-022

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

G-1-023

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

G-1-024

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.

G-1-025

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.

G-1-026

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

G-1-027

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

G-1-028

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

G-1-029

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.

G-1-030

A fejlesztés kedvezményezett oldali irányításához szükséges vezető szakemberek (belső menedzsment, IT oldali projektvezető stb.) kiválasztásra kerültek, és felmentést


96


kaptak a fejlesztés idejére egyéb tevékenységeik végzése alól. G-1-031

A fejlesztés kedvezményezett oldali irányításához szükséges kulcsszakemberek (kulcsfelhasználók, a fejlesztésben kiemelt területek képviselői stb.) kiválasztásra kerültek, és felmentést vagy könnyítést kaptak a fejlesztés idejére egyéb tevékenységeik végzése alól.

G-1-032

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

G-1-033

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

G-1-034

Az intézmény/kedvezményezett szakemberei hatékony fejlesztés/fizikai rendszertervezés szakaszában is.

segítségre

képesek

a

5.1.2 Intézményi követelmények a fejlesztés előkészítésére G-2-001

A fejlesztés kedvezményezettje rendelkezik informatikailag képzett felhasználókkal.

G-2-002

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

G-2-003

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

G-2-004

A fejlesztés koncepciója, főbb elemei ismertek, a kiírónál/kedvezményezettnél előkészített a befogadása emberi tényezők tekintetében.

G-2-005

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

G-2-006

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

G-2-007

Az intézmény orvosai (szakemberei) használnak IKT megoldásokat más orvossal (egymás között) való elektronikus információcserére

G-2-008

Az intézmény elérhető elektronikus úton a betegek, páciensek, ügyfelek számára (elektronikus ügyintézés)

G-2-009

Az intézmény rendelkezik rendszeresen frissített honlappal (egészségügyi szolgáltatás lista, ki-kicsoda, elérhetőségek, intézményi profil, külső kapcsolatok lehetősége)

G-2-010

Az intézmény rendelkezik intranettel, ami naprakész információkat ad a saját felhasználóknak (intézményi belső információkkal, menedzsment információkkal)

G-2-011

A beszállító üzleti szereplők és az egészségügyi kapcsolatrendszere alapvetően IKT megoldásokon alapul

G-2-012

A projektet végrehajtó intézmény szervezeti, pénzügyi és humán erőforrás-oldali felkészültségének felmérése megtörtént.

G-2-013

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

G-2-014

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

G-2-015

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

G-2-016

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

G-2-017

A

fejlesztések,

alkalmazások


támogatják

az

alapvető

szolgáltató/intézmény

orvosi/egészségügyi

97


tevékenységeket. G-2-018

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

G-2-019

A kórházi/intézményi informatika intézeti és osztályos szinten is felelős koordinátor kinevezése mellett van kialakítva és működtetve.

G-2-020

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

G-2-021

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

G-2-022

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

G-2-023

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

G-2-024

Az informatikai tevékenységét.

G-2-025

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

G-2-026

Az információs rendszer adataihoz való hozzáférések kérdései tisztázottak, szabályozottak.

G-2-027

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)

rendszerek

felhasználóbarát

módon

segítik

a

felhasználók

5.2 A beszállító felkészültségének és ajánlatának követelményei 5.2.1 Beszállítói követelmények G-3-001 G-3-002 G-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ég ellenőrzésbe bevonni kívánt szakemberei (szervezetei), illetőleg vezetői képzettsége és összetétele megfelelő.

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

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

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

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


98


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

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

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

G-3-011

A beszállító megfelel a műszaki-technikai alkalmasságára, felszereltségére a fejlesztésbe bevonni kívánt szakemberei képzettségére (67.§.) vonatkozó közbeszerzési előírásoknak, és benyújtotta az ott előírt igazolásokat, dokumentumokat.

G-3-012

A beszállító referenciái (a fejlesztés nagyságrendjével összhangban legalább az előző 13 évre visszamenőleg) megfelelőek.

G-3-013

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

G-3-014

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

G-3-015

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

G-3-016

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

G-3-017

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

G-3-018

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.

G-3-019

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

5.2.2

Az ajánlott megoldás illeszkedése a kiíráshoz

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

G-4-002

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

G-4-003

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

G-4-004

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.

G-4-005

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.

G-4-006

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


99


G-4-007

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

G-4-008

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.

G-4-009

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.

G-4-010

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

G-4-011

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.

G-4-012

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.

G-4-013

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.

G-4-014

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.

G-4-015

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

G-4-016

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

G-4-017

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.

G-4-018

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

G-4-019

A műszaki leírás megfelelő részletességgel mutatja be a hardver architektúra rendszerét és elemeit, ezek elhelyezkedését.

G-4-020

A műszaki leírás megfelelő részletességgel mutatja be a hardver architektúrán belül a legfontosabb erőforrások (szerverek, központi eszközök) kialakítását, teljesítményét, paramétereit.

G-4-021

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.

G-4-022

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

G-4-023

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.

G-4-024

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.


100


G-4-025

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.

G-4-026

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.

G-4-027

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

G-4-028

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

G-4-029

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.

G-4-030

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

G-4-031

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)

G-4-032

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

G-4-033

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

G-4-034

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


101


5.3 A fejlesztés előkészítésének, megvalósításának és eredményének, követésének követelményei

5.3.1

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

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

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

G-5-003

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

G-5-004

Készült logikai keretmátrix.

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

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

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

G-5-008

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

G-5-009

Az előfeltételek, feltételezések és kockázatok elemzése megtörtént (kockázatkezelési terv).

G-5-010

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

G-5-011

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.

G-5-012 G-5-013

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

G-5-014

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

G-5-015

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

G-5-016

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.

G-5-017

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

G-5-018

A feladatok kivitelezőinek (kompetenciák és felelősségek mátrixa) meghatározása megtörtént.

G-5-018-1

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

G-5-018-2

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

G5-019

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


102


G-5-020

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)

G-5-021

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

G-5-022

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

G-5-023

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

G-5-024

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

G-5-025

A definiált indikátorok minőségileg alkalmasak (SMART kritériumrendszer - Specific, Measurable, Available, Relevant és Timebound) a számszerű mérésre.

G-5-026

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

G-5-027

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

5.3.2 A Projekt Alapító Dokumentum követelményei G-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)

G-6-002

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

G-6-003

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

G-6-004

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

G-6-005

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

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

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

G-6-008

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

G-6-009

A projektmenedzser(ek) személye (szakmai és emberi képességek) megfelelő(ek).

G-6-010

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

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

G-6-012

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

G-6-013

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

G-6-014

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

G-6-015

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

G-6-016

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

G-6-017

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


103


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

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

G-6-020

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

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

G-6-022

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

G-6-023

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

G-6-024

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

G-6-025

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

5.3.3 A fejlesztéssel kapcsolatos szerződés(háló) kialakításának követelményei G-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.

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

G-7-003

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

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

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

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

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

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

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

G-7-010

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

G-7-011

A beszállítói szerződés egyértelműen szabályozza, hogy a beszállító jogosult-e, és ha igen, milyen feltételekkel többletmunkája/többletkiadása ellenértékéhez jutni.

G-7-012

A beszállítói szerződés egyértelműen szabályozza, hogy a beszállító jogosult-e, és ha igen, milyen feltételekkel árat emelni (infláció, előre nem látott körülmények, vis major stb.)

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


104


szakmai kapcsolattartó, aki jogosult a beszállító felé szakmai kérdésekben döntést hozni. G-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.

G-7-015

A beszállítói szerződés egyértelműen szabályozza az eredménytermék (szállítandó eszközök, fejlesztendő alkalmazások, szolgáltatások) tartalmát, paramétereit.

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

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

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

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

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

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

G-7-022

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

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

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

G-7-025

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

5.3.4 Szoftverszerződésekkel kapcsolatos elvárások G-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.

G-8-002

A szerződéseknek minden esetben rendelkezniük kell a szerzői, illetve felhasználási jogokról. Egyedi célra történő szoftverfejlesztésre illetve továbbfejlesztésre vonatkozó szerződések esetén - összhangban a szerződéskötéskor érvényes szerzői jogi törvénnyel 176 - az alábbiak szerződésben történő rögzítése elvárt:

G-8-002-1

176

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.

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


105


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

G-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á177.

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

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

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

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

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

G-8-002-9

o A szoftverhez kapcsolódó adatbázisban szereplő adatvagyon az intézmény tulajdona. Az adatbázishoz való hozzáférést, további feldolgozást, elemzést, értékelést a beszállító a szerződés keretében maradéktalanul biztosítani köteles.

G-8-00210

o A szerződésekben szükséges az adatmentés, adat tárolás, archiválás részletes szabályozása.

5.3.5 A fejlesztés megvalósítása követésének követelményei G-9-001

A mérföldkövek (az időütemezés szerinti) időbeli megvalósításának követése biztosított-e (tűrés, módosítások, csúszások, a csúszások oka és hatása)

177

Harmadik személy ilyen korlátozó vagy akadályozó igénnyel való fellépése esetén a vállalkozó kötelessége közvetlenül fellépni a megrendelő jogos érdekei védelmében.


106


G-9-002

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

G-9-003

A megfelelő ellenőrzési struktúra és hierarchia (ellenőrzési felelősségek, alá- és fölérendeltségek) kialakításra került és működtetik, az ellenőrzések adminisztrációja biztosított.

G-9-004

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.

G-9-005

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.

G-9-006

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

G-9-007

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

G-9-008

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

G-9-009

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

G-9-010

Minőségi nyilvántartás (minőségi szemlék események) rendelkezésre áll és aktualizált.

G-9-011

A fejlesztés termékeinek minőségbiztosítási rendszere működik és megfelelően dokumentált.

jegyzőkönyvei,

váratlan

szakmai

5.3.6 A fejlesztés eredményének követelményei G-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.

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

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

G-10-004

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

G-10-005

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

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

G-10-007

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

G-10-008

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

G-10-009

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

G-10-010

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

G-10-011

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


107


G-10-012

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


108


6 A követelmények alapján folytatott minősítés módszertana, folyamata és szervezete 6.1 A minősítés célkitűzése, alanyai Az alapvető elvárás az, hogy az ágazatban olyan információs rendszer-együttes épüljön ki, amely az alapfeladatának (a gyógyító-megelőző-rehabilitáló tevékenység támogatása) informatikai eszközökkel való kiszolgálásán túl: 9 9 9 9

szabványos (korlátozottan csereszabatos), biztonságos, együttműködésre képes elemekből álljon, amelyek technológiai megoldásukban felülről nyitott (fejleszthető) megoldásokat tartalmazzanak, 9 az alkalmazók számára arányos fenntartási és üzemeltetési költségeket generáljanak, 9 kezelésüket az alkalmazó intézmény átlagos felhasználói felkészültség mellett el lehet sajátítani.

A minősítő eljárás tehát a fenti kívánalmaknak csak úgy képes megfelelni, ha azoknak egyértelmű, világos követelmények felelnek meg. A minősítő eljárás 9 információs rendszert, 9 fejlesztési projekteket és 9 szervezetet minősít. Ezeket egyszóval a minősítés alanyainak nevezzük. Feladatunk a korábbiakban megfogalmazott kritériumrendszer alkalmazásának módszerének kidolgozása, amely alkalmazás a minősítendő alanyok (az egészségügyi információs rendszerek, az információs rendszerfejlesztési projektek, valamint a fejlesztést végző egészségügyi intézmények) minőségének, alkalmasságának és megfelelőségének vizsgálati eljárását határozza meg. A minősítendő alanyok folyamatosan változnak. Ezért a minősítési eljárás az adott pillanatban vizsgálja a megfelelősséget. Nemcsak az alanyok változhatnak az időben, hanem a minősítés szempontrendszere, a követelmények is. Tehát időről-időre ki kell adni az újabb jegyzéket, illetve a változás-jegyzéket, valamint az alanyok minősítését is – a szükséges időközönként – meg kell újítani. Mi is várunk el a minősítéstől? Mi legyen az eljárás kimeneti pontja? Milyen eredménytermék álljon elő az eljárás végén? Végezetül: milyen hatása legyen a minősítésnek az alanyokra, az alkalmazó intézményre vonatkozóan, és az informatikai környezet alakításáért felelős kormányzati szervekre vonatkozóan? Vegyük egyenként a fentieket az alanyok szerint:

6.2 Információs rendszerek 6.2.1 Elvárás a minősítő eljárással szemben Az információs rendszer megfelelésének vizsgálata: 9 a korábbi fejezetekben meghatározott rendszerkövetelmények egyértelmű mérési eljárás szerinti ellenőrzésével, 9 az ellenőrzés alapján a minősítési dokumentáció reprodukálható előállítását, valamint Összeállította a GYEMSZI szakértői munkacsoportja

109


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


110


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


111


Az információs rendszerfejlesztő egészségügyi szervezet a fejlesztést felügyelő kormányzati szerv (pl. NFÜ) felé – mint a projekt minőségbiztosításának eredményét – felhasználhatja, és azt a kormányzati szerv köteles figyelembe venni. A nem megfelelő minősítési végeredmény esetén az eredmény alapján a minősítő által meghatározott – a döntőfórum döntésével kiegészített – tevékenységek és hiánypótlások elvégzésére a meghatározott ideig a fejlesztési projekt szervezete kötelezhető, amelyet a meghatározott idő eltelte után köteles jelenteni az ágazati informatikáért felelős szervnek. A megkövetelt tevékenységek nem teljesítéséért a kötelezett intézmény egyszemélyi felelős vezetője felel. Ekkor a fejlesztési projekt megállítható. Szankciók a nem megfelelő rendszer alkalmazása esetén: o fegyelmi felelősségre vonás o juttatás megvonás o pénzbüntetés o elbocsátás

6.4 Információs rendszerfejlesztési projektet vezető egészségügyi intézmény 6.4.1 Elvárás a minősítő eljárással szemben Az intézményi feladatok informatikai támogatását biztosító rendszer fejlesztéséhez tartozó felkészültség biztosítása, amely a következőket ellenőrzi: 9 9 9 9

az intézményi szakmai és szervezeti előkészítés megfelelőségét a projekttel összefüggő szervezetfejlesztést a fenntarthatóság intézményi garanciáit az üzemeltetés megfelelő szervezeti vagy szerződéses kialakítását.

6.4.2 Az eljárás kimeneti pontja Egy szervezet minősítése a fejlesztési projekt (i) előkészítése, (ii) a szükséges szervezet fejlesztése, (iii) a lebonyolítása és a (iv) fejlesztett rendszer üzemeltetése szempontjából történik. A kimeneti pont a két előző objektum esetén leírtak ötvözete: hiszen valamennyi (iiv) fázis egy-egy dokumentumot eredményez, viszont a fejlesztési projekt egy-egy meghatározott stádiumában kerül végrehajtásra, vagyis a folyamatszerűség is megjelenik benne. 6.4.3 A minősítés eredményterméke A minősítési eljárás eredményterméke az a dokumentum, amely a vizsgálat(ok) részletes eredményét tartalmazza a következők szerint: a vizsgálat időpontja, a vizsgált alany rövid leírása, a vizsgálat célja, a vizsgált kötelező követelmények táblázatos felsorolása, eredménye (megjegyzéssel), a vizsgált, és meglévő ajánlott követelmények táblázatos felsorolása, eredménye (megjegyzéssel), a vizsgálat értékelése, javaslattétel a hiányosságok pótlására. A minősítés eredménye megfelelő ha: A minősítés eredményterméke(i) által megfogalmazott szervezetfejlesztések végrehajtásra kerültek. A végrehajtást vállaló nyilatkozat nem elegendő a megfelelőséghez!


112


Amennyiben a minősítés eredménye nem megfelelő, az eredménytermék a vizsgált intézmény véleményeltérésével az ágazati döntőfórum elé kerül, amely grémium dönt a kérdésben. A döntőfórum döntése mind a minősítő intézményre, mind pedig a minősítettre kötelező. Az eredménytermék az ágazati informatikáért felelős szervnek is megküldésre kerül. 6.4.4 A minősítés eredményének hatása a vizsgált objektumra, intézményre és ágazati szervekre Az eredménytermék az intézmény által végrehajtandó szervezetfejlesztések indokaként, és a későbbi ellenőrzéseknél is felhasználható, amelyetket az ellenőrző szerv köteles figyelembe venni. A nem megfelelő minősítési végeredmény esetén az eredmény alapján a minősítő által meghatározott – a döntőfórum döntésével kiegészített – tevékenységek és hiánypótlások elvégzésére a szervezet kötelezhető, hogy meghatározott ideig azt elvégezze - amelyről köteles jelenteni az ágazati informatikáért felelős szervnek. A megkövetelt tevékenységek nem teljesítéséért a kötelezett intézmény egyszemélyi felelős vezetője felel. Ekkor az intézmény számára – saját költségén – szervezetfejlesztési tanácsadó rendelhető ki ágazati döntési felhatalmazással. Szankciók a nem megfelelő rendszer alkalmazása esetén: o fegyelmi felelősségre vonás o juttatás megvonás o pénzbüntetés o elbocsátás

6.5 A minősítő eljárás módszertana 6.5.1 A minősítő eljárás során alkalmazott módszer Az információs rendszerek infrastruktúrájának minősítésekor annak mérete alapvetően befolyásolja a vele szemben elvárt kritériumok sorát. Ezért szükséges a minősítés eljárásának meghatározása előtt ezt a méretbeli-komplexitásbeli elkülönítést – besorolást – megtenni, hogy felállíthassunk egy működőképes minősítési rendszert. Az egészségügyi információs infrastruktúra besorolását annak függvényében adjuk meg, hogy egy időben hány munkahelyet szolgálnak ki. Ezt a besorolást azért tartjuk fontosnak, mert más és más követelményeknek kell megfelelnie egy két munkahelyes háziorvosi praxisrendszernek, egy 10-egynéhány munkahelyes praxisközösséget kiszolgáló, vagy kis rendelőintézetben működő információs rendszernek, és más szintű követelményeknek kell megfelelnie egy százas nagyságrendű kórházi rendszernek, vagy egy országos hálózatba szervezett rendszernek. Általában megállapítható, hogy a rendszerek biztonsági, rendelkezésre állási, szolgáltatási komplexitási fokozatai is követik a fenti méretbeli kategóriákat. Így a következő minősítési kategóriákat állítunk fel: 9 kevesebb, mint 3 munkahelyes rendszerek – személyes rendszerek = A típus 9 3 ÷ néhány 10 munkahelyes – csoport rendszerek = B típus 9 néhány száz, földrajzilag közeli elhelyezésű munkahelyeket kiszolgáló – nagyvállalati méretű rendszerek = C típus Összeállította a GYEMSZI szakértői munkacsoportja

113


9 földrajzilag országos kiterjedésű több száz munkahelyet kiszolgáló – országos rendszerek = D típus 9 Weben keresztül több százas (ezres) nagyságrendű felhasználót kiszolgáló – felhőszolgáltató rendszerek = E típus A rendszerkritériumok táblázatában ezért öt oszlopot rendelünk minden egyes követelmény sorába. Az oszlopokba három jel kerülhet: K-Kötelező kritérium; A-Ajánlott kritérium; N nem alkalmazandó kritérium. Így a korábban megfogalmazott kritérium-táblázat a következőképpen egészül ki:

Ssz.

A-1-001

A-1-002

A-1-003

A-1-004

A-1-005

Követelmény A megfelelő fejlesztési technológia kiválasztásával időtálló 178, fenntartható rendszereket kell fejleszteni. Robosztus architektúra: Az alkalmazások architektúráját úgy kell megtervezni és megvalósítani, hogy az képes legyen a megcélzott (ágazati vagy intézeti) számú felhasználó biztonságos és gyors kiszolgálására. (Az elvárt gyorsaság megítélésénél az adott funkciók specifikációjánál megadott érték az irányadó). A megfelelőséget számítással kell alátámasztani és teszteléssel ellenőrizni. Architektúra: a megvalósításra kerülő alkalmazás kettő (kliensszerver), vagy több rétegű (multitiered) architektúrára 179 épüljön. Méretezhetőség: Az alkalmazások architektúrájának (hardver és szoftver) biztosítania kell az intézmény vagy régióhoz tartozó teljes intézményrendszernek, mint felhasználó számhoz szükséges méretre való felbővítés lehetőségét. A megfelelőséget számítással kell alátámasztani. Hibatűrő, redundáns kialakítás: Mind egyedi eszköz telepítése esetén, mind szolgáltató központoknál olyan mértékben

Szállító /intézm ény

Típus A

B

C

D

E

K

K

K

K

K

A

K

K

K

K

N

N

A

K

K

A

A

K

K

K

N

A

K

K

N

Megjegy zés

178

Az időtállóságnál figyelembe kell venni a 1997. évi XLVII. Törvény‐ben foglalt adatmegőrzési időtartamokat. Nyilatkozat és megvalósítási leírás szükséges az időtállóság megvalósításáról. 179 Pl. three‐tier architektúra ‐ kliensl, alkalmazás szerver (application server), adatbázis szerver (database server)


114


Ssz.

A-1-006

A-1-007

A-1-008

Követelmény

Szállító /intézm ény

szükséges hibatűrő, redundáns infrastruktúrát kialakítani, amely összhangban áll a vállalt szolgáltatási szint (kiemelten a rendelkezésre állás) paraméterekkel. A megfelelőséget számítással kell alátámasztani. Ki kell alakítani a feladatátvételi topológiát 180. Meg kell határozni, hogy mely eszközök szolgálnak egymás tartalékaiként, illetve az egyes tagok milyen szerepet (aktív kiszolgálói, tartalék) játszanak. A hardveres redundancia mellett az alkalmazás-szoftveres redundáns megvalósítása a rendelkezésre állás érdekében indokolt. A hálózati szempontból redundáns kapcsolatot kell biztosítani a kliensekkel.

Típus A

B

C

D

E

N

N

K

K

K

A

A

K

K

K

N

N

A

K

K

Megjegy zés

…és így tovább. A minősítés során a teljes követelmény-struktúrából egyszerűen leválogatható az a részhalmaz, amelyet a vonatkozó rendszer (A, B, C, ...besorolások szerint) minősítésekor alkalmazni kell. A fenti struktúrájú táblázatot a minősítő állítja elő a jelen követelményrendszer alapján. 6.5.2 Információs infrastruktúra minősítése A minősítés során a fenti módszerrel felállított táblázat szűrése után már a ténylegesen alkalmazandó kritériumokat tartalmazó táblázat lesz a „sorvezető”. Egy háziorvosi csoportpraxis számára felállított információs rendszer minősítési táblázatat az előzőek alapján a következőképpen alakul: a táblázat első két oszlopa a követelményeket meghatározó 4. és 5. fejezet táblázataiból áll. A harmadik oszlop a minősítésben érintett intézményt jelöli ki, a negyedik a típus (A ÷ E), valamint Megjegyzés rovat az utolsó oszlop. A Típus oszlopban kell meghatározni, hogy a követelmény-elem kötelező )K), vagy ajánlott (A).

180

Pl: feladatátvételi pár topológia, forró tartalék, feladatátvételi gyűrű, stb.


115


Ssz.

A-1-001

A-1-002

A-1-004

A-1-005

A-1-007

Követelmény A megfelelő fejlesztési technológia kiválasztásával időtálló, fenntartható rendszereket kell fejleszteni. Robosztus architektúra: Az alkalmazások architektúráját úgy kell megtervezni és megvalósítani, hogy az képes legyen a megcélzott (ágazati vagy intézeti) számú felhasználó biztonságos és gyors kiszolgálására. (Az elvárt gyorsaság megítélésénél az adott funkciók specifikációjánál megadott érték az irányadó). A megfelelőséget számítással kell alátámasztani és teszteléssel ellenőrizni. Méretezhetőség: Az alkalmazások architektúrájának (hardver és szoftver) biztosítania kell az intézmény vagy régióhoz tartozó teljes intézményrendszernek, mint felhasználó számhoz szükséges méretre való felbővítés lehetőségét. A megfelelőséget számítással kell alátámasztani. Hibatűrő, redundáns kialakítás: Mind egyedi eszköz telepítése esetén, mind szolgáltató központoknál olyan mértékben szükséges hibatűrő, redundáns infrastruktúrát kialakítani, amely összhangban áll a vállalt szolgáltatási szint (kiemelten a rendelkezésre állás) paraméterekkel. A megfelelőséget számítással kell alátámasztani. A hardveres redundancia mellett az alkalmazás-szoftveres redundáns megvalósítása a rendelkezésre állás érdekében indokolt.

Szállító/intéz mény

Típus

I

K

Sz

K

Sz

A

Sz

A

Sz

A

B

Megjegyzés

A táblázatot a minősítő intézet állítja elő és tölti ki a minősítési eljárás során. A táblázatban szereplő teljesített/összes kötelező követelmények hányadosa adja a minősítés eredményét:


116


Az információs rendszer megfelelő, ha az , vagyis a kötelező követelmények legalább 90%-át teljesíteni kell. Amennyiben az információs rendszer 3 évnél régebbi fejlesztés, akkor az elfogadható arány 70%, de a nem teljesített 20%-ot két éven belül pótolni kell. 6.5.3 Egészségügyi információs rendszerek szolgáltatásainak minősítése Az előző pontban az infrastruktúrális elemek 181 minősítését tárgyaltuk. A működő információs rendszerek az infrastruktúrán túl szolgáltatásokat nyújtanak a felhasználóiknak. Ezeknek a szolgáltatásoknak szoros kapcsolatuk van az alkalmazói logikával, vagyis az egészségügyi folyamatokkal. Jelen dolgozat nem tér ki a legapróbb részletekig ezen folyamatoknak való megfelelésre, hiszen a kérdést jobbára jogszabályok határozzák meg (pl.: adattartalmak, jelentési gyakoriság stb.). Az egészségügyi információs rendszerek szolgáltatás-szintű besorolását az alkalmazó intézmény szakmai besorolása adja meg. Ilyen az alapellátás, azon belül a különféle ellátási szakmák, vagy a szakellátás, az ágazati irányító státusz stb.

6.5.4 Információs rendszerfejlesztési projekt minősítése Az információs rendszerfejlesztési projekt minősítése két ágon zajlik: 9 alaki minősítés: a projekt belső szerkezetének – szervezetének minősítése (lásd részletesebben a 6. fejezetet) 9 tartalmi minősítés: a projekt célját, követelményeit tartalmazó dokumentáció minősítése Tartalmi minősítés a projekt kezdő dokumentumától (koncepció) a megvalósítást követő üzemeltetési dokumentációig terjedően vizsgálja a dokumentumok illeszkedését a tematikus fejezetek (3-6 fejezetek) által megfogalmazott követelményekhez, vagyis, biztosítja az elkészült információs rendszer megfelelőségét. A minősítés módszertana a dokumentum létrehozója által kitöltött ellenőrző lista ellenőrzése, a dokumentum összefogó, általános véleményezése. A minősítés eredményterméke az a hibalista, vagy vélemény, amely az ellenőrzésből következik. Tekintsük át a vonatkozó dokumentáció fajtákat a minősítés módszere szempontjából: 1. Rendszer koncepció A rendszer koncepció a megvalósítandó szolgáltatások nagyvonalú terve, amely szolgáltatások segítségével a projekt gazda valamely feladatának-feladatainak elvégzését kívánja támogatni. 1/a. A rendszerkoncepció illeszkedjen a központi fejlesztési programokhoz, a Semmelweis Terv szakmia taralmaihoz. Az illeszkedés ellenőrző listája 182: Sorszám Követelmény

Előfordulás helye (referencia)

Teljesül (Igen/nem)

181

Infrastruktúra alatt értünk minden olyan elemét az információs rendszernek, amely nem a felhasználói használathoz tartozik, vagyis a telepített hardvereken kívül ide tartozónak tekintjük az autentikációt‐authorizációt, a biztonsági elemeket és a mentés‐helyreállítás elemeit. 182 Az ellenőrző listát a minősítő szervezet állítja elő az NFÜ ajánlásainak megfelelően. Az előfordulás helye rovatot a A projekt gazda tölti ki.


117


1.

Az ellenőrző lista jelen dokumentumban szereplő változata nem tekinthető végleges, állandó tartalmúnak, hiszen a központi fejlesztési programok folyamatosan terebélyesednek. Ezért az ellenőrző lista aktuális állapota a minősítő intézet (lásd 121. oldal) honlapjáról letölthető lesz.

Sorszám

Támogatandó feladat

Előfordulás helye a feladatmeghatározó okiratban(referencia)

1.

X. feladat

k. okirat előfordulási helye

szerepel (Igen/nem)

1/b. A rendszerkoncepció illeszkedjen a projektgazda feladataihoz. A minősítés a hatályos intézményi alapító okiratban és egyéb alapfeladatot meghatározó dokumentumban ellenőrzi a projektgazda által meghatározott támogatott feladatok meglétét. Ez a következő ellenőrző lista 183 alapján történik: A rendszerkoncepció által megcélzott információs rendszer arányosságának ellenőrzése. 1/c. A minősítő azt ellenőrzi, hogy a tervezett információs rendszer bevezetése arányos szakismereti képzési megterhelést jelent a projektgazda szervezetének. Ennek mérésére …… 2. Megvalósíthatósági tanulmány(ok), Logikai rendszerterv – előzetes és végleges tanulmányok Az előzetes- és végleges megvalósíthatósági tanulmányok, rendszertervek vizsgálatát a fenntarthatóság és a hatáselemzés szempontjából kell elvégezni. A fenntarthatóság durva mérőszáma a projektgazda informatikai költségvetésének növekedése, valamint ennek az intézményi költségvetéshez való viszonya. A tanulmányok a következő ellenőrzési lista alapján kerülnek minősítésre: Sorszám Követelmény 184

Megkövetelt érték

Megfelel (Igen/nem)

1.

3. Pályáztatási dokumentáció A pályázati dokumentáció minősítése a tematikus (3-6) fejezetekben kidolgozott követelmények azon hányadára történik, amelynél a Kötelező és a Pályázatnál releváns értékei K; P. Sorszám 1.

Követelmény 185

Kötelező Pályázatnál /ajánlott

releváns

K

P

Mért érték

Teljesül (Igen/nem)

183

Az ellenőrző listát a projektgazda állítja elő és tölti ki, a minősítő intézet az utolsó oszlopot tölti ki. Az NFÜ által meghatározott követelmény 185 A mindenkori (köz)beszerzési eljárás határozza meg. 184


118


A pályázati dokumentáció (technikai specifikációja) akkor megfelelő, ha az összes ilyen követelmény teljesítve van. 5. Értékelés dokumentációja Az értékelés dokumentációját a pályázati dokumentáció alapján, az ott megkövetelt követelmények ajánló által vállalt megfelelését kell vizsgálni. A teljes egyezőség az elfogadott. 6.5.5 Szervezet minősítése az információs rendszer fejlesztési projekt szempontjából A szervezetet azoknak a képességeknek a megléte szempontjából minősítjük, amelyek szükségesek a projekt életciklusán keresztül. Az életciklust 4 részre oszthatjuk: 9 Projekt előkészítése 9 Projekt végrehajtása 9 A projekt során megvalósuló információs rendszer fenntarthatósága 9 A projekt során megvalósuló információs rendszer üzemeltetésének megfelelősége A megfelelőség mérésére az 5. fejezet által meghatározott követelmények alapján történik. A megfelelőséget a minősítő által meghatározott követelmény jegyzék alapján mérik.

6.6 A rendszerminősítés folyamata, a minősítések publikálása 6.6.1 Információs rendszer minősítésének folyamata 9 A minősítendő információs rendszer besorolása (A ÷ E) 9 A besorolásnak megfelelő minősítő táblázat előállítása (lőlap) 9 A minősítő táblázat elküldése a minősítendő információs rendszer felelősének 9 A kitöltve visszaérkezett minősítő táblázat alapján helyszíni ellenőrzés o tételes v. o szúrópróba szerint 9 Az ellenőrzés során észlelt eltérések értékelése o megfelelő o nem megfelelő o ideiglenesen éé.hh.nn-ig üzemeltethető 9 A minősítési jegyzőkönyv előállítása 9 A minősítés eredményének feltöltése a minősítési információs rendszerbe 9 A minősített felügyeleti szervének értesítése a minősítésről.


119


6.6.2 Fejlesztési projekt minősítésének folyamata

Előkészítés 9 A fejlesztési projekt besorolása (A ÷ x) 9 A besorolásnak megfelelő dokumentumok listájának előállítása 9 A meghatározott dokumentumok bekérése a minősített projekt gazdájától 9 A besorolásnak megfelelő minősítő táblázat előállítása (lőlap) 9 A minősítő táblázat elküldése a minősítendő projekt gazdájának 9 A kitöltve visszaérkezett minősítő táblázat alapján ellenőrzés o tételes v. o szúrópróba szerint 9 Az ellenőrzés során észlelt eltérések értékelése o megfelelő o nem folytatható o ideiglenesen éé.hh.nn-ig folytatható 9 A minősítési jegyzőkönyv előállítása 9 A minősítés során észlelt hiányosságok pótlása, annak elősegítése 9 A minősítés eredményének feltöltése a minősítési információs rendszerbe 9 A minősített projekt felügyeleti (EU-s, kormányzati, magán) szervének értesítése a minősítésről.

Végrehajtás (forrás biztosított) 9 A minősítő táblázat elküldése a minősítendő projekt gazdájának 9 A besorolásnak megfelelő dokumentumok listájának előállítása o Egyszeri dokumentumok o időszakos dokumentumok 9 A meghatározott dokumentumok egyszeri v. időszakos bekérése a minősített projekt gazdájától 9 A besorolásnak megfelelő minősítő táblázat előállítása (lőlap) 9 A kitöltve visszaérkezett minősítő táblázat alapján ellenőrzés Összeállította a GYEMSZI szakértői munkacsoportja

120


o tételes v. o szúrópróba szerint 9 Az ellenőrzés során észlelt eltérések értékelése o megfelelő o nem folytatható o ideiglenesen éé.hh.nn-ig folytatható 9 A minősítési jegyzőkönyv előállítása 9 A minősítés során észlelt hiányosságok pótlása, annak elősegítése 9 A minősítés eredményének feltöltése a minősítési információs rendszerbe

Eredmény termék – a szállított/fejlesztett rendszer 9 A minősítendő információs rendszer besorolása (A ÷ E) 9 A besorolásnak megfelelő minősítő táblázat előállítása (lőlap) 9 A minősítő táblázat elküldése a projekt gazdának 9 A kitöltve visszaérkezett minősítő táblázat alapján helyszíni ellenőrzés o tételes v. o szúrópróba szerint 9 Az ellenőrzés során észlelt eltérések értékelése o megfelelő o megfelelő, ha a felsorolt hiányok pótlása megtörtént o nem megfelelő 9 A minősítési jegyzőkönyv előállítása 9 A minősítés eredményének feltöltése a minősítési információs rendszerbe 9 A minősített felügyeleti szervének értesítése a minősítésről. 6.6.3 Szervezet minősítésének folyamata

6.7 A rendszerminősítés szervezete/intézménye A rendszerminősítés az egészségügyi ágazatban nem rendelkezik hagyományokkal. Ugyan az Országos Egészségbiztosítási Pénztár azokat a rendszereket minősíteni akarta, amelyekkel Összeállította a GYEMSZI szakértői munkacsoportja

121


elektronikus jelentési kapcsolatban áll, azonban ennek a minősítési környezete az elektronikus kapcsolódásra való alkalmasságon nem mutatott túl, és nem is valósult meg. A jelen dokumentum túl a rendszerkövetelmények összegyűjtésén egy megvalósítható minősítési rendszer elképzelését is tartalmaznia kell, amely alapjául szolgál a minősítés intézményi környezetének kialakításához, valamint az eljárást alátámasztó jogi környezet megteremtéséhez. A rendszerminősítés csakis egy erre a célra kialakított szervezeten keresztül történhet. A nemzetközi gyakorlat szerint az auditálás (nem a rendszerminősítés, annál komolyabb folyamat) mindig független szervezetek privilégiuma. Ez biztosítja a platform- és piacfüggetlenséget. A mi esetünkben ágazati minősítésről van szó, amelyet az egészségügyi kormányzat abból a célból végez, hogy biztosítsa az informatikai, információs rendszerbeli fejlesztések leghatékonyabb módját, egyben érvényesítve azokat az elvárásokat, amelyeket az ágazat szervezője és irányítója az ágazati egész szempontjából szükségesnek tart. Erre azért is szükség van, mert az egészségügyi ellátás átszervezése központi akaratból történik. Ezért a minősítés intézményét első menetben a Megrendelő GYEMSZI „hatókörébe” tervezzük, amely gyakorlati tapasztalatokat halmoz fel a kezdeti minősítési periódusban, ami alapján kialakítható az a „független” audit szervezet, amely függetlenül az ágazati törekvések irányától, csakis informatikai szempontból vizsgálja majd a rendszereket.

6.7.1 A minősítő szervezet/intézmény jogállása A minősítő tevékenységet három periódusra bonthatjuk:

1. A minősítés szempontrendszerének és folyamatának tesztelése – kezdeti periódus ; 2. A minősítés rendszerének jobbítása a felgyűlt tapasztalatok alapján, összehasonlító minősítések folytatása – szankciók és következmények nélkül; 3. Rendszerszerű, tervszerű és folyamatos minősítési tevékenység folytatása. A fenti periódusok értelemszerűen a végrehajtó szervezetre is visszahatnak, alakítják azt is. Ezért felesleges arról beszélni, hogy a kezdetektől álljon fel egy szervezet a tevékenység ellátására. Véleményünk szerint erre csak a második, de leginkább a harmadik periódusban van szükség. A minősítő szervezet/intézmény alapfeladata a 4. és 5. fejezetek által meghatározott követelmények érvényesítése az információs rendszerek és a fejlesztést végrehajtó intézmények illetve az általuk vezetett fejlesztési projektek tekintetében. A szervezet ezen feladatát megfelelő szintű jogszabály által nevesítetten látja el. A jogszabály kormány/ágazati szintű rendelet formájában jelenik meg.


122

Javasolt jogszabályi változtatások

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

186

Szabályzatban rögzített eljárások sorozata


123

Javasolt jogszabályi változtatások

8.

9. 10.

11.

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. Az egészségügyi intézménynél mindenkor rendelkezésre kell állnia: a) az informatikai rendszer felépítésének és működtetésének az ellenőrzéséhez szükséges rendszerleírásoknak és modelleknek b) az informatikai rendszernél az adatok szintaktikai szabályainak, az adatok tárolási szerkezetének – konkrétabban: fejlesztői vagy üzemeltetői kézikönyv? Annak elvárt sablonjával az NFM-től ?, c) az informatikai rendszer elemeinek az egészségügyi előírások által meghatározott biztonsági osztályokba sorolási rendszerének – mi ez: cégszintű adatbesorolás?, d) az adatokhoz történő hozzáférési rend meghatározásának, e) az adatgazda és a rendszergazda kijelölését tartalmazó iratnak – mi ez: IT szervezetimunkaköri leírás, amely bizonyos kötelező elemeket tartalmaz?, f) az alkalmazott szoftver eszközök jogtisztaságát bizonyító szerződéseknek, az informatikai rendszert alkotó ügyviteli, egészségügyi szoftvereszközök teljes körű és naprakész nyilvántartásának. 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.


124

Nemzetközi minősítési gyakorlat

MELLÉKLETEK 8 A követelmények rendszerét meghatározó fejezetek 8.1 Az egészségügyi információs követelményei és gyakorlata

rendszerek

nemzetközi

minősítési

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


125


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


126


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


127


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


128


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


129


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

130


egészségügyi adatok egészségügyi ellátás céljából való tárolása. A rendszereket úgy kell megtervezni, hogy lehetőség szerint azonosítás céljából ne használjanak személyes adatot, hanem csak anonim azonosítókat. Azonosítani kell továbbá azokat az egészségügyi adatokat, amelyek elektronikus hozzáférése – az ellátás szempontjából – lényeges, és azokat, amelyek ebből a körből kizárhatók (pl. genetikai vagy pszichiátriai adatok).

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


131


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


132


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


133


Ennek megfelelően az EHR rendszerekkel kapcsolatos releváns standardok kapcsán beszélhetünk architekturális, modellezési, terminológiai, ontológia, osztályozási, azonosítási, biztonsági, infrastrukturális, személyiségi jogi, fejlesztési és más standardokról. A projektek megrendelőinek azt kell biztosítaniuk, hogy az alkalmazások szállítói az alkalmazások tervezése során alkalmazzák a rendelkezésre álló szabványokat és nyilatkozzanak az alkalmazások megfelelőségéről és az esetleges fenntartásokról és ezek okairól.

Szervezet

Alkalmazási terület

ASTM

Az USA legjelentősebb szabványosítási szabványok széles területet lefednek.

CEN (EN)

Kötelezően alkalmazandó, általános.

ISO

Általános – az egészségügyi informatikai szabványok a TC 251 munkacsoport termékei

CENELEC

A szabványok az EN szabvány alatt jelennek meg a CEN-el együttműködésben, ezeket technikai jelentések (TR) egészítik ki

ETSI

Európai telekommunikációs szabványosítási intézet. A technikai specifikációtól az EN szabványok kidolgozásáig terjed a tevékenysége.

HL7

Elsődlegesen egészségügyi informatikai interoperabilitását szolgáló standardok.

openEHR

Elektronikus betegadatok kezelése, tárolása

DICOM

Digitális képalkotó technológiák

LOINC

Orvosi terminológia adatbázis, amely általános kód és azonosítási rendszert alkalmaz, így támogatja a rendszerek közötti kommunikációt.

IHTSDO

Szemantikai interoperabilitás

IHE

Specifikus profilok alkotása, amelyek a szabványok gyakorlati alkalmazását biztosítják

Continua

Ellátás folyamatossága

GS1

Elektronikus kereskedelem/vonalkódok (betegbiztonság)

W3C

Web service leíró nyelv (WSDL 1.1) alkalmazások közötti kommunikációra


szervezete.

A

rendszerek

134


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

135


egészségügyi ellátás és az e-egészségügyi rendszerek egyes kulcsterületein, úgy mint az ekórlap és az e-recept, valamint ezeket követően az európai egészségbiztosítási kártya és a betegek egészségügyi adatokhoz való hozzáférése. Az epSOS szolgáltatásai web-service szolgáltatásként valósulnak meg. A kommunikáció hivatalosan kijelölt un. nemzeti kapcsolati pontokon (NCP) keresztül történik, amelyek a szolgáltatást nyújtják a felhasználóknak. Öt szolgáltatást definiál a projekt: azonosítás, beteg-adat lekérése és megrendelése, egyógyszerkiadás, beteg-beleegyezés. Az epSOS a későbbikben ismertetett szabványokon és profilokon alapul. A CALLIOPE az EU kezdeményezése, amely az interoperabilitással kapcsolatos akadályokat és teendőket térképezte fel és felvázolt egy cselekvési menetrendet (Interoperability Roadmap), amely elsősorban tagállami szinten értelmezhető. Fontosabb szabványok Az alábbiakban bemutatjuk a fontosabb e-egészségügyi szabványokat, amelyeket az alkalmazások és projektek tervezése során figyelembe kell venni és amelyekre az EU szabványosítási munkája is alapul. A szabványok aktuális listája megtalálható az EuroRec és a OENO honlapján, valamint az egyes szabványalkotó szervezetek honlapjain. A szabványok változása miatt feltétlenül javasolt ezek áttekintése. Azonosító

Megnevezés/Leírás

ASTM

ASTM E1714-00, ASTM Azonosítás, biztonság E1987-98 személyiségi jogok

CEN

CEN (EN) egészségügyi informatikai standardok

CEN

CEN 13608: Az egészségügyi ellátás során történő kommunikáció biztonsága CEN 13606: Elektronikus egészségügyi rekord kommunikáció CEN 13729: Biztonságos felhasználó azonosítás Digitális Képalkotás és Kommunikáció

CEN CEN DICOM ASTM E1239

Megjegyzés és

Kommunikáció

Kommunikáció Személyiségi jog/biztonság

A betegek regisztrációját, felvételét, szállítását és elbocsátását kezelő rendszerek (R-ADT) leírásának standardja


136


ASTM E1284

Útmutató az Elektronikus egészségügyi rekordokat támogató klinikai nomenklatúra kialakításához

ASTM E1384

Elektronikus egészségügyi rekord tartalma és struktúrája

ASTM E1633

Az elektronikus egészségügyi rekordokban használt kódolt értékek specifikációja

ASTM E1714

Egységes egészségügyi azonosító tulajdonságai (UHID)

ASTM E1715

Objektum-orientált beteg regisztrációs, -felvételi, szállítási és elbocsátási (RADT) funkciók az EHR rendszerekben

ASTM E1744

Sürgősségi ellátás az EHR rendszerekben

ASTM E1762

Egészségügyi ellátási információk elektronikus azonosítása

ASTM E1869

Az egészségügyi információ adatbiztonsági, hozzáférési, személyiségi jogi elvei

ASTM E2171

Elektronikus egészségügyi rekordokkal kapcsolatos mérési skálák

ASTM E2183

XML DTD tervezés, architektúra és implementáció

ASTM E2184

Egészségügyi dokumentáció standard specifikációja


137


ASTM E2211

Személyes elektronikus egészségügyi rekordok személyei és szolgáltatói közötti kapcsolat specifikációja

ASTM E2369

Ellátás folyamatosságára vonatkozó rekord (CCR) specifikációja

ASTM E2473

Az elektronikus egészségügyi rekord foglalkozás- és környezetegészségügyi nézete

EN 1068

Kódolási rendszerek regisztrációja

EN 12967:2005

Egészségügyi rendszerek architektúrája

EN

13606 EHRcom Elektronikus egészségügyi rekordok kommunikációja

EN 14484:2003 14485:2004 is)

információs standard

(lásd Az EU adatvédelmi Magas-szintű adatvédelem irányelve által lefedett egészségügyi adatok nemzetközi szintű cseréje

EN 14720

Szolgáltatás kérési és riportolási üzenetek

EN 14822

GPIC Általános célú információs komponensek

ENV 12612

Egészségügyi igazgatási információ cseréjére vonatkozó üzenetek

HL7

V3 üzenetküldési standard Kommunikáció (a HL7 V3 modellnek megfelelő rendszerek


Kommunikáció

Kommunikáció

138


esetén) HL7

GELLO

UML-alapú klinikai döntéseket támogató leíró nyelv

HL7

CCOW/vizuális integráció

Standard protokoll, amely különálló rendszereket támogat a felhasználói és beteg kontextus megosztásában felhasználói szinten.

HL7

Standard mellékletek

HL7

Arden syntax

Orvosi ismeretek (tudás) kódolására alkalmas nyelv, amely az orvosi/klinikai döntéseket támogatja

HL7

Strukturált termék címkézés

Gyógyszerek standard termék leírásának modellje

HL7 10781:2009

Elektronikus egészségügyi Elektronikus egészségügyi adat (personal health record) nyilvántartó rendszerek funkcióinak leírása

HL7/ISO 21713:2006

Referencia Modell (RIM)

HL7/ISO 27931:2009

2.5 verzió standard

HL7/ISO 27932:2009

Klinikai dokumentum Xml használatán alapuló architektúra (CDA) model, amely biztosítja klinikai dokumentumok cseréjét, gépi és humán értelmezését

elektronikus Beutalók, elszámolások struktúrája

jelentések, standard

Információs Klinikai és adminisztratív környezetben használt adattartalom leírása üzenetküldési Informatikai rendszerek által előállított és fogadott tranzakciók interoperabilitási specifikációja. Az üzenetküldést a MML protokoll támogatja.


139


IEEE 11073-10101

Betegágy melletti orvosi eszközök kommunikációja nomenklatúra

Kommunikáció

IEEE 11073-10200

Betegágy melletti orvosi eszközök kommunikációja – számítógépek és orvosi eszközök összeköttetése LAN rendszerekben

Kommunikáció

IEEE 11073-10201

Betegágy melletti orvosi eszközök kommunikációja – alkalmazási entitások közötti kommunikáció

Kommunikáció

IHE profilok

A profilok a különböző standardok gyakorlati alkalmazását írják le specifikus adott klinikumi környezetben

Jelenleg a következő területeken létezik leírt és tesztelt profil: patológia, kardiológia, szemészet, IT infrastuktúra, orvosi laboratórium, radiológia, sugárterápia, betegellátás koordinációja, betegellátással kapcsolatos egyes eszközök

ISO 12052:2006/DICOM

Orvosi digitális képalkotás és kommunikáció

ISO 17090

Publikus infrastruktúra

ISO 18308:2003

Elektronikus egészségügyi referencia architektúra

ISO 20514:2005

Elektronikus beteg rekord

ISO 21549

Elektronikus kártya

ISO 22857:2004

Betegadatok védelme a Adatvédelem határon átnyúló ellátásban

ISO CT 215

Az ISO egészségügyi Összesen 59 szabvány – ezek informatikai bizottsága, közül csak néhány amely a releváns fontosabbat sorolunk fel standardokat dolgozza ki.

kulcs Infrastruktúra

egészségügyi


140


ISO/TR 18307:2001

Üzenetküldési és Kommunikáció kommunikációs standardok interoperabilitása és kompatibilitása

ISO/TS 25237:2008

Pszeudo-anonimizáció

Azonosítás

openEHR

OpenEHR keretrendszer

Az egészségügyi adatok kezelését, tárolását, kinyerését leíró standard

OpenEHR/EN 13606

Elektronikus beteg kommunikáció

SNOMED CT /IHTSDO)

Orvosi terminológia Rendszerek szemantikai standard leírása interoperabilitása


adat Az elektronikus beteg dokumentáció egészének vagy egy részének továbbítását támogató információs modell

141

Gazdasági és VIR rendszerek adatkezelési követelményei

8.2 Egészségügyi gazdasági információs rendszerek és VIR rendszerek speciális adatkezeléssel kapcsolatos minősítése ajánlásai 8.2.1 Törvényi háttér

8.2.1.1 Esetfinanszírozott adatok jelentése 43/1999. (III. 3.) Kormányrendelet. Tételes elszámolású eszközök és a nagy értékű műtéti beavatkozások (17. sz. melléklet) Az esetfinanszírozott beavatkozások teljesítmény jelentése számítógépes adathordozón (mágneslemezen) szabványos formátumban küldhető. A havi teljesítményadatokat illetve az esetleges korrekciós adatokat külön adatállományokba kell szervezni. Jelenlegi adatküldési rekordkép az alábbi személyes adatokat tartalmazza: ¾ Beteg személyazonosító jele ¾ Beteg születési dátuma ¾ Beteg neme ¾ Beavatkozás dátuma ¾ Beavatkozás indikáció A fenti személyes adatokon túl megtalálható a ¾ Elvégzett beavatkozás kódja ¾ Térítési kategória ¾ Elvégzett beavatkozás forintérték

8.2.1.2 Tételes elszámolású eszközök és a nagy értékű műtéti beavatkozások 43/1999. (III. 3.) Kormányrendelet Tételes elszámolású eszközök és a nagy értékű műtéti beavatkozások (17. sz. melléklet) A kórházi információs rendszerek az költség adatok kimutatása illetve az eszközök nyilvántartása érdekében a műtét során felhasznált anyagokról tételes, betegre szóló bizonylat készül. A bizonylat vagy a gazdasági rendszerben vagy a klinikai rendszerben kerül rögzítésre, de a raktári mozgásokkal és felhasználásokkal kapcsolatban a beteg személyes adati a gazdasági rendszerben tárolásra kerülnek. Nagy értékű anyagok betegre történő rögzítését törvény írja elő ()

8.2.1.3 Ráfordítási adatgyűjtés Az egészségügyi szolgáltatások, a finanszírozási paraméterek folyamatos karbantartását a 6/1998. (III. 11.) NM rendelet szabályozza. Az átfogó karbantartáshoz szükséges adatbázis létrehozásának egyik fő forrása a kijelölt ellátási területeken, ellátási esetekhez, szolgáltatásokhoz felhasznált erőforrások kijelölt időszakban, kijelölt szolgáltatóknál történő megfigyelése.

8.2.1.4 Orvosválasztás kapcsán felmerülő díj


142


2007. január 1-jétől külön, részleges térítési díj megfizetése mellett lehetőség van arra, hogy az egészségügyi intézmény munkarendje alapján a beteghez beosztott orvos helyett másik orvost kérjen a beteg, ha ezt a választást a beteg egészségi állapota által indokolt ellátás szakmai tartalma és az ellátás sürgőssége nem zárja ki. A részleges térítési díj ellenében a beteg olyan orvost is választhat, aki az ellátó egészségügyi szolgáltatónál nem áll munkaviszonyban (közalkalmazotti jogviszonyban).

8.2.1.5 Fizetős szolgáltatások Egyes egészségügyi ellátásokra a szolgáltató térítési díjat állapíthat meg, amelyekről a szolgáltatás megkezdése előtt köteles a biztosítottat tájékoztatni. A részleges térítési díj képzésének szabályai, illetőleg több esetben pontos összege a térítési díj ellenében igénybe vehető egyes egészségügyi szolgáltatások térítési díjáról szóló 284/1997. (XII. 23.) Korm. rendelet 1. sz. melléklete meghatározott, attól érvényesen eltérni nem lehet.Pl: ¾ a terhesség megszakítás térítési díja. 1992. évi LXXIX. Törvény ¾ 284/1997. (XII. 23.) Korm. Rendelet térítési díj ellenében igénybe vehető egyes egészségügyi szolgáltatások térítési díjáról

8.2.1.6 Vizitdíj, kórházi napidíj Megjelenés helye, ideje: Magyar Közlöny 2006/156. (XII. 18.) Hatályosság kezdete:2007. január 1. A 7. §, 17. § és a 19. § (1) bekezdés 2007. február 15-én, a 34. § 2007. május 1-jén lépett hatályba. 2007. február 15-én bevezetésre került a vizitdíj és a kórházi napidíj,” a beteg-orvos találkozások csökkentésére és a társadalombiztosítás biztosítási körének csökkentésére, a költségek részleges áthárítására” érdekében. Igaz, hogy népszavazás eredményét követően 2008. március 31-ével megszüntetésre került, de hasonló intézkedésre a gazdasági rendszereket fel kell készíteni. A vizitdíjat nyugta ellenében kellett megfizetni. A nyugtának tartalmaznia kellett a beteg nevét, a tajszámát és a dátumot. A nyugta az intézetek nagy részében a klinikai és a gazdasági rendszerek integrálását biztosító szoftver (a klinikai rendszer biztosította a beteg személyi adatait) segítségével került kiállításra, tehát a beteg személyi adatai a gazdasági rendszerben kerültek tárolásra.

8.2.1.7 Várólistával kapcsolatban ¾ ¾ ¾ ¾ ¾

1997. évi LXXXIII. törvény a kötelező egészségbiztosítás ellátásairól 1997. évi CLIV. törvény az egészségügyről 2006. évi CXVI. törvény az egészségbiztosítás hatósági felügyeletéről 287/2006. (XII. 23.) Kormányrendelet a várólista alapján nyújtható ellátások részletes szabályairól 45/2006. (XII. 27.) EüM rendelet a várólista-sorrend kialakításának és az eltérés lehetőségének egészségügyi szakmai feltételeiről ¾ 46/2006. (XII. 27.) EüM rendelet a várólista adatainak honlapon történő közzétételére vonatkozó szabályairól


143


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

Jelen anyag hatókörében nem tartozik mindazon szakmai követelmények specifikálása amelyek a gazdálkodással kapcsolatos funkciók működését és elvárásait tartalmazza. Összeállította a GYEMSZI szakértői munkacsoportja

144


8.2.3 Személyi adatok védelme a nem klinikai rendszerekben A törvényi előírások alapján ellenőrizendő funkciók.

A vizsgált szoftverterméket felkészítették-e személyes adatok kezelésére ¾ ¾ ¾ ¾ ¾ ¾

A személyes adatok védelmével kapcsolatos jogosultság kialakítását biztosító funkció, funkciócsoport meglétének és működésének ellenőrzése A személyes adatok kezelésének egyedi felhasználók számára történő engedélyezése megvalósítható-e? A személyes adatok bevitelének egyedi felhasználók számára történő engedélyezése megvalósítható-e? A személyes adatok törlésének egyedi felhasználóhoz történő engedélyezése megvalósítható-e? A személyes adatok nyomtatásának egyedi felhasználóhoz történő engedélyezése megvalósítható-e? A személyes adatok listázásának egyedi felhasználóhoz történő engedélyezése megvalósítható-e?

A személyes adatok kezelése a rendszerben (az adat kezelésére nem jogosultak esetén) ¾ A rendszerben tárolt személyes adatot tartalmazó tétel kezelése kapcsán az arra nem jogosultak elől oly módon van-e védve az adat, hogy a kapcsolata az érintettel nem helyreállítható (ez történhet egyéb azonosító megjelenítésével vagy a személyes adat kitakarásával, helyettesítésével)? ¾ A rendszerben tárolt személyes adatot tartalmazó tétel megtekintése kapcsán az arra nem jogosultak elől oly módon van-e védve az adat, hogy a kapcsolata az érintettel nem helyreállítható (ez történhet például egyéb azonosító megjelenítésével vagy a személyes adat kitakarásával, helyettesítésével)? ¾ A rendszerben tárolt személyes adatot tartalmazó tétel nyomtatása kapcsán az arra nem jogosultak elől oly módon van-e védve az adat, hogy a kapcsolata az érintettel nem helyreállítható (ez történhet például egyéb azonosító megjelenítésével vagy a személyes adat kitakarásával, helyettesítésével)? ¾ A rendszerben tárolt személyes adatot tartalmazó tétel állományba mentése kapcsán az arra nem jogosultak elől oly módon van-e védve az adat, hogy a kapcsolata az érintettel nem helyreállítható (ez történhet például egyéb azonosító megjelenítésével vagy a személyes adat kitakarásával, helyettesítésével)? A személyes adatok kezelése a rendszerben (az adat kezelésére jogosultak esetén) ¾ A rendszerben tárolt személyes adatot tartalmazó tétel kezelése kapcsán az arra jogosultak kezelhetik-e az adatokat (pl: betegszámla felvitel)? ¾ A rendszerben tárolt személyes adatot tartalmazó tételsor megtekintése kapcsán az arra jogosultak nyomtathatják-e az adatokat (pl: betegszámla nyomtatás)? ¾ A rendszerben tárolt személyes adatot tartalmazó tételsor elemeit nyomtathatják-e az arra jogosultak? ¾ A rendszerben tárolt személyes adatot tartalmazó tétel állományba mentése kapcsán az arra nem jogosultak kezelhetik-e az adatokat (pl: ellenőrző lista nyomtatás, file-ba importálás)


145


8.2.4 A személyes adatok kezelésével kapcsolatos tevékenységek naplózása A törvényi előírások alapján ellenőrizendő funkciók.

A vizsgált szoftverterméket felkészítették-e a személyi adatok kezelésével kapcsolatos tevékenységek naplózására ¾ ¾ ¾ ¾ ¾ ¾ ¾ ¾ ¾ ¾

A személyes adatok védelmével kapcsolatos tevékenységek rendszer szintű megvalósítását biztosító naplózó funkció, funkciócsoport meglétének és működésének ellenőrzése A személyes adatok kezelésével kapcsolatos tranzakciók naplózása beállítható-e a rendszerben? A személyes adatok kezelésével kapcsolatos tranzakciós naplókban tárolt adatok alapján megállapíthatók-e, hogy az adatkezelést ki, mikor, melyik program melyik programrészéből (funkciójából) és melyik számítástechnikai eszközről kezdeményezte? A személyes adatok kezelésével kapcsolatos tranzakciós naplókban tárolt adatok alapján megállapíthatók-e, hogy az adatkezelés során mely adatok kerültek módosításra (módosítás, törlés, adatbevitel,stb.)? A módosítás kapcsán tárolásra kerülnek-e a módosítás előtti és a módosítás utáni adatok minden verziója? A személyes adatok kezelésével kapcsolatos tranzakciós naplók megtekinthetők-e a rendszerben? A személyes adatok kezelésével kapcsolatos tranzakciós naplók nyomtathatók-e a rendszerből? A személyes adatok kezelésével kapcsolatos tranzakciós naplók állományba menthetők-e a rendszerbőn? A személyes adatok kezelésével kapcsolatos tranzakciós naplók mentésre kerülnek-e a rendszerben? A személyes adatok kezelésével kapcsolatos tranzakciós naplók archiválásra kerülnek-e a rendszerben?

8.2.5 A személyes adatok továbbításával kapcsolatos tevékenységek naplózása A törvényi előírások alapján ellenőrizendő funkciók.

A vizsgált szoftverterméket felkészítették-e a személyi adatok adattovábbításával kapcsolatos tevékenységek naplózására ¾ ¾ ¾

¾

A személyes adatok védelmével kapcsolatos tevékenységek rendszer szintű megvalósítását biztosító adattovábbítást naplózó funkció, funkciócsoport meglétének és működésének ellenőrzése A személyes adatok továbbításával kapcsolatos tranzakciók naplózása beállítható-e a rendszerben? A személyes adatok kezelésével kapcsolatos tranzakciós naplókban tárolt adatok alapján megállapíthatók-e, hogy az adattovábbítást ki, mikor, melyik program melyik programrészéből (funkciójából), melyik számítástechnikai eszközről és mely törvényi előírás utasítására kezdeményezte? A személyi adatokat tartalmazó továbbított állományok (adatküldő, javító és elszámoló állományok) a személyes adatok védelmével kapcsolatos előírás szerint védett módon kerülnek-e tárolásra?


146


8.2.6 Egyéb adatok továbbításával kapcsolatos elvárások A törvényi előírások alapján ellenőrizendő funkciók.

Adatok adattovábbításával kapcsolatos tevékenységek ¾

¾ ¾ ¾

A gazdálkodási rendszernek támogatnia kell az államháztartás felé jelentési kötelezettséggel bíró operatív gazdálkodási folyamatait, tranzakcióit és biztosítania kell az egészségügyi intézményeknél alkalmazott szakrendszerek által a gazdálkodási rendszer felé kezdeményezett pénzügyi/gazdasági tranzakciók elektronikus kezelését. A továbbított adatok digitális aláírását A továbbított adatok naplózását és visszakereshetőségét. Felhasználói interfész: Az alkalmazások felhasználói interfészét az egyes alkalmazások esetében úgy kell kialakítani, hogy azok biztosítsák az alkalmazás képernyők, oldalak elvárható sebességű, elérhetőségét az általánosan elterjedt, kereskedelmi forgalomban rendelkezésre álló szélessávú internet kapcsolatokon keresztül az adatbiztonság megőrzése mellett.


147

Portál követelmények

8.3 Intézményi portálok közzététellel kapcsolatos tartalmi követelményei 8.3.1 Törvényi háttér

8.3.1.1 A honlapon történő közzététel kötelezettséggel kapcsolatban ¾ Az elektronikus információszabadságról szóló 2005. évi CX törvény, (Eitv.) törvényből adódó közzétételi kötelezettségek,és o Az Eitv. 6. § (2) bek. szerint „Jogszabály egyes ágazatokra, a közfeladatot ellátó szervtípusra vonatkozóan meghatározhat egyéb közzéteendő adatokat (különös közzétételi lista).” o Az Eitv. 6. § (3) bek. értelmében „A közfeladatot ellátó szerv vezetője — az adatvédelmi biztos véleményének kikérésével —, valamint jogszabály a közfeladatot ellátó szervre, azok irányítása, felügyelete alá tartozó szervekre vagy azok egy részére kiterjedő hatállyal további kötelezően közzéteendő adatkört határozhat meg (egyedi közzétételi lista) ¾ a közpénzek felhasználásával, a köztulajdon használatának nyilvánosságával, átláthatóbbá tételével és ellenőrzésének bővítésével összefüggő egyes törvények módosításáról szóló 2003. évi XXIV. törvény, ¾ a közbeszerzésekről szóló 2003. évi CXXIX. törvény, ¾ valamint a 305/2005. korm. rendelet o A 305/2005. korm. rend. 6/A. § (1) bek. alapján minden intézet a honlapján a”Közérdekű adatok” között köteles feltüntetni a közzéteendő adatok teljes körét (vezetői döntés alapján közzéteendő adatok).

8.3.1.2 Várólistával kapcsolatban ¾ ¾ ¾ ¾

1997. évi LXXXIII. törvény a kötelező egészségbiztosítás ellátásairól 1997. évi CLIV. törvény az egészségügyről 2006. évi CXVI. törvény az egészségbiztosítás hatósági felügyeletéről 287/2006. (XII. 23.) Kormányrendelet a várólista alapján nyújtható ellátások részletes szabályairól ¾ 45/2006. (XII. 27.) EüM rendelet a várólista-sorrend kialakításának és az eltérés lehetőségének egészségügyi szakmai feltételeiről ¾ 46/2006. (XII. 27.) EüM rendelet a várólista adatainak honlapon történő közzétételére vonatkozó szabályairól

Az anyag elkészítésénél figyelembe vettük a NEFI elődjének Egészségügyi Minisztérium Belső Ellenőrzése által adott iránymutatásokat és ellenőrzési terveket.


148


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


149


kezelő szervének tagjait Megjelenítették-e a közfeladatot ellátó szerv által alapított lapok nevét a szerkesztőség nevét címét a kiadó nevét címét a főszerkesztő nevét Megjelenítették-e a közfeladatot ellátó szerv felettes, illetve felügyeleti szervének, ennek hiányában a közfeladatot ellátó szerv felett törvényességi ellenőrzést gyakorló szerv nevét székhelyét postai címét telefonszámát faxszámát elektronikus levélcímét ügyfélszolgálatának elérhetőségét

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


150


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

151


mutatókat és értéküket időbeli változásukat teljesítményének mérésére mutatókat és értéküket időbeli változásukat Megjelenítették -e a közérdekű adatok megismerésére irányuló igények intézésének rendjét az illetékes szervezeti egység nevét elérhetőségét (telefon- és faxszáma, elektronikus levélcíme) az adatvédelmi felelős nevét az információs jogokkal foglalkozó személy nevét Megjelenítették -e a közfeladatot ellátó szerv tevékenységére vonatkozó, jogszabályon alapuló statisztikai adatgyűjtés eredményeit időbeli változásukat Megjelenítették -e a közérdekű adatokkal kapcsolatos kötelező statisztikai adatszolgáltatás adott szervre vonatkozó adatait Megjelenítették -e azon közérdekű adatok hasznosítására irányuló szerződések listáját, amelyekben a közfeladatot ellátó szerv az egyik szerződő fél Megjelenítették -e a közfeladatot ellátó szerv kezelésében lévő közérdekű adatok felhasználására vonatkozó általános szerződési feltételeket hasznosítására vonatkozó általános szerződési feltételeket Megjelenítették-e a közfeladatot ellátó szervre vonatkozó különös és egyedi közzétételi listát

Javasolt ellenőrzési terv Feltüntették-e a közfeladatot ellátó szervre vonatkozó adatokat az Eitv. Melléklete II. 1. pontjában meghatározott módon és tartalommal Feltüntették-e az országos illetékességű szervek esetén a közfeladatot ellátó szervre vonatkozó adatokat az Eitv. Melléklete II. 2. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szerv által nyújtott vagy költségvetésből finanszírozott közszolgáltatásokra vonatkozó adatokat az Eitv. Melléklete II. 5. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szerv által fenntartott adatbázisokkal, illetve nyilvántartásokkal összefüggő adatokat az Eitv. Melléklete II. 6. pontjában meghatározott módon és tartalommal Feltüntették-e a közfeladatot ellátó szerv nyilvános kiadványaira vonatkozó adatokat az Eitv. Melléklete II. 7. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szerv által kiírt pályázatokkal összefüggő adatokat az Eitv. Melléklete II. 10. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szervnél végzett alaptevékenységgel kapcsolatos adatokat az Eitv. Melléklete II. 11. pontjában meghatározott módon és tartalommal Feltüntették-e a közfeladatot ellátó szerv feladatellátására vonatkozó adatokat az Eitv. Melléklete II. 12. pontjában meghatározott módon és tartalommal Feltüntették-e a közérdekű adatok megismerésére irányuló igényekel összefüggő adatokat az Eitv. Melléklete II. 13. pontjában meghatározott módon és tartalommal Feltüntették-e a közfeladatot ellátó szerv tevékenységére vonatkozó adatokat az Eitv. Melléklete II. 14. pontjában meghatározott módon és tartalommal Feltüntették-e a közérdekű adatokkal kapcsolatos kötelező statisztikai adatszolgáltatásra vonatkozó adatokat az Eitv. Melléklete II. 15. pontjában meghatározott módon és tartalommal Feltüntették-e azon közérdekű adatok hasznosítására irányuló szerződésekre vonatkozó adatokat az Eitv. Melléklete II. 16. pontjában meghatározott módon és tartalommal Feltüntették-e a közfeladatot ellátó szerv kezelésében lévő közérdekű adatokra vonatkozó adatokat az Eitv. Melléklete II. 17. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladato ellátó szervre vonatkozó különös és egyedi közzétételi listát


152


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


153


megnevezését (típusa) tárgyát a szerződést kötő felek nevét a szerződés értékét határozott időre kötött szerződés esetében annak időtartamát vagyonértékesítésre vonatkozó szerződések megnevezését (típusa) tárgyát a szerződést kötő felek nevét a szerződés értékét határozott időre kötött szerződés esetében annak időtartamát vagyonhasznosításra vonatkozó szerződések megnevezését (típusa) tárgyát a szerződést kötő felek nevét a szerződés értékét határozott időre kötött szerződés esetében annak időtartamát vagyon, vagy vagyoni értékű jog átadására vonatkozó szerződések megnevezését (típusa) tárgyát a szerződést kötő felek nevét a szerződés értékét határozott időre kötött szerződés esetében annak időtartamát koncesszióba adásra vonatkozó szerződések megnevezését (típusa) tárgyát a szerződést kötő felek nevét a szerződés értékét határozott időre kötött szerződés esetében annak időtartamát Megjelenítették-e a közfeladatot ellátó szerv által nem alapfeladatai ellátására fordított, 5 millió forintot meghaladó kifizetéseket társadalmi szervezet támogatás esetén foglalkoztatottai szakmai és munkavállalói érdekképviseleti szervei számára foglalkoztatottai, ellátottjai oktatási, kulturális, szociális és sporttevékenységét segítő szervezet támogatására alapítványok által ellátott feladatokkal összefüggő kifizetésekre

Javasolt ellenőrzési terv Megjelenítették-e a közfeladatot ellátó szervre vonatkozó adatokat az Eitv. Melléklete III. 1. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szervnél foglalkoztatottak létszámára és juttatásaira vonatkozó adatokat az Eitv. Melléklete III. 2. pontjában meghatározott körben, módon és tartalommal Megjelenítették-e a közfeladatot ellátó szerv költségvetéséből nyújtott nem normatív támogatások kedvezményezettjeire vonatkozó adatokat az Eitv. Melléklete III. 3. pontjában meghatározott módon és tartalommal céljellegű támogatások kedvezményezettjeire vonatkozó adatokat az Eitv. Melléklete III. 3. pontjában meghatározott módon és tartalommal fejlesztési támogatás kedvezményezettjeire vonatkozó adatokat az Eitv. Melléklete II. 3. pontjában meghatározott módon és tartalommal Megjelenítették-e az államháztartás pénzeszközei felhasználásával, az államháztartáshoz tartozó vagyonnal történő gazdálkodással összefüggő - a külön jogszabályban meghatározott értékű árúbeszerzésre vonatkozó szerződésekkel összefüggő adatokat az Eitv. Melléklete III. 4.


154


pontjában meghatározott módon és tartalommal építési beruhárzásra vonatkozó szerződésekkel összefüggő adatokat az Eitv. Melléklete III. 4. pontjában meghatározott módon és tartalommal szolgáltatás megrendelésre vonatkozó szerződésekkel összefüggő adatokat az Eitv. Melléklete III. 4. pontjában meghatározott módon és tartalommal vagyonértékesítésre vonatkozó szerződésekkel összefüggő adatokat az Eitv. Melléklete III. 4. pontjában meghatározott módon és tartalommal vagyonhasznosításra vonatkozó szerződésekkel összefüggő adatokat az Eitv. Melléklete III. 4. pontjában meghatározott módon és tartalommal vagyon vagy vagyoni értékű jog átadására vonatkozó szerződésekkel összefüggő adatokat az Eitv. Melléklete III. 4. pontjában meghatározott módon és tartalommal A koncesszióról szóló törvényben meghatározott nyilvános adatokat az Eitv.Melléklete III. 5. pontjában meghatározott módon és tartalommal Megjelenítették-e a közfeladatot ellátó szerv által nem alapfeladatai ellátására fordított, 5 millió forintot meghaladó kifizetésekkel összefüggő adatokat az Eitv. Melléklete III. 6. pontjában meghatározott módon és tartalommal

8.3.5 Várólistával kapcsolatos adatok A törvényi előírások alapján megjelenítendő és ellenőrizendő tartalom. Megjelenítették-e az egészségügyi ellátásra várakozó betegek várólistára kerülési sorrendjének kialakítására vonatkozó szempontokat a várólistára kerülő beteg kiválasztásának szakmai szempontjait egészségügyi adatait személyazonosító adatait kiválasztásukat indokoló körülményeket

Javasolt ellenőrzési terv A várólistán szereplő adatok közül a honlapon közzétételre kerültek-e a 46/2006. (XII. 27.) EüM rend. 1. § (1) bek. szerinti adatok A közzétételre statikus html oldalon került sor (1. § (2) bek.) A közzétételre várólista-kezelő számítógépes programmal került sor (1. § (2) bek.) A közzétételre intézményi integrált informatikai rendszer várólista-kezelő modulja révén került sor (1. § (2) bek.) A várólistán szereplő adatok közül a honlapon közzétételre kerültek-e a beteg személyazonosító adatai (rend. 1. § (1) bek.)


155


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

Javasolt ellenőrzési terv Megjelenítették-e a költségvetési év elején, legkésőbb április 15-ig az éves összesített közbeszerzési tervet (Kbt. 5. § (1) - (2) bek.) ha módosították a közbeszerzési tervet, annak módosításait (5. § (2) bek.) 5 munkanapon belül szerepeltették-e a közbeszerzési tervben a terv elkészítése előtt - ha volt - indított közbeszerzési eljárás(oka)t (5. § (3) bek.) Megjelenítették-e közbeszerzési eljárásonként csoportosítva 5 munkanapon belül a közbeszerzési eljárást megindító hirdetményt (17/C. § (1) bek.a) pont) az eljárás eredményéről vagy eredménytelenségéről szóló tájékoztatót tartalmazó hirdetményt (17/C. § (1) bek. b) pont) 99. § (4) bek. Szerinti szerződéseket 17/C. § (1) bek. D) pont)


156


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


157

Telemedicina

8.4 A telemedicina alkalmazásának telemedicina rendszerkövetelményei

helyzete

Magyarországon,

a

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

Nem igen lehetett támogatásnak nevezni azt a lendülettelen hozzáállást, amelyet a kormányzat – különösen az egészségügyi adminisztráció – a témával kapcsolatban tanúsított.


158

Telemedicina

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

159

Telemedicina

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

160

Telemedicina

működési, biztonsági és felelősségi kérdések teljes körű megoldását. Ezekkel felvértezve, kétség sem férhet ahhoz, hogy a rendszer megbízható. 8.4.4 Jogszabályi környezet. A telemedicina rendszerben milyen eljárások garantálják a betegadatok védelmét? Lehetséges-e a betegadatokat feldolgozni egy telekommunikációs szolgáltatónak, aki a kapcsolatot üzemelteti, és a betegadatokat temporáris állományokba gyűjti? Lehet-e a beteg adata a beteg vagy az egészségügyi szolgáltató hatókörén kívül? A hozzáférésnek milyen erősségű azonosítási rendszer felel meg? Ezekre a kérdésekre még ma nincs válasz. Ennek ellenére a telemedicina alkalmazások az ipari lobby feszítésére terjednek. Ezért alapvető informatikai követelmények megfogalmazhatóak: X-1-001

A telemedicina rendszer valós ellátási igényt elégítsen ki

X-1-002

A rendszer az orvos számára adekvát információkat szolgáltasson

X-1-003

A rendszer a betegadatokat a hatályos jogszabályoknak megfelelően kezelje Amennyiben a rendszer üzemeltetésében az ellátásban érintett egészségügyi intézményen kívüli szervezet is részt vesz, csak a beteg felhatalmazása mellett kezelheti a beteg adatait A telemedicina rendszer csak orvosi felügyelet mellett működtethető, vagy úgy, hogy a betegadatokat orvosi háttér értelmezi és tesz beavatkozásokat A telemedicina rendszerben alkalmazott diagnosztikai készülékek érvényes minősítéssel kell rendelkezzenek A betegadatokat csak védett csatornán lehet továbbítani Azt a telemedicina rendszert, amely a beteggel szoros kapcsolatban működik (szenzorok, jeltovábbítók, stb), csak a beteg hozzájárulásával lehet alkalmazni A teleradiológiai és telepatológiai rendszerekben dolgozó leletező szakorvos számára a beteg személyes adata nem lehet hozzáférhető, csak „elkódoltan” lehet az esethez tartozó objektumot (képet, stb.) azonosítani A beteg környezetében alkalmazott telemedicina rendszer érvényes érintésvédelmi tanúsítással kell rendelkezzen A telemedicina rendszer, annak személyes szenzorai a beteget sértő, megalázó vagy emberhez méltatlan helyzetbe nem hozhatják A telemedicina rendszer által gyűjtött esetadatok csak beteg beleegyezése mellett, személyes adatoktól megtisztítottan lehet más – pl. statisztikai – célra felhasználni A telemedicina rendszer működtetésének a betegre vonatkozó részleteiről a beteget pontosan ki kell oktatni, számára írásos dokumentumot kell biztosítani erről.

X-1-004 X-1-005 X-1-006 X-1-007 X-1-008 X-1-009 X-1-010 X-1-011 X-1-012 X-1-013


161

NFM IT követelményrendszer integrálása

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

162


folyamataira épülnek. A folyamatoktól független, informatikai és infrastrukturális konszolidációt a teljes közigazgatás szintjén lehet maradéktalanul teljesíteni, ezen felül az alkalmazások szintjén is felmerülnek konszolidációs lehetőségek. Az intézkedési terv a központilag végrehajtható racionalizálási feladatokat tartalmazza (lásd később). A felmérés folyamata A végrehajtandó feladatok kijelölését átfogó elemzés előzte meg, amelyet a 1277/2010. (XII. 9.) kormányhatározat alapján végzett el 5 tárcaközi munkacsoport a Nemzeti Fejlesztési Minisztérium koordinálásában. Az elemzés és értékelés a kormányhatározat alapján kiterjedt valamennyi minisztériumra, valamint a minisztériumok által felügyelt valamennyi szervre, a gazdasági társaságok kivételével. Ez a központi közigazgatási intézményekkel együtt összesen 176 szervezet infokommunikációs tevékenységének felmérését jelentette. Az elemzés négy fő szempont mentén készült: az informatikai infrastruktúra felkészültségét; a humán-erőforrások képességeit, releváns tapasztalatát; az informatikai szabályozás minőségét; valamint az informatika szerződéses és pénzügyi jellemzőit vizsgálta. Ezen belül a 2008-tól 2010-ig terjedő periódusra koncentrált. A felmérés alapjául szolgáló kérdőívet a Nemzeti Fejlesztési Minisztérium állította össze 2010 decemberében. A kérdőív az informatikai infrastruktúra és szolgáltatások igénybe vételének alábbi kérdéseire tért ki: • a központi és végfelhasználói hardver elemek, a központi és a munkaállomásokon üzemelő szoftver elemek • számítógépes hálózat (lan-wan), a teljes informatikai struktúra, illetve az egyes adatbázisok közötti adatkapcsolat • informatikai szervezeti felépítés, a szervezeti működési szabályzatok, az informatikai létszám bemutatása • szerződéses kötelezettségvállalások, illetve a 2008-2009 és 2010-es évekre szóló informatikai kiadások • a szervezetek informatikai fejlesztési tervei A feldolgozást az egyes minisztériumok, így a NEFMI-GYEMSZI által is delegált szakértők végezték. Az értékelés és feldolgozás alapján lehetővé vált a fejlesztési javaslatok és a hatékonyság-javító intézkedési terv összeállítása 8.5.2 Az egészségügyi információs rendszerkövetelmények anyag megfelelése kormányzati infokommunikációs konszolidációs intézkedési tervben leírtakhoz

a

Az NFM infokommunikációs konszolidációs intézkedési terve a központi költségvetési szférára, vagyis a minisztériumok és háttérintézményeik infokommunikációs tevékenységeire vonatkozik, alsóbb szintű regionális, vagy megyei szintű, vagy más ellátórendszerben, így az egészségügyben működő állami fenntartású intézményekre nézve ajánlásokat tud adni (már amennyiben azok relevánsak). A GYEMSZI és az NFM Kormányzati Informatikai Helyettes Államtitkárság közös álláspontja, hogy a jelen, egészségügyi információs rendszerek követelményei anyag kapcsán összevetésre, illetve beépítésre kerüljenek a kormányzati infokommunikációs konszolidációs intézkedési terv vonatkozó részei. A két alapos szakértői előkészítés után létrejött anyag egymáshoz felelését a következő táblázatban ismertetjük:


163


NFM infokommunikációs konszolidációs intézkedési terv Témakör

Feladat / Intézkedés

Vonatkozó rész

Intézkedési terv készítése a kormányzati végfelhasználói és központi infokommunikációs infrastruktúra biztosítását és üzemeltetését biztosító kedvezőbb ár-érték arányú technológiák alkalmazásáról

A vonatkozó központi intézkedések annyiból relevánsak egészségügyi informatikai szempontból, hogy a 3. „Központi kormányzati egészségügyi informatikai fejlesztések, a rendszerkövetelmények anyag illeszkedése” 3.1.4 részben leírt, GYEMSZI által megvalósítani kívánt core-saas központ látná el szolgáltatásokkal, alkalmazásokkal az alap-, járó- és fekvőbeteg intézményeket a 4. részben ismertetett követelmények betartása szerint (ez összhangban van azzal, hogy a központi közigazgatásban központosított infrastruktúra üzemeltetés lép életbe a jövőben). Így a központi kormányzati intézményi-informatikai szinthez hasonlóan az egészségügyi ellátórendszer egységeinél is megtakarítás érhető lenne el egyes, főleg a szoftver, IT szolgáltatási, de a felhőalapú technológiákra áttéréssel a hardver típusú infokommunikációs költségek vonatkozásában is.

Végponti IT szolgáltatások Kormányzati végfelhasználói és kiterjesztése központi infokommunikációs infrastruktúra konszolidált biztosítása és üzemeltetésének kiterjesztése a 168/2004. (V. 25.) Korm. rendelet 1. §-ában meghatározott szervek számára

A központi kormányzati szoftverlicenc-, és szoftver támogatási-követési szolgáltatásLicensz-, és gazdálkodásért felelős végrehajtó supportszervezet kialakítása, amelytől a gazdálkodás 168/2004. (V. 25.) Korm. központosítása rendelet 1. §-ában meghatározott szervek veszik igénybe a szolgáltatásokat

Informatikai fejlesztések konszolidációja

GYEMSZI Egészségügyi információs rendszerek követelményei

Az állam által meghatározott szoftverektől, szerzői jogi jogosultaktól való függés, és az ezzel kapcsolatos kockázatok mértékének csökkentéséért felelős szervezet létrehozása


Lásd előző cella. Ezenkívül fontos, hogy a 4. részben mind a szofver beszerzés/fejlesztés, mind az üzemeltetés – support licenszgazdálkodás kapcsán meg vannak fogalmazva testreszabott követelmények az egészségügyi intézményekre nézve, összhangban a központi kormányzati informatikai elvárásokkal. Az egészségügyi információs rendszerkövetelmények kialakításának fontos célja, hogy az intézmények IT szállítói függését csökkentsük, illetve, hogy a beszállítóiktól egységes elvárások szerinti szolgáltatási szinteket és rendszerképességeket kapjanak. Ennek fényében lettek kialakítva az anyag 4. és 5. fejezetei (illetve azok tartalmai), így elérhető, hogy az egészségügyi informatikában megfelelő minőséget nyújtó és árazású szállítók működjenek közre magas színvonalú infokommunikációs termékekkel és szolgáltatásokkal. A felállítani javasolt, egészségügyi ágazati koordinációs szerepet betöltő GYEMSZI-n belüli minősítő rendszer és szervezet (lásd 6. fejezet) a központi kormányzatban hasonló célt szolgáló intézménnyel összhangban, annak

164


iránymutatásai alapján kellene, hogy működjön.

A 4. és 5. fejezetben leírt követelmények a specifikációik szerint meghatározzák illetve megszabják azon megoldások körét, amelyeket a jövőben használniuk kellene az egészségügyi intézményeknek , ezáltal az ágazaton belül is Informatikai alkalmazások megvalósul (a rosszabb minőségű, szakmailag konszolidációjának végrehajtása kifogásolható szállítók és azok rendszereinek kiszűrésével) egyfajta alkalmazáskonszolidáció. Ezt az is segíti, hogy várhatóan az egészségügyi (lásd 3.1.4 rész: TIOP 2.3.1) core-saas központ egyes szolgáltatásai (lásd pl. e-recept, háziorvosi rendszer) is el fognak indulni.

Alkalmazások üzemeltetésének konszolidációja

A szerverek és a hosting vonatkozásában az anyag 4.1 és 4.5 részei tartalmaznak követelményeket az egészségügyi Kormányzati központi szerver-, intézményekre nézve. Ugyanakkor ismét a coreés alkalmazás-elhelyezési saas központban megvalósítani, szolgáltatni (hosting) szolgáltatás kialakítása kívántakra hivatkozva azok igénybevételével az intézményi hardverjellegű költségek csökkenthetők. Előterjesztés készítése a felhő alapú alkalmazásfuttatási modellről és a szabványos, központi üzemeltetésű informatikai alkalmazásoknak különösen a közigazgatási szervek folyamataiban történő bevezetéséről

Az anyag 4. fejezetében leírt követelmények vonatkoznak a felhőalapú rendszerekre is (illetve külön jelöljük, ha esetleg nem). A coresaas központ maga is felhőalapú szoftverszolgáltatásokat is fog szolgáltatni, ezáltal teljesül az ágazatban a központi kormányzati infokommunikációs elvárásokhoz való igazodás.

A legfontosabb állami nyilvántartások számára kiemelt fizikai biztonságot nyújtó állami megoldás kialakítására vonatkozó intézkedési terv elkészítése

Az egészségügyi intézmények biztonsági követelményeit (amelyek igazodnak az általános kormányzati informatikai elvárásokhoz, de nyílván a releváns körre vonatkoznak) elsősorban a 4.1.6 IT biztonsági követelmények és a 4.5.1.5 Informatikai biztonság menedzsment részek taglalják.

Új, modulárisan felépített közbeszerzési portál létrehozása Infokommunikác (közbeszerzési, használteszköziós eszközök kezelési, selejtezési és beszerzésének jótékonysági ill. szállítóknál konszolidációja elfekvő készletek felhasználását lehetővé tevő modulokkal)

Úgy látjuk ez a központi kormányzati intézkedés nem releváns az egészségügyi rendszerkövetelmények vonatkozásában. Egyedül az 5.2.1. Beszállítói követelmények részben vannak infokommunikációs közbeszerzési témájú elvárások. Központi egészségügyi informatikai beszerzési portál elindításának tervéről nincs tudomásunk.

Igénybevett távközlési

A központi államigazgatási szervek összességét átfogó


Az intézkedések nem igazán relevánsak, mivel az egészségügyi rendszerkövetelmények anyag

165


vezetékes és mobil 4. fejezete csak az intézményi informatikai (és telefonszolgáltatás igénybevételi nem telekommunikációs!) rendszerek megfelelő (biztonságos) használatához kapcsolódó lehetőségeinek feltérképezése távközlési jellegű elvárásokat (pl. internetes A nemzeti informatikai sávszélesség igény, backup szükséglet, hálózat) alaphálózatok konszolidációja és tartalmazza. Egységes egészségügyi távközlési kiterjesztése lehetőség szerint hálózat kialakításáról, vagy annak minél több kistérségi központig, konszolidációjáról nem rendelkezünk településig információkkal, de a fejlesztésre kerülő nemzeti kormányzati informatikai A távközlési alaphálózatok egységes központi államigazgatási szervek, gerinchálózat szolgáltatásait az intézmények más államigazgatási szervek, várhatóan igénybe vehetik majd (legalábbis állami vállalatok és egyéb állami javasolt lenne).

szolgáltatások konszolidációja

Távközlési alaphálózat konszolidációja és kiterjesztése

szervezetek körében kötelező használatát megalapozó jogszabály-módosítások előterjesztése

Közigazgatási humánerőforrás fejlesztése

Az informatikai szakember gárda megtartását és az állami informatikai pozíciók vonzerejét biztosító, a közigazgatásban informatikai munkakörben dolgozó állami alkalmazottakra vonatkozó életpálya modell kidolgozása

Az egészségügyi informatikai humán erőforrással (szakemberekkel), tehát nem a felhasználókkal, kapcsolatban az anyag 4. (lásd 4.5.1.5.3; 4.5.1.5.5 részek), illetve 5. (lásd 5.1.1; 5.1.2) fejezete állít fel infokommunikációs és menedzsment jellegű követelményeket. A rendszerkövetelmények anyagtól függetlenül, de a kormányzati szintű törekvésekkel összhangban megjegyezzük, hogy az egészségügyben is szükség van az informatikai szakemberállomány fejlesztésére, képzésére, életpálya modell kidolgozására, erre a kulcsprojektek (lásd 3. fejezet) leírásaiban nem látunk utalást. Javasoljuk a leginkább releváns TÁMOP 6.2.7 (alapvetően képzési jellegű) projekt térjen ki erre is. Ágazati IT szakmai mátrixok és szakember-nyilvántartások felállítása is a kormányzati intézkedés része, értelemszerűen ez érinti az egészségügyet is.

Nem releváns intézkedési javaslat, illetve az egészségügyi intézményeknél nem célszerű országos szintű videokonferencia-rendszerben gondolkodni (a 3. részben tárgyalt kiemelt Országos videokonferencia- kormányzati projektek nem is célozzák annak rendszer kiépítése megvalósítását). Ugyanakkor az egészségügyi intézményi csoportmunka rendszerekkel kapcsolatban az anyag (lásd 4.3.2.3 rész) tesz elvárásokat. Informatikai szabályozás informatikai szervezete

A közigazgatási informatika és szabályozottságának javítása érdekében szabályrendszerek kidolgozása A pénzügyi elszámolási és szerződéses gyakorlat fejlesztése


Az egészségügyi információs rendszerek anyag szempontjából leginkább releváns kormányzati infokommunikációs konszolidációs intézkedési javaslatok, ezért ezeket külön részben tárgyaljuk (lásd 8.5.3)

166


A költségvetési szervek informatikai szervezetének felépítésére vonatkozó ajánlás készítése

8.5.3 Informatikai szabályozás és informatikai szervezete – kormányzat / egészségügy A központi közigazgatás informatikai szabályozása és informatikai szervezetének feltételeinek rendbetétele kapcsán a következőket kívánja elérni a felelős szaktárca: • A közigazgatási informatika szabályozottságának javítása érdekében szabályrendszerek kidolgozása

• A pénzügyi elszámolási és szerződéses gyakorlat fejlesztése • A költségvetési szervek informatikai szervezetének felépítésére vonatkozó ajánlás készítése Ezen célok kormányzati szinten törtnő megvalósításának érdekében a következő intézkedéseket javasolják (az egyes javasolt beavatkozások mellett feltüntettük, hogy hogyan illeszkedik az egészségügyi információs rendszerkövetelmények anyag): NFM által javasolt, kormányzati szintű javasolt szabályozásiszervezeti jellegű intézkedések

Egészségügyi információs rendszerkövetelmények anyag illeszkedése

A. IT specifikus szabályozási javaslatok 1. Az informatikai szabályozási Maga a rendszerkövetelmények anyag elvárásokat fogalmaz elvárások egyértelmű meg (igaz nem jogszabályszerűen) az egészségügyi informatikai fejlesztések, rendszerek vonatkozásában úgy, megfogalmazása hogy megfelelően informálja, egyértelműen felvilágosítja a Elemei: célcsoportot, az ellátórendszerben működő intézmények • az informatikai szabályozási informatikai vezetőit, szakembereit. A tudatosság növelése rendszerkövetelményekből következő jogszabályi átültetés (vagy legalábbis javaslat annak módjára) az EIT • megfelelő információk (pl. mi a rendeletelemzés munkacsoport feladata. kormányzati stratégia), elemzések, tájékoztatók eljuttatása a felelősöknek 2. Egységes központi iránymutatások: Fontos, hogy az egységes informatikai szabályozás kialakításánál a következő elvek érvényesüljenek: a) Módszertan b) Szabályozási térkép c) Szójegyzék d) Központilag kialakított belső szabályozás e) Működtetés központi

A rendszerkövetelmények anyag a felsorolt kormányzati szintű paraméterek közül gyakorlatilag valamennyihez illeszkedik, a következőképpen: a) az anyag sorvezető az ágazati informatikai fejlesztések, üzemeltetés és projektmenedzsment vonatkozásában b) egyfajta térkép is, hiszen gyakorlatilag az informatika teljes spektrumát felöleli c) tartalmaz szószedetet, megmagyarázza az alapvető dolgokat, egységesen kezeli a fogalmakat d) e) ágazati központi intézmény számára (GYEMSZI) készül f) megjelöli a központi és alsóbb szintű intézmények egymáshoz való viszonyát g) megkülönbözteti a kötelező és opcionális


167


szabályozása f) Szervezetek kapcsolata g) A kötelező és ajánlott szabályzók elválasztása h) Projektmenedzsment i) Tárcák együttműködése j) Audit k) Alkalmazásvédelem l) Allokáció (az elkészült szabályzásokat belső szabályozási hierarchiájában a megfelelő szintre kell elhelyeztetni).

követelményeket h) külön projektmenedzsment kézikönyvet tartalmaz i) mind a NEFMI és alá tartozó szervezetek (GYEMSZI, OEP), mind az NFM részt vesznek kidolgozásában, validálásában, elfogadásában j) felvázolja az optimális minősítési rendszert és annak intézményét k) megfogalmaz biztonsági elvárásokat az ágazatban működő informatikai rendszerekre nézve l) a GYEMSZI felsővezetés számára készül, így annak jóváhagyásával alsóbb szinten is elfogadásra kell, hogy majd kerüljön m) nem terjeszkedik túl az intézmények jelenleg törvényileg szabályozott hatáskörén, nem ér el túlszabályozottságot n) a mellékletben külön fejezet foglalkozik a nemzetközi követelményekkel, gyakorlatokkal o) még az ágazati stratégia projektek elindulása előtt jelenik meg, azokhoz megfelelő alapot ad.

m) Elégséges szabályzás elérése n) Benchmark projektek o) Időzítés 3. A helyi intézményi tudásszint Maga az anyag tájékoztatást, iránymutatást ad az egészségügyi ellátórendszer informatikai stakeholder-ei növelése számára, vagyis azok tudásszintjét növeli. A másik elemmel Elemei: kapcsolatban annyit jegyeznénk meg, hogy a GYEMSZI• lokális (intézményi) szintű nek (a felsővezetésnek) kell majd eldöntenie, hogy a tudásszint növelése rendszerkövetelményeket milyen formában fogja tálalni az ágazati érintetteknek. • szervezeti felelősök elérhetőségének biztosítása, azok folyamatos tájékoztatásának, képzésének érdekében 4. Átfogó felügyeleti rendszer A kialakítani javasolt, GYEMSZI-n belüli minősítő szervezet (vagy annak egy kibővített egysége) célszerű kiépítése volna (és tudomásunk szerint ez is a terv), hogy az Központi menedzsment kialakítása, egészségügyi ágazaton belül informatikai felügyeleti amely a kormányzat részéről szakmai szerepet is ellásson az intézmények felé, így az összhang felügyeletet gyakorol a szervek biztosítva lenne a kormányzati szinttel. Megjegyezzük, szabályzórendszere és annak hogy az Egészségügyi Informatikai Tanács egyébként már végrehajtása felett, méghozzá a szerv most is (igaz magasabb szinten) betölt ilyen jellegű által létrehozott és működtetett funkciót. felügyeleti szerven keresztül 5. Rendszeres kapcsolattartás a Közvetlenül az anyag kapcsán nem releváns intézkedés. A jogalkotó és a jogalkalmazók NEFMI-nek, illetve a GYEMSZI-nek nyilván részt kell majd vennie a tárcaközi bizottságban. között


168


• szükséges a kormányzati direktívák folyamatos implementálása • állandó jellegű tárcaközi bizottság kialakítása B. Az informatikai pénzügyi szabályozás A költségvetési szférában az informatikai üzemeltetést és fejlesztést érintő pénzügyi felelősség megalapozására szükségesnek látjuk az alábbi feladatok mielőbbi végrehajtását: 1. Megrendelői-szolgáltatói kialakítása

viszony A központi költségvetés – intézmények – informatikai tevékenység finanszírozás kérdés nem a dokumentum kompetenciája.

2. Szolgáltatási szintek definiálása

Egészségügyi intézményekre vonatkozó informatikai szolgáltatási kötelezettség színvonalával kapcsolatos SLA követelményeket tartalmaz az anyag 4.5 Üzemeltetési fejezete. (elsősorban a 4.5.1.2 Szolgáltatás szint menedzsment rész).

3. EU források bevonhatósága (ne az Az nem a rendszerkövetelmények dokumentum üzemeltetésre) kompetenciája, hogy javaslatot tegyen arra, hogy az egyes intézmények miből finanszírozzák informatikai költségeiket (azzal maximálisan egyetértünk, hogy üzemeltetési kiadásokat nem lehet, és nem szabad hagyni EU-s forrásokból fedezni). 4. Szerződéstípusok előírása

Az anyag külön részben (5.3.3 A fejlesztéssel kapcsolatos szerződésháló kialakításának követelményei) foglalkozik az egészségügyi intézménybeszállító informatikai szerződések javasolt tartalmával.

5. Beszállító független megoldások

A 4. részben maximálisan arra törekedtünk, hogy az egyes követelmények ne legyenek csak egyes szállítók által teljesíthető elvárások, így garantáltuk a megoldás és informatikai beszállító függetlenséget, annak szem előtt tartásával, hogy az egészségügyben beszerzésre kerülő informatikai eszközöknél, rendszereknél jól bevált termékek, szolgáltatások, technológiák, és az azokat kínáló magas szakmai színvonalú informatikai cégek kerülhessenek előtérbe.

6. Alkalmassági követelmények

A beszállítók alkalmassága kapcsán az anyagban külön követelményrészt jelenítettünk meg (lásd 5.2 A beszállító felkészültségének és ajánlatának követelményei).


169


C. Szervezeti keretek Az anyag szempontjából annyiban releváns az intézkedésjavaslat, hogy a központi informatikai felelős Elemei: minisztérium iránymutatásai alapján (lásd az NFM delegált • központi kormányzati felelős részvételét a munkacsoportban és a jelen fejezetet) az minisztérium (NFM) kijelölése egészségügyi ágazatban az informatikai feladatok jogosítványokkal koordinálására kijelölt EIT és GYEMSZI megrendelésére, • ágazati szintű felelős szervezetek azok elvárásainak beépítésével készül. Az informatikai kijelölése jogosítványokkal vezetők premizálásával kapcsolatban jó ötletnek tartjuk • informatikai vezetők premizálása ösztönző megoldások bevezetését egészségügyi intézményi szinten. 1. Irányítás:

informatikai A dokumentumban az 5.1.2 Intézményi követelmények a fejlesztés előkészítésére részben van rá utalás, hogy az egészségügyben (értelemszerűen a fekvő- és járóbeteg Elemei: • informatikai szervezet helyének ellátóknál) milyen elvárások vannak az intézményen belül az informatikai szervezet helyével, a menedzsmenttel kijelölése a szervezetekben • informatikai átvilágítás szervezeti kapcsolatban. 2. Intézményi szervezetek

átalakítás előtt 3. Informatikát érintő szabályozás Maga a rendszerkövetelmények anyag elvárásokat fogalmaz meg (igaz nem jogszabályszerűen) az egészségügyi megismertetése informatikai fejlesztések, rendszerek vonatkozásában úgy, Elemei: hogy megfelelően informálja, egyértelműen felvilágosítja a • Informatikával kapcsolatos célcsoportot, az ellátórendszerben működő intézmények vezetőit, szakembereit. A jogszabályi kötelezettségek informatikai rendszerkövetelményekből következő jogszabályi átültetés összegyűjtése (vagy legalábbis javaslat annak módjára) az EIT • Hírlevél jelleggel vagy portálon rendeletelemzés munkacsoport feladata. A másik elemmel történő tájékoztatás kapcsolatban annyit jegyeznénk meg, hogy a GYEMSZInek (a felsővezetésnek) kell majd eldöntenie, hogy a rendszerkövetelményeket, illetve a hivatkozott jogszabály változtatásokat milyen formában fogja tálalni az ágazati érintetteknek.

8.5.4 Konklúzió Megállapítható, hogy az egészségügyi információs rendszerkövetelmények anyag tartalma gyakorlatilag teljes összhangban van a kormányzati szintű informatikai elvárásokkal, intézkedésjavaslatokkal úgy hogy figyelembe veszi az ágazat specifikumait és azt, hogy nem központi költségvetési intézmények érintettek elsősorban.


170


9 A dokumentum szerzői A dokumentum szerzői, a GYEMSZI szakértői munkacsoportjának tagjai: Adányi Balázs Berky Tamás Fogarassy Károly Gazdagh Pál Kövesdi Zoltán Nagy István Dr. Valovics István A dokumentumot véleményezték, az egyeztető üléseken részt vettek: Dr. Fónyad Gábor Bizzer László Csuzi Szilvia Frányóné Németh Angéla Pári Mónika Somogyi László Surguta András Dr. Surján György A szerzők fejezetenként: Fejezetcím

Felelős szerző

1. Bevezető

Fogarassy Károly

2. Szószedet

A szerzők

Társszerzők

3. Központi kormányzati egészségügyi Kövesdi Zoltán informatikai fejlesztések, a rendszerkövetelmények anyag illeszkedése

Gazdagh Pál

4. Az informatikai követelményei

Adányi Balázs, Fogarassy Károly, Gazdagh Pál, Kövesdi Zoltán

rendszerek Nagy István

5. A fejlesztési pályázat és a Dr. Valovics István megvalósítási projekt követelményei, minősítése

Nagy István

6. A követelmények alapján folytatott Fogarassy Károly minősítés módszertana, folyamata és Összeállította a GYEMSZI szakértői munkacsoportja

171


szervezete 7. Javasolt jogszabályi változtatások

Nagy István

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


172

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

Recommend Documents