RE: EEIR, avagy a magyar egészségügy villamosítása

2008.06.13. 14:52 bs395

Dr. Morcz elkövetett egy kintűnő posztot a magyar egészségügy (és úgy általában az állami szervek és szolgáltatások) egyik komoly problémájáról, azaz az információ áramlás és rögzítés hiányosságairól.

A kommentek között felmerült, hogy ennek az esetleges professzionális megoldása miért kerülne pusztán üzemeltetésileg is havi több száz millió forintba, éves szinten akár 2-3 milliárdba? (és erre rakódna rá a tárgyi eszközök beszerzése és az infrastruktúra kialakítása előzményként, amiknek a költségeit még megbecsülni sem merem)

Az ár kérdése - mint mindig - attól függ, hogy mik az elvárások. A klasszikus elvárások egy informatikai rendszerrel kapcsolatban a következők: nagy rendelkezésre állás, maximális adatbiztonság, alacsony válaszidő, bővíthetőség és átadhatóság. Hogyan lehet ezeket mind megvalósítani, és az miért ilyen drága?

Kezdjük az elején. Milyen formában kívánjuk ezt megvalósítani? A 100%-os kiszervezést ilyen kényes és érzékeny adatoknál én magam se támogatom, hiszen hiába tulajdonosa az állam az adatoknak, ha a szolgáltatóban nincs tulajdonrésze, úgy csak körülményesen tudja azok biztonságát és az egyéb folyamatok betartását felügyelni. Teljesen állami tulajdonban üzemeltetve a költségeket és a hatékonyságot képtelenség kézben tartani, hiszen ha az állam saját magával szerződik, az azt jelenti, hogy pártalkuk kérdésévé degradálnánk, és teletömnénk káderekkel, majd az egészet megfejelnénk közbeszerzéssel és a költségvetés - így a szolgáltatásra szánt összeg - percenkénti újraszabásával, vagyis tömören tervezhetetlen és felügyelhetetlen lenne.

Maradna egy vegyesvállalat, ami természetesen azt is magában hordozza, hogy egyrészt a privát partnernek az állam nem csupán működési költséget, hanem hasznot is fizet, továbbá a szerződéses tételek az államháztartás pillanatnyi állapotától és a tényleges működési költségektől függetlenek lennének, viszont mind az állam, mind a privát partner osztoznának a kockázaton is.

A kockázatvállalást és a szolgáltatást az úgynevezett szolgáltatási szint szerződés (SLA) szabályozza. Fő eleme - sok egyéb paraméter, így a már említett válaszidő és biztonság mellett - a rendelkezésre állás: ennek a kitételnek a teljesülése határozza meg az üzemeltetés költségeinek a fő számait. A rendelkezésre állás pusztán egy 0 és 100 közötti százalék, mondjuk 99.96%. Ez azt jelenti, hogy a szolgáltatás adott paraméterekkel és egyéb feltételek nem sérülésével a szerződésben meghatározott időtartam 99.96%-ban elérhető, nem számítva a tulajdonos kéréseiből és az esetleges rendszeres karbantartásból és egyéb, szintén szerződött rendszeres tevékenységekből származó kieséseket vagy lassulásokat.

Egy országos egészségügyi nyilvántartó rendszernél, amiben nem csupán a társadalombiztosítási jogállást és egyéb alapadatokat tartanánk nyílván, hanem valamennyi beteg teljes kórtörténetét, a szerződéses időtartam napi 0-24 óra, évi 365 nap - vagyis non-stop szolgáltatás. Ebben az esetben a 99.96%-os rendelkezésre állás azt jelenti, hogy az év 8760 órájából a szolgáltatás kiesés 3.5 óra lehet - a cél ugyanis az, hogy az egészségügyi szolgáltatás NEM ÁLLHAT MEG! Amennyiben ez nem teljesül, úgy a szolgáltató súlyos kötbért fizet, rosszul megtervezett szolgáltatásnál akár veszteséges is lehet (előfordul a nagyokkal is).

Hogyan lehetséges egy ilyen első látásra irreálisnak tűnő feltételt teljesíteni? Redundanciával.

Telephely (site)
A szolgáltató cégnek négy telephellyel kell rendelkeznie: két szerverközponttal, egy felügyeleti központtal, és egy tartalék felügyeleti központtal. A két szerverközpont teljesen azonosan van felszerelve, azaz minden eszközt és beszállítói szolgáltatást duplán kell kalkulálni. Az elsődleges felügyeleti központ és a tartalék felügyeleti központ felszereltsége eltérhet az elsődleges javára.
Miért kell a telephelyet duplázni?

Csinálunk egy szerverközpontot Budapestre, egyet meg mondjuk Debrecenbe. Amennyiben a budapestivel bármi történne - elvágják az áramot, a hálózati kapcsolatot, elárasztja a víz, tűz üt ki, elfoglalja az alkotmányozó nemzetgyűlés - úgy a szolgáltatást fél órán belül vissza kell állítani, ez pedig csak úgy lehetséges, ha van tartalékban egy ikre, aminek az üzembe helyezéséhez elég az interneten elfordítani néhány kapcsolót, és máris oda érkeznek a bitek - ez persze azt is jelenti, hogy a debreceni központ is folyamatosan teljes árammal üzemel, és várja, hogy történik-e bármi baj a budapestivel. A távolság az olyan események miatt indokolt, amik tartósan ellehetetlenítik akár egy egész város működését is: földrengés, árvíz, lázongások - mindaz, amit egy biztosítás kötésekor a vis major apró betűs magyarázata alatt találnánk. Vagyis a továbbiakban minden olyan költséget, ami a szerverközponttal kapcsolatos, tessék fejben megszorozni kettővel.

A felügyeleti központ duplázása is ugyanezen okokból indokolt. A hatékony üzemeltetés megoldásához komoly felügyeleti infrastruktúra tartozik, ellenkező esetben az üzemeltetéshez szükséges információk hatékony feldolgozása sérül, és az esetleges problémákra adott korrektív válaszreakciók késnek. A másodlagos felügyeleti központ szükségmegoldásként van tartalékban, vagyis a szerverközponttal ellentétben használaton kívül nem üzemel. A felügyeletet ellátók képzése és az információk kényes volta miatt a személyzetet nem lehet duplázni, így a két felügyeleti központ szükségszerűen ugyanabban a régióban, egymástól maximum fél órányira található. Végszükség esetén megoldható az elosztott felügyelet is, amikor a felügyeletet ellátók az erre a célra kiosztott eszközökkel akár otthonról is képesek minimális szolgáltatást nyújtani, ám ha a helyzet eddig fajul, könnyen meglehet, hogy már nincs is szükség egészségügyre.

Mit kell még duplázni?

Induljunk az alapoktól. Duplázni kell a telephely áramellátását és hálózati kapcsolatát, külön szolgáltatókkal: ezekre azért van szükség, hogy ha bármilyen gond történne a fizikai infrastruktúrával, a szolgáltatás folytonossága ne sérüljön, továbbá, ha bármely szolgáltatóval kötött szerződéssel gondok lennének az alvállalkozó váltás is zökkenőmentes legyen. Minimum duplázni kell minden egyes szervert, amit funkciótól és a várható terheléstől függően lehet többszörözni is, így a terhelés a felhasználó számára láthatatlanul oszlik meg az azonos funkciójú gépek között. Az egyes szervereknek duplázni kell szintén az áramellátását, a hálózati hozzáférését, a belső tárhelyét paritással konfigurálni, valamint nem árt a belső hálózati eszközöket is redundánssá tenni.

Itt viszont már érintettük is az alacsony válaszidőt, a bővíthetőséget, és az adatbiztonságot - folytassuk a továbbiakban az utóbbival.

Adatbiztonság

A adatbiztonság egyrészt a szerverközpontok védettsége minden külső behatástól és behatolástól - akár fizikai, akár hálózati támadás -, másrészt annak a biztosítása, hogy bármely adatvesztés vagy sérülés esetén az adatokat vissza tudjuk állítani.

A fizikai védelem tulajdonképpen egy föld alatti bunkert jelent, ami véd akár egy rázuhanó repülőgéptől is, valamint védett az elektromágneses impulzusoktól. Maga az objektum nemzetbiztonsági szempontból a legmagasabb kategóriába kell, hogy tartozzon - csak gondoljunk bele, mivel járhat az itt tárolt adatok illetéktelen eltulajdonítása, így mind a védelemnek, mind a beléptető rendszernek és protokolloknak ezt kell tükrözniük. (ez mondjuk egy meghibásodott hardver eszköz cseréjekor, amikor a gyártó a garanciális szerződés alapján kiküldi saját technikusát a csereeszközzel, elég pikáns tud lenni - gyakorlatilag ott kell állnia mellette két embernek, akik nézik, amit a csavarhúzós ember csinál)

Szintén a fizikai védelemhez tartozik a több évtizedekre eltárolt biztonsági mentések védelme: bunker a bunkeren belül, hatalmas, bankokat megszégyenítő páncélajtóval, automata CO2 oltórendszerrel. (jártam már olyanban, ami azt is túlélné, ha egy atombomba robbanna az épület fölött - több tíz kilométeres körzetben mindenki meghalna, de az ott tárolt biztonsági mentésekből vissza lehetne állítani az adatokat, és ez most nem nagyzolás, ezt tényleg így csinálják, pedig azok nem egy állam összes állampolgáráról szóló nyilvántartások)

A biztonsági mentésnek három fajtáját tudjuk használni: image (bocs, nem tudok rá megfelelő magyar szót), naplózás és külső mentés.

Az image pillanatfelvétel az adott gépen található adatokról, operációs rendszertől kezdve az összes telepített programon át a beállításaikig mindenről. Kitűnően alkalmas olyan szerverek mentésére, amik nem üzemeltetnek adatbázisokat, rajtuk a felhasználók által kezdeményezett adatváltozás minimális: ilyenek az alkalmazás szerverek, terminál szerverek, stb. Helyigényük az adatok kis mennyisége miatt kicsi, és szinte percek alatt helyreállítható (újrahúzható) egy szerver belőlük bármilyen adatsérülés vagy olyan változtatás után, aminek a kimenetele kedvezőtlenül hat a rendszer működésére. (tipikus példa a programjavítások telepítése: a program forgalmazója nem tud minden csatolt termékkel kompatibilitási tesztet végezni, így minden egyes program minden egyes változtatása igazából lutri - ezért kell minden egyes változtatás előtt egy működőképes állapotot lementeni, amit bármikor, akár a változatás után hónapokkal később is, amikor a hibák a felszínre jönnek, visszaállíthatunk)

A naplózás a legjobb módja az adatbázisok mentésének: minden egyes adatváltoztatáskor lementésre kerül az adat kiinduló változata, a változtató parancs és az új adat a naplóba (journal, nem pedig log, az más), míg magában az adatbázisban csak az adat legutolsó verziója marad. Helyigénye óriási, mivel mérete a szintén óriási adatbázisnak gyakorlatilag a háromszorosa, viszont megkapjuk vele azt a lehetőséget, hogy nem csak egy adott nap vagy óra (attól függ, hogy milyen gyakoriságra van beállítva) végi adatbázis állapotot tudunk visszaállítani, hanem akár egy tetszőlegesen kiválasztott adatmódosításig vissza tudjuk pörgetni az eseményeket, javítani, és az összes utána következő módosítást újra megejteni, automatizálva persze.

A naplófájlokat évekig megtartani a szerveken fizikai képtelenség, egész egyszerűen nem lenne az a számítási kapacitás, ami megérné. Itt jön be a képbe a külső adathordozókra történő mentés, ami általában még mindig mágnesszalagot jelent, bár a tíz évvel ezelőttiekkel összevetve rájuk se ismernénk. A naplófájlok bejegyzéseit előre beállított időintervallum szerint avultatnánk, mondjuk a szervereken található naplófájlok csak az elmúlt egy hónap adatmódosításait tartalmaznák (ezek lennének on-line elérhetők), és minden ennél idősebb módosítást naponta, óránként, két óránként (ahogy tetszik) lementjük külső adathordozóra (ezek lesznek szükség szerint elérhetők, de nem igazán off-line), valamint ez egy évnél vagy két-három hónapnál (megint csak ahogy tetszik) idősebb külső adathordozókat visszük a páncélba. Ezeken a rendszeres mentéseken kívül készítünk teljes külső mentést az adatbázisainkról heti ill. havi (vagy akár napi) rendszerességgel, amit a mentés befejeztével szintén elzárunk. A külső mentéssel helyet szabadítunk fel a naplófájlokban, illetve abszolút biztonságos körülmények közé helyezzük az adatbázisaink pillanatfelvételeit, hogy egy igazán nagy katasztrófa vagy adatvesztés után se kelljen mindent a nulláról kezdeni.

Az adatbiztonsággal átlapolva meg kell említenünk a hálózati biztonságot (itt a különböző technikákat nem fogom se felsorolni, se részletezni, egyrészt mert ehhez a részhez annyira nem értek, másrészt ez még az informatikán belül is gyakorlatilag egy külön világ - egy profi hálózatbiztonsági szakember megkapja a súlyát aranyban, és ez megint nem túlzás). Ott van ugye az iker szerverközpontunk, ugrásra készen - de az adataink a pillanatnyilag működő szerverközpontban keletkeznek, így azokat át kell "vinnünk" a tartalék helyre. Ez nem megoldható a külső biztonsági mentések szállításával, egyrészt a plusz biztonsági kockázatok, másrészt az időigénye miatt - maradna a hálózati szinkronizálás, amihez olyan vonal kell, aminek az éves bérleti díja egy kistelepülés éves költségvetésével vetekszik.

A válaszidő a rendelkezésre állás mellett a másik olyan mérhető paraméter, ami a szolgáltató tényleges díjazását meghatározza. Kényes kérdés, mivel a szolgáltató – ahogy az egy lakossági internet szolgáltatónál is gyakorlat, tessék megnézni a szerződését, ott vannak benne a rendelkezésre állás és a minimális szolgáltatási paraméterek abban is – ez esetben csak a központi infrastruktúrára vállal kötelezettségeket, így a távoli eléréseket mérni csak úgy lehetne, ha a központi infrastruktúra üzemeltetője (aki ugyanúgy vásárolná a szükséges hálózati hozzáféréseket, csak a szerződések központosítva és valamennyire hangolva lennének) leszerződnénk legalább a nagyobb intézetek (kórházak például) összekötésére. A kisebb, magánúton járó intézetek esetében a válaszidő a központi infrastruktúra válaszidejére vonatkozna csak, így a hálózati szolgáltató rendszerében keletkezett problémák esetén a központi infrastruktúra üzemeltetője széttárná a kezét.

Ezen is lehetne segíteni két módon: az egyik a redundancia bevezetése a kis intézeteknél is (vezetékes mellé mobilinternet például), valamint a terminál technológia kiajánlása. Ez utóbbi esetén a kisebb intézeteknek – de akár a nagyobbaknak is, ha úgy döntenek – semmiféle központi infrastruktúrát nem kellene fenntartaniuk helyileg, hiszen minden adatrögzítés és kérés egy terminál ablakban történne, ami azt tudja, hogy egy távoli gép képernyőjének a képét jeleníti meg, így az adatbeviteli program maga a központi infrastruktúrában futna, érzetre viszont majdnem olyan lenne, mintha helyben. A hálózati adatforgalom így a töredékére csökkenthető, hiszen még egy kliens-szerver felépítésű adatbázisprogram esetében is egy lekérdezés eredményét teljes egészében át kell küldeni mondjuk Debrecenből Karakószörcsögre (ami igazából Karakószörcsök), míg a terminálnál csak a lekérdezés eredményének a képét, amit a felhasználó a képernyőjén látna, hogy ha a program helyben nála futna (sőt, igaziból csak a képernyő változásait küldik át a kliens fele, a szerver fele pedig csak az egérkattintások pozícióját és a billentyűlenyomásokat, és abból számolja ki a szerver, hogy az adott koordinátán egy kattintás mögött ikon, gomb vagy beviteli mező van-e – spórol a hálózattal, na). Ja, és very-very secure. Persze mindezek a megoldások (plusz mobilinternet, plusz adminisztráció a központi szolgáltató részéről) jelentősen megdobják a szolgáltatás árát.

Most pedig jöjjön a bővíthetőség. Bővítésre illetve változtatásra szükség van. A terhelés és az igények folyamatosan változnak: vágyálmaim között szerepel, hogy előbb-utóbb az informatika eléri a magyar államigazgatást is legalább egy közepes bank szintjén, és a különböző szervek és szervezetek, hatóságok is hasonló konstrukciókat valósítanak meg, és a rendszereket egymással összekötik és egymás számára átjárhatóvá teszik. Változtatásra ezen kívül szükség van még a különböző eszközök elhasználódása, a programok frissítése, illetve az adattulajdonos igényeinek változása miatt (huhú, ott aztán vannak csúnya dolgok). Itt csatolunk vissza a redundanciához: ahhoz, hogy a bővítések illetve a változtatások kivitelezhetőek legyenek, szükség van a redundanciára minden szinten. (és akkor még nem említettem a különbséget a produktív, a teszt és a fejlesztői rendszerek között)

Meg kell említenünk még egy nagyon fontos dolgot: az átadhatóságot. A teljes rendszert úgy kell kiépíteni, az üzemeltetést, a folyamatokat, a dokumentálást úgy megvalósítani, hogy az másfél-két hónap alatt átvihető legyen egy másik szolgáltatóhoz szolgáltatás fennakadás vagy minőségromlás nélkül (good luck - ilyenről még csak nem is hallottam, hogy ez valaha valahol sikerült volna, pedig 8 éve csinálom, de meg kell próbálni, hátha). Tulajdonosként elemi érdekünk a tulajdonunk védelme, és - mint már mondtam - az egészségügyi ellátás NEM ÁLLHAT MEG!

Így visszagondolva a poszt elején említett havi több száz millió forintra úgy érzem, igen szerényen számoltam: igazgatótól a fejlesztőkön és üzemeltetőkön át a biztonsági személyzetig és a takarítókig ez úgy lazán 150 fő, akiknek pusztán a fizetési vonzata havi 150-200 millió forint. És akkor nem számoltuk a vásárolt szolgáltatásokat és a fenntartási költségeket, mint bérleti díjak, áram, hálózati kapcsolat, stb., stb.

Legyen évi 6 milliárd alsó hangon. Plusz a tiszteledíjam, persze, ami majdnem ugyanennyi, de az csak egyszeri kiadás.

 

14 komment

Címkék: kommunikáció informatika egészségügy számítógép információ átalakítás árnyékkormány

A bejegyzés trackback címe:

https://republicator.blog.hu/api/trackback/id/tr77517587

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Dr.Stein (törölt) · http://republicator.blog.hu/ 2008.06.14. 06:35:17

próba. kinn van ez vagy miért nem szóltok hozzá?

Ras · http://futo.blog.hu 2008.06.14. 08:24:34

bs395: szerintem nagyon szerényen becsültél. én a teljes funkcionalitást (két szerverfarm, két felügyeleti központ, merthogy a tartalékot is azért őrizni kell, ha nem is működik de áram víz villany bevezetve néha takarítva) legalább 20milliárdra taksálnám. HA tervezni kell ilyet, beszállok szívesen ;).

Rorgosh 2008.06.14. 09:15:05

BS395
Engem meggyőztél... :)
Igazából a múltkori válasz után is már újragondoltam a posztot a buszon utazva, és rájöttem, hogy magamban 1 nullával elszámoltam a dolgokat....

Hiába no, tisztességes szolgáltatás nincs ingyen. Amúgy 1 hónap/adófizetőre vetítve még mindíg csak 100-150 Ft körül alakul havonta. Szóval egy ex vizitdíjból legalább 2 havi fenntartás kijön...

Takika 2008.06.14. 15:27:15

Ej, de szivesen beszallnek a halozatot uzemeltetni :)

osi 2008.06.14. 17:31:50

BS395
Nem kötözködés, de a ktg tervezés erősen hiányos (laza):
Elsősorban el kell dönteni, melyek azok a területek amiket az Állam Bácsi biztosít és mit rendelnek meg külső beszállítótól. Mind a két véglet rossz! Létrehozni egy Hivatalt (Intézetet), amely mindent kézben tart, vagy mindent csináljanak külsősök és lehet fizetni, vagy mutogatni.
A kezdő pénzről elképzelésem sincs, tekintettel arra, hogy nem ismerem az EÜ jelenlegi HW, SW felszereltségét.
A project több éves. Mármint az első gyermek létrehozása. Ebből következik, ebből a "szép" szakmából, - nevezzük ámítástechnikának - az avulás igen gyors. Teljesen egyetértek, a módosíthatóság, bővíthetőség alapelvvel, de hát ez nagyon keserves.
Bár tudok cégekről ahol DOS 6.2 alatt számláznak, készletet, -raktárat tartanak nyilván, a franc tudja milyen gépeken és megy nekik. Meg vannak a hibridek, ahol XP alatt futnak a DOS-os progik.
Na de, ha elkészül a portéka és még müxik is jön a legnagyobb rákfene:

- szervíz
- HW. Nyilván külsős történet, vagy nem. Végülis nem lehet minden körzetiorvos mellé ültetni egy szakembert, aki kiszabadítja a papírt a nyomtatóból, ha az éppen begyűrődik.
- SW. Oprendszer, felhasználói szoft újra telepítése még "egyszerű". De a "jaj Istenem mi történt? Én nem csináltam semmit!!!" című történetekhez igen felkészült, jó idegrendszerrel felszerelt "telefonos" segítségek kellenek.

- üzemeltetés
A "lazán 150 fő"-t nem tudom hogy számoltad. Én persze nem gondolkodom atomtámadásban és szükségtelennek tartok egy, - a pápát védő - biztonsági rendszert. Ha van ilyen érdekeltséged szólj és megszavazom! Ha megegyeztünk.
Szóval a 150 vagy nagyon kevés, vagy nagyon sok. Szerintem a hálózat üzemeltetéshez nagyon sok. Ha a szervíz is ide számoltatik, akkor nagyon kevés.

- Fejlesztés
Itt csak a SW-ről. Két vonal kezelendő:
- Egy prgrendszer sosincs kész. Állandó módosítás, bővítés, hiba javítás.
- Ha átadtunk egy rendszert, jöhet egy rövid pihenés. Terméktől függően 1 hónap - 1 év, aztán máris neki lehet fogni a V.2 tervezésének, fejlesztésének.
Felmerül az ostoba kérdés: ki fogja csinálni, mennyiért, milyen forrásból.

- Betanítás
Nehéz dolog. Belevágni valakinek az arcába, hogy "Ne haragudjon, de Ön alkalmatlan!"
Idetartozik: az emberek ódzkodnak az újtól. Néha irgalmatlan ellenállásba ütközik, egy új mutatvány bevezetése.

Végül magamról: Több mint 30 éve eszem a programozók, tervezők kenyerét.

bs395 · http://killtheradical.blog.hu 2008.06.14. 22:31:58

osi:
az, hogy mit rendel az állam bácsi, mit szolgáltat a cég, benne van a posztban, több helyen is.
a dosos rész az a front-end. ha az a backend is, akkor a redundancia egész egyszerűen siralmas lehet.
a szervíz külsős (hw vendor) kizárólag, már csak a garancia miatt is.
ha a rendelő helyben meg akarja tartani a dolgait, semmi gond, de azt nem a központi szolgáltató üzemelteti. hívjon, elbeszélgetünk vele fociról, időjárásról, bármiről.
ha a rendelő termiált használ, az egyrészt egy picsamód egyszerű progi a kliensoldaról, másrészt szerveroldalról nem tud mit elbaszni, csak rossz adatot felvinni, azt meg felviszi újra, módosítja.
az üzemeltetés az üzemeltetés. monitoring, 1st, 2nd és 3rd level, némi fejlesztői támogatással, non-stop 4 műszak, plusz on-call standby. mivel specializált részterületekről lesz szó (hálózat, hálózatbiztonság, unix, db, termináltechnológia, stb.) egy műszak az olyan 20 fő, 4 műszak az 80, plusz 20 db 3rd level, 5-10 fejlesztő, managerek, adminisztráció, őrzés-védés, takarítás. 150 fő.
a fejlesztéseket a fejlesztők csinálják. ha verzióváltás van, azt az üzemeltetéssel közösen levezénylik. legalábbis ahol eddig dolgoztam, ott mindenhol így csinálták, és működik.
a betanítás csak akkor esedékes, ha a rendelő átáll a terminálokra. ha nem, akkor nincs mit betanítani, a local supportot oldja meg saját kútfőből. ha meg hiányoznak a beérkező adatok tőle, akkor jön a kötbér - neki.

rotting 2008.06.15. 18:38:28

az a szárnyas botos embléma az egy jó nagy tévedés

az a kereskedés jelképe, nem az orvoslásé
(lásd még aszklépiosz és hermész)

dendrimer-molecule.blogspot.com/2008/06/mind-sign.html

jó lenne lecserélni

gordiusz 2008.06.16. 13:34:45

Továbbra is az a véleményem, hogy
- a dolog nagyon jó lenne;
- amire szerintem szükség volna, egy minden orvos által hozzáférhető központi adatbázis, ahová minden eü szolgáltató a kívánt adatokat rendszeresen, kellően rövid időn belül feltölti. A feltöltéshez definiálni kell valamilyen egyszerű adatstruktúrát, így az adott helyen használt nyilvántartó szoftver el tudná készíteni az adatfeladást. Lekérdezni pedig weben lehetne, mert kilensoldalon sokkal egyszerűbb. Úgy általában kicsit hasonló dologra gondolok, mint pl. az adóbevallás a magyarorszag.hu-n, csak .
- szerintem létezik olyan alap állami IT-infrastruktúra, ahol a szerverszobák, a távközlési vonalak megvannak, "csak" a projekthez szükséges szerverekre, ill. fejlesztésekre lenne szükség. Azért gondoltam az oep-re, mint alapra, mert oda tudomásom szerint rendszeresen jelentenek a szolgáltatók.

Szerintem, ha előírnánk, hogy egy háziorvos egy központi rendszerrel tartsa nyilván a saját praxisának összes adatát, az kb. olyan lenne, mintha az APEH nemcsak járulékbevallást kérne a cégektől, hanem bérszámfejtő szoftvert is adna nekik.
Még egy háziorvosi praxisban, de különösen egy kórházban számos olyan adatot kell valószínűleg tárolni, amire sehol máshol nincs szükség , de a betegek adataival összefügghet. Ha a "közös" adatokat egy állami, meghatározott rendszerben tartják nyilván, akkor vagy még egyszer rögzíteniük kell a saját rendszerükbe is, vagy az állami rendszert kell összekapcsolni a helyi rendszerrel. Mindkettőnél sokkal értelmesebb megoldás, ha mindenki úgy tartja nyilván a munkájához szükséges adatokat, ahogy akarja, de a "közös" adatokat valahová jelenti. (Mint ahogy a bérszámfejtő szoftverek is el tudják készíteni az elektronikus járulékbevallást.)

dr. Morcz · http://drmorcz.blog.hu 2008.06.18. 10:24:38

Kedves bs395,

Remek a poszt, köszönöm ezt a részletes elemzést! Mit ne mondjak, több, mint amire gondoltam, de meggyőztél.
Szerintem az általad vázolt technológia mellett nyilván a szerver-, és felügyeleti központok lennének a költségesek, az orvosok jelenlegi gépei (amiken a ma használt programok is futnak) bőven alkalmasak lennének a terminál futtatására. A nagy kérdés ott van, hogy magát a központi rendszert kell-e hardver és oprendszer szintjén fejleszteni? Azaz kell-e követni ott is azt a trendet, ami a mai hobbiszinten számítógépet használót is max. 2-3 évente új gép és szoftverek beszerzésére ösztönzi? Az nyilvánvaló, hogy maga a rendszer fejleszthető kell legyen (ha új eü. jogszabály jön ki, tudja követni stb), de ez nyilván nem igényelne pl. új hardverbeszerzést.
A kérdést annyiból érzem lényegesnek, hogy nyilván az egész rendszer kiépítése (HW és SW) lenne a legnagyobb falat, de az üzemeltetés egy főre eső költsége jóval alatta maradna pl. egy doboz Cavinton árának, tehát az ijesztően nagy számok ellenére is vállalhatónak tűnik. Érdekes lenne tudni, hogy az OEP/Gyógyinfok jelenleg is használt rendszere, amivel az eü. ellátók finanszírozását is követik, mennyibe fáj havonta.

Ja, ezt a kommentet egy Win98-as gépről, Firefoxszal netezve írom, a gépen bőven elfut a Med*** (ez itt nem a reklám helye) terminálja, amit a párezer ágyas kórházunk az összes beteg-dokumentációhoz használ. Szóval tényleg nem a kliens-, (vagy terminál-) oldal számít.

bs395 · http://killtheradical.blog.hu 2008.06.18. 10:54:42

doktor úr,

az ilyen gépeket általában 4-5 év folyamatos (24/7) üzemre kalibrálják.
a szoftvert természetesen (akár a nyilvántartó programot, akár az operációs rendszereket) folyamatosan karban kell tartani az új biztonsági rések felfedezése és az új igények miatt.
a gond a gyártói avultatás: 4-5 évente lejár a támogatás az új termékeknek piacot teremtendő, és a garancia mind a hardver, mind a szofver eszközökre, garancia nélkül üzemeltetni pedig olyan, mint ejtőernyő nélkül ugrani :-(.
részleges megoldás a licenszek "bérlése", amikor nem a teljes licensz árat fizetjük ki, majd az új termék megjelenésekor újra a teljes licensz árat, hanem egy éves átalányt, ami magában foglalja a termékváltást is.

bs395 · http://killtheradical.blog.hu 2008.06.18. 10:59:47

meg még:
index.hu/tech/mobil/pangy080617/?main&rnd=19
ha nem csinálja az állam, csinálja a privát szféra. mondjuk bátor ember, aki így kiadja az adatait.

mrc 2008.06.25. 14:37:52

Szép elemzés, sajnos kevesen látják át ilyen részletesen, hogy mégis mivel jár egy ilyen rendszer megtervezése / üzemeltetése.

Ugyanakkor megrizikóznám, hogy lehet ezt még tovább fokozni, sok szempontból.

Első körben is az SLA az azon túl hogy egy darab papír, meghatározza az egész rendszer tervezését - pár paramétert említettél, de azt gondolom, hogy jónéhány másik paramétert is ismerni kell, sőt bonyolítok: nem egy SLA szükséges egy ilyen rendszernél. Tehát visszábblépnék: definiálni kellene első körben, hogy konkrétan mik azok a szolgáltatások amiket ennek az infrastruktúrának ki kell szolgálni - egyáltalán nem mindegy, hogy mondjuk kórtörténet lekérdezésről van szó (ilyen szolgáltatásnál a 99.96-nál magasabb rendelkezésre állást várnék el, mert ha 3 óráig áll a rendszer addigra egy balesetes meghalhat ha beadnak neki egy olyan gyógyit amire allergiás), vagy mondjuk költségelszámolásról és térítésigénylésről (egyrészt ezt adminisztrátorok csinálják munkaidőben másrészt bár kényelmetlen, de katasztrófa nem történik ha pár napig papíroznak és utólag írják be a megjavított rendszerbe).

Ami mindenesetre azt jelenti, hogy
- Nem kell mindent duplázni
- Standby rendszereket lehet úgy tervezni, hogy egyszerre több rendszernek legyen a standby rendszere mert nagyon nem valószínű, hogy egyszerre esik szét az összes rendszer
- Adott esetben nem 2, hanem 4-5 adatközpontról kéne beszélni, bármilyen fura de ez akár fajlagosan olcsóbb is lehet a 2-nél, mivel nem muszáj a cuccok felének üresen járnia, hanem csak mondjuk az 1/5-ének

Az üzemeltető társaság méretét pedig nem csak az infrastruktúra, hanem a támogatni kívánt alkalmazások diverzitása és a támogatott embertömeg nagysága és jellege is meghatározza. Mivel a szolgáltatásokat nem határoztuk meg ezért fogalmam sincs, mennyi felhasználóról beszélünk (csak egészségügyi adminisztrátorok? A nóvérek is? A háziorvosok? A patikusok is?), ezért ezt nehéz tippelni. A 150 lehet jó tipp és lehet nagyon kevés is.

Ne vesézzük tovább, mégiscsak több emberéves munka ezt korrektül kitalálni és megcsinálni :) De az biztos, hogy érdekes témakör.

Annyit azért megjegyeznék, hogy valami hasonlót csinálnak itt Angliában az NHS (National Health Service) égisze alatt, rémisztő mennyiségű pénzt időt és energiát emészt fel, és még senki nem látja a végét. Pedig itt kicsitt fejlettebb szinten van és elfogadott dolog az IT szolgáltatásmenedzsment, nem alibiből űzik mint a legtöbb helyen Magyarországon.