Ágazati adatkommunikációs ajánlásgyűjtemény

Ágazati adatkommunikációs ajánlásgyűjtemény Budapest 2011. június 19.

Készítette: HC expert Kft. Verzió: 10.1 2/92

Tartalomjegyzék Tartalomjegyzék... 3 Bevezetés... 6 Összefoglaló ajánlások... 7 Az egységes ágazati adatkommunikációs és jelentés rendszer alapjainak kialakításával kapcsolatos ajánlások és követelmények... 8 Egykapus rendszer kialakítása... 8 Egységes objektum modell (BOM) alkalmazása az ágazatban... 8 ISO OID (Object IDentifier egyedi azonosító) rendszer kialakítása... 9 Az egységes ágazati adatkommunikációs és jelentés rendszerben alkalmazott interfészek... 10 On line interfészek... 10 Off line (batch) interfészek... 11 Egységesített fejléc információk (metaadatok) alkalmazása... 11 Egységesített hiba struktúra alkalmazása... 11 Alkalmazott fájl formátumok... 11 Az egységes ágazati adatkommunikációs és jelentés rendszerben alkalmazott adattípusok... 13 Az egységes jelentés rendszerben alkalmazott időformátumok... 13 Standardizált ellátási alapdokumentáció kialakítása... 14 Egységes ágazati jelentés rendszer... 14 Egységes jelentés objektum... 14 Egységes jelentés workflow... 15 Azonosítók, kódrendszerek nyilvántartások... 17 Egységes intézmény (ellátó) azonosítási rendszer... 17 Egységes ellátott azonosítás... 19 Kódrendszerek egységes ábrázolása... 20 Nyilvántartások... 21 Kommunikáció biztonságára vonatkozó ajánlások... 22 Csatorna védelme (Kommunikáció)... 22 Felhasználó azonosítás (Kommunkáció)... 22 Koncepcionális javaslat az egységes ágazati informatika megalapozására... 24 Ágazati informatikai közmű... 24 Az ihealthway rétegezettsége... 25 A Hungarian ihealthway ágazati informatikai közmű összetevői... 28 Kulcsjellemzők... 32 A közmű és az ESB modell... 32 Az elektronikus beteginformációk továbbítása... 34 Az információtovábbítás szintjei... 34 Best practice projektek... 35 EHR továbbítási módszerek... 36 EHR dokumentumok előállítása és felhasználása az intézményekben... 38 Dokumentum repository... 39 Publikáció betegek számára... 40 Az EHR kommunikáció feltételrendszere... 40 EHR egységesítése és publikációja... 40 Kódtörzsek egységes használata... 40 Standardizált ellátási alapdokumentáció intézményi szinten... 42 Bevezetés A standardizáció célja... 42 Hazai helyzetkép... 43 3/92

Jogszabályi környezet... 43 A hazai dokumentumegységesség általános jellemzése... 44 Az orvosszakmai egységesség értékelése... 46 A formális standardizáció eszköztára... 48 A duális adatmodellek... 48 A dokumentumstruktúrák tipizálása... 52 Az általános ellátási folyamat adatelemei... 53 A dokumentáció hierarchikus szintjeinek modellje... 57 Az alapdokumentáció javasolt szerkezete... 57 Specifikáció a felső szintű dokumentumelemekre... 57 Specifikáció az alacsony szintű dokumentumelemekre... 57 Technikai javaslatok... 58 Szóba jövő szabványok... 58 Alapelvek... 58 A szerkezeti standardizáció fenntarthatósága... 69 A klinikai irányelvek és az ellátási adatok formalizációja... 69 A formalizáció lépései... 70 Adatjelentések adattartalma... 73 Elemzés... 73 A jelentési rendszerek problémái... 74 Eltérő formátumok... 74 Rugalmatlan szerkezetek... 74 Eltérő adatreprezentációk... 75 Nem egységes adattípusok... 75 Eltérő adattovábbítási csatornák... 76 Kommunikáció biztonsága... 76 Párhuzamos, de tartalmilag divergáló jelentések... 77 A jelentési folyamat transzparenciájának hiánya... 78 Eltérő jelentés workflow... 78 Ellátó és ellátott azonosítás... 78 Elsődleges validáció hiánya, a visszajelzések hiánya, illetve késedelme... 79 Alkalmazás... 80 Közhiteles portál... 81 Jelenlegi helyzet... 81 Törzsadatok és nyilvántartások kezelésének és felhasználásának problémái... 81 Kódrendszerek, kódtáblák... 81 Nyilvántartások... 82 Nem egységes törzsadat kezelés... 82 Egységes elérhetőség, publikáció hiánya... 82 Redundáns törzsadatok... 83 Az idősoros kezelés hiánya... 83 Egymásra épülő nyilvántartások problémái... 83 Közhiteles portállal szemben támasztott követelmények... 83 Egymásra épülő kódtörzsek (kódtáblák és nyilvántartások)... 84 Irodalom, külföldi példák... 86 Kötelező funkciók... 86 Publikációs javaslat... 87 A rendszeres publikáció megkövetelt tartalma... 87 Célközönség... 87 Szakmai közvélemény... 87 4/92

Laikus közvélemény... 88 Szállítók... 88 Felhasználók... 88 Terítési módszerek... 89 Ágazati központi szervek bevonása... 89 Sajtókapcsolatok... 89 Szakmai rendezvények... 89 Validációs módszerek... 90 PDCA SDCA ciklus... 90 Validációban részt vevő partnerek... 91 Mellékletek... 92 5/92

Bevezetés Az Egészségügyi Stratégiai Kutató Intézet (2011. május 1 én a GYEMSZI be integrálódott szervezetként) az Új Magyarország Fejlesztési Terv TIOP 2.3.2. konstrukció, a TÁMOP 6.2.3 konstrukció (és egyúttal további konstrukciók) mint kiemelt projektek projektgazdai várományosa a 2011 13 évi akciótervekben. Az Intézet célként határozta meg, hogy ezen projektek módszertani előkészítését elvégezze a majdani gyors megvalósíthatóság érdekében. A fenti tevékenysége keretében az Intézet 2011. január 26 án megbízta a HC expert Kft. t, hogy a fent hivatkozott projektjeit, illetve a magyar egészségügyi ágazat informatikai fejlesztéseit megalapozó, adatkommunikációs alapokra vonatkozó ajánlásgyűjteményt készítse el a jelen tanulmányban. A projekt kezdetén meghatározott követelmények a munka előrehaladása során a szerződésben megfogalmazottakkal összhangban további pontosításra kerültek, ami meghatározta a szakértői tevékenység végső kiterjedését és fókuszpontjait. Az anyag elkészítése során számos egészségügyi ágazatirányítási intézmény szakembere segítette a szakértői csoport munkáját aktív tevékenységgel, többek között az Egészségügyi Stratégiai Kutató Intézet (időközben GYEMSZI), az Országos Gyógyszerészeti Intézet, az Országos Egészségbiztosítási Pénztár és a Kormányzati Informatikai Fejlesztési Ügynökség szakemberei is. Ugyanakkor lényeges hangsúlyozni, hogy a projekt kezdetén csak döntően verbális jellegű információk álltak rendelkezésre az ágazati operatív programok tagolásáról és céljairól, beleértve különösen az egyes operatív programokban megvalósítandó adatkommunikáció folyamatait és környezetét. Jelen projekt félidején jóval túl (2011. május végén) került elfogadásra az ágazati stratégiát pontosító Semmelweis Terv végleges változata, illetve a projekt szakértői számára csak a lezárás időpontját közvetlenül megelőzően vált elérhetővé az ágazati informatikai fejlesztési stratégiát körvonalazni kívánó ún. e Health koncepció munkaváltozata. Mindezek következményeképpen a jelen projekt szakértői a munka első szakaszában kidolgoztak egy feltételezett magas szintű követelményforrásnak szánva egy általuk működtethetőnek tartott ágazati informatikai víziót, amelynek egyes kulcsjellemzőit ebben az anyagban is megjelentették. A részletes ajánlások ezen vízió feltételezéseinek alapulvételével készültek, ezáltal nem feltétlenül kongruálnak tökéletesen az ágazatirányításban később megjelenő koncepcionális döntésekkel, illetve emiatt számos helyen alternatív, vagy akár eltérő nézőpontokból való megközelítéseket is tartalmaznak. Az elkészült ajánlásgyűjtemény célja szerint az ágazat fejlesztéseinek közös technológiai és részben módszertani alapot teremt, egyben segít abban, hogy az ágazati informatikai vonatkozású fejlesztések kompatibilisek legyenek, függetlenül az intézményi háttértől, vagy regionalitástól. Az ajánlások a hazai és nemzetközi egészségügyi informatikai gyakorlat figyelembe vételével, arra épülnek, céljuk a gyakorlati hasznosíthatóság, felhasználva és hivatkozva a legjobb gyakorlatot, a létező külföldi és hazai eredményeket és tapasztalatokat. 6/92

Összefoglaló ajánlások Bár az ajánlások létrejöttének folyamatában a konkrét ajánlások megfogalmazása értelemszerűen az utolsó lépés, jelen anyagban a könnyebb áttekinthetőség érdekében az ajánlásokat kiemeltük a tanulmány első fejezetébe. A tanulmány későbbi fejezetei az egyes ajánlások hátterét, illetve részleteit mutatják be és tárgyalják. 7/92

Az egységes ágazati adatkommunikációs és jelentés rendszer alapjainak kialakításával kapcsolatos ajánlások és követelmények Egykapus rendszer kialakítása Az egységes ágazati kommunikációs és jelentés rendszer megteremtésén alappillére egy olyan központi infrastruktúra portál létrehozása, mely biztosítja az ágazat szereplői (ellátók, szolgáltatók, ellátottak, ágazat irányítás intézményei) számára a szükséges információhoz történő hozzáférés eszközeit, a megfelelő transzparenciát és a megfelelő technológiai hátteret. Ennek érdekében: létre kell hozni az ágazati portált, melynek minimális funkcionalitása: 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 publikálása az egységes jelentés fogadó és ellenőrző rendszer. A közhiteles és közcélú adatok, illetve az egyes rendszerek működtetéséhez kapcsolódó nyilvános adatok publikálása terjedjen ki az alábbi adatkörökre: használt kódtáblák, kódrendszerek hozzáférés biztosítása a közhiteles és közcélú nyilvántartások releváns adataihoz a portálon publikált adatok és funkciók specifikációi és egyéb leírások: eljárásrendek fogalomtár jelentések specifikációi szolgáltatások specifikációi metamodellek validálási szabályok az egységes jelentés fogadó és ellenőrző rendszer biztosítsa: az ágazati adatszolgáltatásokhoz szükséges átadási felületeket az egyes jelentések, adatszolgáltatások specifikációját a jelentések szétosztását és továbbítását a tényleges címzettekhez az egyes jelentések formai és bizonyos általános (a portálon publikált) szabályok szerinti tartalmi validációját a jelentések javításának általános mechanizmusát a jelentésekről történő visszajelzések mechanizmusait a jelentésekkel és adatküldésekkel kapcsolatos minden tranzakció naplózását, és az érintett szereplő általi betekinthetőségét. Egységes objektum modell (BOM 1 ) alkalmazása az ágazatban A portálon publikált minden interfész (fájl formátum, web service) egy egységes fogalmi modellre kell, hogy épüljön. Az esetleges szükséges transzformációk a portál belsejében kerülnek végrehajtásra. Ennek érdekében: szükséges elkészíteni az ágazat egységes fogalmi modelljét (BOM), a modell elemei minimálisan az alábbi tulajdonságokkal kell, hogy rendelkezzenek: 1 Business Object Model 8/92

class Alapfogalmak BOM 1..* Objektum - Megnevezés - Egyedi azonosító - Verzió - Részletes leírás - Formális logikai model [0..1] - Formális specifikáció [0..1] a modellt a portálon kell publikálni, a megfelelő jogszabályi és/vagy felhatalmazási háttér kialakításával biztosítani kell a modell folyamatos karbantartását és frissítését, a publikált interfészek (szolgáltatások és fájl formátumok) függetlenül attól, hogy a portál, vagy az ágazat egyéb szereplőinek valamilyen interfészéről van e szó a publikált fogalomrendszerre kell, hogy épüljenek. A megfelelő jogszabályi és/vagy felhatalmazási háttér kialakításával biztosítható, hogy a jövőbeli jogalkotási folyamatok az ágazat egységes fogalomrendszerét használják. Ennek alapján az ágazaton belül a kommunikációra vonatkozó jogalkotási folyamat helyes menetében a jogalkotó csak az elvárt adattartalmakat specifikálja, míg az elvárt adattartalom alapján a formális specifikációt az erre felhatalmazott szervezet készíti el és publikálja a BOM alapján. ISO OID (Object IDentifier egyedi azonosító) rendszer kialakítása Az OID k rendszere egy fa struktúra, melynek egyes pontjához intézményi felelősök vannak hozzárendelve, akik az adott pont alatti rész fáért felelnek: további ágakat (csomópontokat) hozhatnak létre, illetve egy egy ilyen csomópontot más szervezethez delegálhatnak (aminek azután már ez az újabb szervezet lesz a felelőse). Az ISO OID k (Object IDentifier egyedi azonosítók) rendszerének formális definícióját az X.208 (ASN.1), míg az OID k kódolására vonatkozó ajánlást az X.209 ITU T ajánlás tartalmazza. Mivel a hazai és nemzetközi egészségügyi szabványok kötelező attribútumaikban alapvetően építenek az OID k rendszerére ( 2 ), a szabványos dokumentumok kialakításához szükséges az egészségügyi informatika területéhez kapcsolódó OID rendszer kidolgozása, és regisztrálása. Ennek hiányában a rendszer nem lesz működőképes. Az OID rendszer három alap ágát a következő szervezetk kezeik: 0 ITU T, 1 ISO, 2 Joint ISO/ITU T. Ebben a rendszerben magyarországi csomópontok két fő ágon regisztrálhatók: 2 A HL7 közösség saját használatára 2001. óta mintegy 4800 OID t regisztrált a 2.16.840.1.113883 (joint iso itut.country.us.organization.hl7) node alatt. http://www.hl7.org/oid/index.cfm 9/92

Magyarország számára két hivatalos node áll rendelkezésre: a joint iso itu t ágon a 2.16.348 {jointiso itu t(2) country(16) hu(348)} node, illetve ennek alternatívájaként az itu t ágon a 0.2.216 {itu t(0) administration(2) 216} node. Ez utóbbit az IHM jegyeztette be 2006 ban3, de ennek alábontása még nem történt meg, és tisztázandó, hogy országos szinten ki és hogyan jogosult ezt tovább bontani. Ugyancsak lehetőség van az 1.3.6.1.4.1 {iso(1) identified organization(3) dod(6) internet(1) private(4) enterprise(1)} ágon tetszőleges vállalkozás számára egy önálló node regisztrálására, így elvben az ágazatirányítás a hivatalos, Magyarország számára fenntartott node helyett egy önálló node ot is szerezhet. 4 Az egységes ágazati informatikai fejlesztések megalapozás érdekében szükséges az ágazatirányítás számára egy, a hazai egészségügyi informatika számára allokált OID node regisztrálása és bevezetése, a hazai node alatt regisztrált OID ket a portálon publikálni kell, a megfelelő szabályi háttér kialakításával biztosítani kell a regisztráció szabályait, biztosítani kell az OID rendszer folyamatos karbantartását és frissítését. Az egységes ágazati adatkommunikációs és jelentés rendszerben alkalmazott interfészek Az interfész típusok egységesítése jelentősen egyszerűsíti az architektúrát, és a maximális függetlenséget biztosítja a fejlesztők számára. A rendszerben az adatok cseréje alapvetően kétféle kommunikációs módon valósulhat meg: on line szolgáltatásokon, illetve fájl átadás alapú off line adat transzferrel. On line interfészek Ezek a szolgáltatások jellemzően valamilyen lekérdezést implementálnak (pl. TAJ ellenőrzés), illetve valamilyen kis adattartalmú információ továbbítás (jelentés) beküldésére szolgálhatnak. Web servicek Az on line interfészek megvalósítására a W3C szerinti web service eket (WS) kell alkalmazni. Az on line interfészek megvalósítása során SOAP/HTML kommunikációt kell alkalmazni. A web servicek specifikációját WSDL formátumban meg kell adni. A specifikációkat tartalmazó WSDL eket a portálon ki kell publikálni. On line űrlapok Webes (on line) űrlapok alkalmazása esetén ezek a felületek az űrlapot (formot) kibocsátó intézmény informatikai rendszeréhez közvetlenül kapcsolódnak. Ebből a szempontból speciális követelményeknek nem kell megfelelniük, hiszen alapvetően a formot működtető inézmény belügyének tekinthetők. Ugyanakkor az általános hozzáférés biztosítás érdekében ezekben az esetben is célszerű néhány, az ágazat egészére vonatkozó ajánlást megfontolni: On line űrlapok esetén a kibocsátó biztosítson az űrlap adattartalmával egyenértékű, az ágazati ajánlásoknak megfelelő web service t is a gépi kapcsolódás biztosítására. Amennyiben az on line űrlap lehetőséget biztosít az űrlap adatainak valamilyen formában történő feltöltésére (batch jellegű feltöltés), úgy a feltöltendő fájlra vonatkozóan érvényesíteni kell az alkalmazható adatfájl formátumokra vonatkozó előírásokat. 3 http://www.oid info.com/get/0.2.216 4 Míg az előbbi eljárás célszerűbbnek tűnik az ágazatirányítás hivatalos reprezentációja szempontjából (pl. a HL7 node is az Egyesült Államok hasonló nodja, a 2.16.840.1. (joint iso itu t.country.us.organization) alatt került regisztrálásra!), az utóbbi eljárással valószínűleg lényegesen gyorsabban, gyakorlatilag minimális adminisztrációval lehet a rendszer működtetéséhez szükséges OID node hoz jutni. Ezen az ágon egyébként jelenleg 23 magyar entitás rendelkezik önálló OID node dal. 10/92

Off line (batch) interfészek Ezek az interfészek nagy adattömegek mozgatására (pl. havi jelentések) szolgálnak. Ezeknél az interfészeknél a nagy adattömeg miatt az adatok átadása off line fájl transzfer művelettel történik. Fájl alapú átadások esetében az átadás két lépésből áll: i) első lépésben a küldő egy megfelelő authentikációval elérhető biztonságos fájl szerverre felmásolja az átadni kívánt állományt ii) második lépésben a küldő egy web service hívással értesíti a rendszert a fájl feltöltéséről. Ennek a hívásnak a nyugtázása jelenti az átadás tulajdonképpeni megtörténtét. Felhasználónként elkülönített feltöltési tárterületet kell biztosítani. Szabályozni kell a tárterületek kezelésének feltételeit: o mekkora a rendelkezésre álló tárterület (kvóta) o kinek a joga / kötelessége a tárterületről való törlés o automatikus törlés esetén mennyi idő múlva kerülnek törlésre az állományok A tárterület elérésével kapcsolatos minden tranzakciót logolni kell a portálnak. Egységesített fejléc információk (metaadatok) alkalmazása A rendszer minden üzenetében egységesen kialakított fejléc információkat (metaadat készletet) kell alkalmazni, mely legalább az alábbi adatokat tartalmazza: class Alapfogalmak Egységes fejlécinformációk - Küldőre vonatkozó információk - Fogadóra vonatkozó információk - Egyedi azonosító - Kapcsolódó üzenetek - Egyéb metaadatok A metaadatokat web serviceek esetében a SOAP fejlécben (header) kell elhelyezni. A metaadatokat fájlok esetében a fájloktól elválaszthatatlan módon, az alábbiak szerint kell elhelyezni: o XML fájlok esetében az XML belsejében, egy egységesesen specifikált objektumban o szöveges fájlok esetén a fájl első sorában (soraiban) Egységesített hiba struktúra alkalmazása A web service válaszokban egységes hiba struktúrát kell alkalmazni. A struktúrát az általános SOAP objektumok hiba struktúrájában kell elhelyezni, a web service válasz (response) objektumában. Alkalmazott fájl formátumok A nagy adattömegek mozgatására szolgáló off line interfészek esetében az adatok átadása fájlokban történik. Az alkalmazható fájlformátumok egységesítése megalapozza az egységes specifikációk elkészítésének lehetőségét, valamint leegyszerűsíti, és ezáltal sokkal hatékonyabbá teszi az előállításhoz és feldolgozáshoz szükséges újrafelhasználható alkalmazás komponensek fejlesztését. 11/92

Jelen kérdéskörben csak az alkalmazás független fájlformátumok értelmezhetők. Az egyes alkalmazásspecifikus formátumok (pl. Excel fájl ) az egyes termékektől, gyártóktól való függőségük miatt mint lehetséges szabványosított formátumok nem jöhetnek szóba. A gyakorlatban elterjedt adat fájl típusok és jellemző tulajdonságaik a következők: Formátum Kulcsjellemzők Használati példák dbf fájlok a 80 as években bevezetett fájlformátum az adatbázisok cseréjére, mely magában a fájlban tartalmaz a saját szerkezetére vonatkozó információkat a formátumnak sok eltérő specifikációja létezik, így kompatibilitási, illetve karakterkódolási problémákat vet fel szeparált szövegfájlok fix pozíciós szövegfájlok a szövegfájlban elhelyezett adatok egy specifikált elválasztó karakterrel elválasztott mezőkben helyezkednek el jellemzően egy sor egy rekord felépítésűek ún. multirekord struktúrák esetében az első mező határozza meg az adott sor típusát, így eltérő rekordspecifikációk kezelésére is alkalmas összetett struktúrák specifikációja bonyolult rugalmasan kezeli a változó hosszúságú tartalmakat tömör, az üres elemek helyfoglalása 1 karakter az egyes elemek hossza előzetesen fixen megkötésre kerül, így az egyes mezők nem mezőhatárolóval vannak elválasztva, hanem mindig egy adott karakterpozíción kezdődnek jellegéből adódóan, általában nem helytakarékos a specifikáció változtatás nehézkes sok kitöltetlen elem esetén különösen nem helytakarékos XML szabványos formátum (W3C) összetett (egymásba ágyazott) struktúrák kezelésére hatékonyan alkalmazható az állomány belső szerkezete formálisan specifikálható (XSD) az XSD alapján automatikus generálás és validálás lehetséges a specifikáció módosítása egyszerűen implementálható bőbeszédű, azaz kis adattartalmak esetében nem feltétlenül helytakarékos EFI, CT MR, Rákregiszter, otthoni ápolás jelenleg nincs használatban fekvő és járóbeteg esetfinanszírozás, fogászat, vényjelentés, E jelentés várólista, obp MOJ vények Az ágazati adatkommunikációban elsődlegesen preferált formátum az XML formátum. Szükség esetén elfogadható szeparált értékeket tartalmazó (CSV) állományok alkalmazása is. XML fájlok Az XML formátumban specifikált objektumok formális specifikációját a XSD ben (XML Schema Definition) kell megadni. Az objektumok specifikációját tartalmazó XSD ket a portálon ki kell publikálni. Az XML ek feldolgozásakor az XML formátumra vonatkozó teljes W3C specifikációt figyelembe kell venni, de szüksége esetén a specifikáció egyes elemeinek használatára lehet korlátozó megkötést tenni (pl. használható karakterkódolási sémák). XML állományok esetében a megengedett karakterkódolási sémák: UTF 8, UTF 16, ISO 8859 2 (Támogatva ezáltal a középeurópai nyelvek karaktereinek helyes megjelenítését, megelőzve a betűk nem tervezett átalakulását ). Az ettől eltérő kódolású XML állományokat a feldolgozó alkalmazások visszautasíthatják. Szeparált szöveges fájlok (CSV) CSV fájlok alkalmazása esetén a specifikációnak tartalmaznia kell az alábbi adatokat: 12/92

i) elválasztó karakter (separator) ii) karakterkódolás iii) elválasztó karaktert tartalmazó mezők esetében a mezőhatároló (quote) karakter. Amennyiben mezőhatároló karakter nem kerül megadásra, az egyes értékek értelemszerűen nem tartalmazhatnak elválasztó karaktert, ez ugyanis a struktúra elcsúszását eredményezi. Ezt az állományt előállító alkalmazásnak ellenőrizni és szükség esetén kezelni kell. Az egységes ágazati adatkommunikációs és jelentés rendszerben alkalmazott adattípusok Az ágazati kommunikáció egységesítésének egyik alapfeltétele a használható adattípusok egységesítése. Ennek során megkülönböztethetünk logikai és implementációs szinteket. A logikai szinten egységes adattípusok implementációs szinten különböző formában jelenhetnek meg, azonban célszerű az egyes kiemelt implementációs technológiák esetében a formai megkötések egységesítése is. Az európai és amerikai szabványosítási folyamatok konvergenciájának egyik eredménye a MSZ CEN/TS 14796 néven a Magyar Szabványügyi Testület által is átvett CEN technikai specifikáció, mely az egészségügyi informatikában alkalmazandó egységes adattípusokat definiálja. Az ebben a TS ben meghatározott adattípusok az amerikai HL7 és az európai 13606 alapú szabványok és ajánlások által közösen használt típusok, melyek egységes használata megteremti a különböző megközelítésű rendszerek és alkalmazások közti interoperabilitás alapjait. Az MSZ 22800 as szabvány szintén a fenti adattípusokra épül, és a logikai specifikáción túlmenően az objektumok XML implementációját is meghatározza. Az ágazatban használt egyes szabványosított fogalmak (összetett típusok) specifikációját a portálon ki kell publikálni. Biztosítani kell a szabványosított fogalmak (összetett adattípusok) folyamatos karbantartását. Az ágazaton belül a kommunikációra vonatkozó, és a portálon közzétett specifikációkban az MSZ CEN/TS 14796 ban meghatározott adattípusokat, illetve az arra épülő, és a portálon publikált összetett adattípusokat kell alkalmazni. Az ágazaton belül a kommunikációra vonatkozó, és a portálon közzétett XML sémák ban a fenti adattípusoknak az MSZ 22800 ban meghatározott XML reprezentációját kell alkalmazni. Az ágazaton belül a kommunikációra vonatkozó, és a portálon közzétett XML sémák ban az összetett adattípusoknak a portálon publikált XML reprezentációját kell alkalmazni. Az egységes jelentés rendszerben alkalmazott időformátumok Gyakorlati szempontból szükséges a alkalmazható időformátumok kérdésének a fenti szabályozásnál részletesebb specifikációja a különböző szabványok által megengedett formátumok ésszerű korlátozásával. Az időformátumok egységes reprezentációját a CEN TS 14796 az időformátumokra vonatkozó ISO 8601 (MSZ/EN 28601) alapján szabályozza. Ugyanakkor ez a vonatkozó szabályozás az időformátumok egyszerű és összetett leírásának engedélyezésével, valamint a teljes, illetve részleges pontossággal megadott időformátumok nagyszámú változatával egy informatikailag ugyan lekezelhető, de nehezen áttekinthető szabályozásnak bizonyult. Gyakorlati problémát jelent továbbá, hogy az adatcsere alapjául szolgáló W3C XML Data Types specifikáció a dátum, időpont és időtartam objektumoknak bár szintén az ISO 8601 re alapozva, de azt erősen korlátozva csak a teljes, csonkolásmentes reprezentációját kezeli a beépített adattípusok szintjén. Ugyanakkor természetesen lehetőség van az egyedi időformátumok (pl. a nem teljes formák: év hónap, év, óra perc, stb.) XML adattípusként történő specifikációjára a String típus specializációjaként. 13/92

Az ágazaton belül a kommunikációra vonatkozó specifikációkban az idő adatok ábrázolására csak a portálon külön publikált formátumok alkalmazhatók. A javasolt időábrázolási formátumok jegyzékét a 9. melléklet tartalmazza. Standardizált ellátási alapdokumentáció kialakítása Az ellátási dokumentáció standardizálásának kérdésköre két nagy, logikailag egymásra épülő területre témakörre bontható: a tartalmi és a formai egységesítés kérdéskörére. A tartalom egységesítése az ellátási dokumentumok típusainak, a dokumentumok elvárt tartalmának, belső felépítésének meghatározására azaz informatikai értelemben egy logikai modell létrehozására irányul, míg a formai egységesítés célja a rendszerek közötti adatcsere megkönnyítése, a rendszerek közötti interoperabilitás biztosítása az alkalmazandó reprezentációs technikák specifikálásával. A két terület külön kezelendő, hiszen különböző kompetenciákat igényel: a tartalmi egységesítés elsősorban orvosszakmai, míg a formai elsősorban információtechnológiai kérdés. Könnyen belátható, hogy a tartalmai egységesítés meg kell előzze a formai egységesítést, hiszen ha pusztán a formátumban egyeznénk meg, attól még egységes szakmai tartalmú kommunikáció nem jöhet létre. Ugyanakkor az is értelemszerű, hogy egy egységesített tartalmú dokumentáció akár különböző formákban is megjelenhet. Ugyanaz az adattartalom leképezhető a HL7 CDA szerint, de megjeleníthető a CEN 13606 által leírt objektumokkal is azaz egy egységes adattartalomnak lehet többféle formális specifikációnak megfelelő leképezése. A standardizált alapdokumentáció kialakításának ezért a logikai szintű egységesítés a célja, ennek reprezentációja pedig akár informatikai, akár papír alapú is lehet. Ki kell alakítani az alapdokumentáció egységes dokumentum típusait, azok elvárt tartalmi elemeinek meghatározásával. Ki kell alakítani az egyes dokumentumokban alkalmazható adatcsoportok szekciók típusait, azok elvárt tartalmi elemeinek meghatározásával. Az egyes definiált dokumentum típusokat egyedi OID vel regisztrálni kell, és a specifikációjukat a portálon ki kell publikálni. Az egyes definiált szekció típusokat egyedi OID vel regisztrálni kell, és a specifikációjukat a portálon ki kell publikálni. Biztosítani kell az így kialakított rendszer folyamatos karbantartását. A folyamatos fejlesztés érdekében létre kell hozni és a portálon publikálni kell az új típusok bevezetésének eljárásrendjét. Az alapdokumentáció egységes típusainak javasolt alapkészletére vonatkozó részletes specifikáció a 8. mellékletekben található. Egységes ágazati jelentés rendszer Az egységes jelentési rendszer kialakításának ki kell terjedni a jelentések tartalmi és formai egységesítésére (egységes jelentés objektum), illetve a jelentések átadás átvételével kapcsolatos folyamatok egységesítésére, az egységes jelentés workflow kialakítására. Egységes jelentés objektum A jelentések egy közös modellel rendelkeznek: 14/92

class Jelentés Jelentés 0..* Fej Tétel - egyedi azonosító Beküldő - Eü. intézmény - Elérhetőség Idő-adatok - Vonatkozási időszak - Létrehozás időpontja Leírók - Egyedi azonosító - Előző jelentés - Típus - Verzió Az egyes jelentések szöveges és formális specifikációját a portálon publikálni kell. Ki kell alakítani és implementálni kell az új jelentések bevezetéséhez szükséges eljárásrendet. A jelentések belső felépítésével kapcsolatban: A jelentés fej része tartalmazza a jelentésre vonatkozó metaadatokat (ezek a metaadatok bár sok hasonlóságot, több esetben átfedést fognak mutatni nem tévesztendők össze a kommunikációban az egyes üzenetekhez csatolt metaadatokkal!) Az egyes jelentés objektumok globálisan egyedi azonosítóval kell, hogy rendelkezzenek (ez lehet pl. a kibocsátó egyedi azonosítójából és a kibocsátóra nézve egyedi sorozatszámból képzett azonosító, amely így már globálisan egyedi azonosítóként alkalmazható) Minden konkrét jelentéssel kapcsolatban meg kell határozni, hogy a jelentés javítható e, vagy sem, és a jelentés szöveges specifikációjában publikálni kell a javítás feltételeit (pl. javításra nyitva álló időszak). Amennyiben egy jelentés javítható, úgy specifikálni kell, hogy a jelentés csak egészben módosítható, vagy a jelentés egyes tételei külön külön módosíthatók. Amennyiben egy jelentés tételei külön külön módosíthatók, az egyes tételeket globálisan egyedi azonosítóval kell ellátni. Egységes jelentés workflow Az ágazati jelentésekkel kapcsolatos összes kommunikáció az ágazati portálon keresztül kell, hogy megtörténjen. Ez lehetővé teszi az a jelentés workflow általánosítását. A jelentésre kötelezettek a portálnak küldik el a jelentéseiket. A portál a beérkezett jelentéseket regisztrálja, nyugtázza, validálja, majd továbbítja azt az ágazatirányítás megfelelő intézménye, a jelentés címzettje felé. A címzettek a portálon keresztül küldik vissza a hibajelzéseket. A jelentések validációjának három szintje különíthető el: 15/92

1. formai validáció: A formai validáció során a jelentés formailag kerül ellenőrzésre. Ennek során ellenőrzésre kerül: a jelentés specifikációnak való formai megfelelése, (az üzenet megfelelő szerkezetű: XML állomány XSD alapú validációja, CSV állomány szerkezete megfelelő e) a metaadatok teljessége és helyessége az üzenet azonsító egyedisége a beküldő esetleges jogosultsága 2. első szintű tartalmi validáció: ennek során a jelentést, mint önálló, zárt egységet vizsgálva annak belső szemantikai szabályai kerülnek ellenőrzésre. Ez a lépés mely nem igényli az adatok hosszú idejű tárolását (azaz csak az adott jelentésen belüli adatokat ellenőrzi egy szabálybázis alapján, nem végez konzisztencia vizsgálatot más jelentésekkel) 3. részletes validáció: ez a jelentés teljeskörű validálását tartalmazza, beleértve az előzményjelenétsekkel, vagymás típusú jelentésekkel történő összevetését, a köztük lévő konzisztencia vizsgálatát, illetve a jelentés címzettjének belső adataival történő összevetést. 16/92 Adatvédelmi okokból a portál csak a validáláshoz szükséges minimáls ideig tárolhatja az egészségügyi és személyes adatot tartalmazó jelentéseket. Az 1. szintű validáció lehetőség szerint az üzenet átvételének kritériuma legyen, azaz sikertelen validálás esetén a jelentés azonnal visszautasításra kerül. Amennyiben egy adott jelentés típus esetében az azonnali 1. szintű validálás nem lehetséges (pl. a méretéből eredő futásidő igény miatt), az üzenet átvételéről a rendszer nyugtát ad. Amennyiben az 1. szintű validálás elválik az üzenet átvételétől, a validálást a lehető leghamarabb el kell végezni, hogy sikertelenség esetén a küldő a lehető leghamarabb kapjon visszajelzést a sikertelen 1. szintű validálásról. A 2. szintű validálás lehetőség szerint a beküldéshez időben minél közelebb történjen meg, hogy a meghiúsult validálásról a beküldő a lehető legrövidebb időn belül visszajelzést kapjon. Az 1. és 2. szintű validálás a portálon kerül végrehajtásra. Bizonyos típusú jelentések esetében a 2. validációs szint elmaradhat (azaz ekkor a formai elfogadás után a portál a jelentést azonnal a címzetthez továbbítja). A 3. szintű validálást mindig a jelentés címzettje végzi. Mindhárom szintű ellenőrzés esetén a küldő értesítést kap a validáció eredményéről, hiba esetén a hiba megfelelő részletezettségű leírásával. A portál által ellenőrzött validációs szabályokat a portálon ki kell publikálni. Összetett (több címzetthez eljuttatandó) jelentések esetén a portál szétszedi a rekordokat címzettek által igényelt adatkörökre, és az így leválogatott adatokat küldi tovább. Ez a mechanizmus hatékonyan csökkentheti a rendszerben jelen lévő párhuzamos adatküldéseket, ugyanakkor felveti a javítás kérdését. Amennyiben egy ilyen jelentés valamelyik címzett által visszautasításra kerül, a feladó értesítése mellett értesíteni kell a többi címzettet is arról, hogy az adott jelentés vagy tétel valamilyen szempontból hibás adatot tartalmaz(hat). A jelentés továbbítás, illetve visszajelzési mechanizmusok kialakításának követelményei: A portál a beérkezett és továbbított üzeneteket az üzenetek egyedi azonosítója alapján naplózza. A jelentések továbbítására, illetve a címzettektől történő visszajelzésre megfelelő interfészeket ki kell alakítani. A portál a beküldők számára a visszajelzéseket legalább a következő formákban biztosítsa: email en a beküldött jelentések státuszának lekérdezésére vonatkozó web service en keresztül Az egységes jelentés rendszert támogató egykapus megoldás egyik előnye, hogy a portál nemcsak ellenőrizni tudja, hogy egy adott jelentés beküldésére az authentikált beküldő jogosult e, hanem a portál felhasználóinak (tk. a jelentés küldők) típusa alapján az egyes beküldőkre vonatkozó jelentési kötelezettségek alapján proaktívan tudja ellenőrizni a kötelező jelentések teljesítettségét. A portálon össze kell tudni rendelni kell az egyes szolgáltató típusokhoz kötött kötelezően küldendő, illetve a küldhető jelentéseket az egyes szolgáltatókkal, az alábbi modell szerint.

class Jelentés kontroll Rule Eü. szolgáltató típusa 0..* Jelentési kötelezettség 1..* 0..* Eü. szolgáltató 0..* Elvárt jelentés 0..* A fenti modell alapján a portálon a jelentések teljesítettségének nyilvántartása mellett további, az szolgáltató figyelmeztető üzenete küldő funkciók is kialakíthatók. Azonosítók, kódrendszerek nyilvántartások Egységes intézmény (ellátó) azonosítási rendszer Az ágazaton belüli adatszolgáltatási, jelentési rendszer felmérése rámutatott arra, hogy a rendszerben a szolgáltatók (ellátók) azonosítása sok esetben esetleges, nem átgondolt azonosításon alapszik. Ez kétféle anomáliához vezet: vagy a jelentés adattartalma torzul, mert az adatszolgáltatók kénytelenek az előírt azonosítók által meghatározott felosztáshoz igazítani a jelentés tartalmát, vagy a ténylegesen használt azonosító értelmezése, esetleges pontosítása a gyakorlatban alakult ki és mintegy best practice ként él. A jellemző problémát az okozza, hogy egy ellátó többféle azonosítóval is rendelkezik, függően attól, hogy milyen funkcionális nézetből vizsgáljuk. A fő azonosítási rendszerek: 1. Jellemzően minden ellátó (szolgáltató) rendelkezik (egy vagy több) olyan azonosítóval, mely a szolgáltató engedélyezett jellegéből ered. Ennek forrása jellemzően az ÁNTSZ, és ezeket általánosságban ÁNTSZ azonosítóként aposztrofálják. 2. A szolgáltatóknak azon csoportja, akik az OEP pel finanszírozási szerződéssel rendelkeznek, rendelkeznek egy vagy több finanszírozási azonosítóval. Ezek forrása az OEP, és ezeket általában OEP azonosítóként aposztrofálják. 3. A szolgáltatóknak egy speciális csoportja, az orvosok, az orvos nyilvántartás szerinti egyedi azonosítóval, az ún. pecsétszámmal rendelkeznek. A pecsétszám ugyanakkor az orvos egyedi azonosítója mellet tartalmaz egy pecsét sorszámot is, így ennek használatában is felmutatható eltérő gyakorlat. 4. A fenti azonosítókon kívül az ágazatban léteznek még egyéb kibocsátott azonosító is, mint a gyógyszer területén a MEP ek által kibocsátott partnerkód, míg pl. a Rákregiszter egyedi szervezeti egység azonosítást használ minden intézményen belül. 17/92

A fenti azonosítók használata elvben attól kellene, hogy függjön, hogy a jelentés tartalma alapján működési jellegű, finanszírozási jellegű, vagy milyen aspektusból várják az adatszolgáltatást, és az ezen területhez tartozó azonosító rendszert kellene használni. A legnagyobb anomáliát az okozza, hogy bár sok esetben az adatszolgáltatás működési jellegű adatokat tartalmaz, mégis, a szervezeti egység azonosítása a finanszírozási azonosítókra épül. Ennek hátterében az egyes azonosító rendszerek közötti kapcsolat jellege áll: Elfogadva azt az állítást, hogy minden szolgáltatónak rendelkeznie kell engedéllyel a tevékenysége végzéséhez, az engedély alapú azonosítók a legszélesebb azonosító kör. Erre épül ennek részhalmaza a finanszírozási azonosítók rendszere hiszen finanszírozást csak engedéllyel rendelkező entitás kaphat. A legnagyobb problémát az jelenti, hogy azon ellátók esetében, akik mindkettővel rendelkeznek (és jellemzően a szolgáltatók többsége ilyen) a két azonosító rendszer nem egy egy, de még csak nem is egy több jellegű kapcsolattal írható le, hanem egy több több es kapcsolattal, ami így ugyanannak az entitásnak többféle felosztását eredményez(het)i. class objektumok ÁNTSZ engedély - 6 jegyű ÁNTSZ azonosító 1..* Eü. ellátó 0..1 OEP finanszírozási szerződés OEP ellátó azonosító 1..* Szervezeti egység 0..* 4 jegyű azonosító 6 jegyű azonosító 1..* 0..* 1..* ÁNTSZ részleg szintű engedély - 9 jegyű ÁNTSZ azonosító Eü. ellátó részleg - 9 jegyű OEP kód [0..1] 0..* OEP finanszírozott tevékenység - Feladat - Kapacitás 1..* Tevékenység Telephely Ugyancsak általános problémája a jelenlegi rendszereknek, hogy nem egyértelműen kezelik le az intézmények hierarchikus jellegét. Egyes esetekben az adatszolgáltatás szintje a finanszírozott egység, míg más esetekben magát az intézményt kell jelenteni. A különböző szempontú azonosító rendszerek összehangolásának alapja mindenképpen az ágazat egységes fogalmi rendszerének kialakítása lenne. Az egységes fogalmi rendszerben minden definiált entitás önálló azonosítóval kerülhet ellátásra mely értelemszerűen lekezeli a különböző hierarchiákat, illetve reflektál az egyes intézmény típusok belső felépítésére, és az egyes, különböző területhez tartozó nyilvántartások összehangolását az ezekre történő hivatkozással lehet biztosítani. Ugyanakkor a realitásokat is figyelembe véve elégséges lehet a jelenlegi, egymástól esetleg független nyilvántartási rendszerek megtartása mellett az egyes azonosítók egymáshoz való viszonyának formális leírása és publikálása, és ennek alapján egy olyan konszolidáló jellegű nyilvántartás létrehozása, mely az egyes intézmények különböző azonosítói közötti összefüggéseit lekérdezhető módon teszi elérhetővé az ágazat szereplői számára. Az ágazat egységes fogalmi modelljének tartalmazni kell az egyes entitások azonosításának módját, illetve tartalmaznia kell a jelenleg használt azonosító rendszereket. 18/92

Ez modellnek tartalmazni kell az egyes különböző azonosító rendszerek közötti kapcsolatok formális leírását. Az azonosítási rendszernek ki kell terjedni az ágazatirányítás intézményeire is azaz minden intézményt önálló egyedi azonosítóval kell ellátni. Minden egyes, a portálon publikált specifikációban egyértelműen meg kell adni, milyen azonosító(k) használata megengedett az adott adatszolgáltatásban. Az ellátók azonosítására használható egyes azonosító rendszereket az OID rendszerben önálló OID vel regisztrálni kell. Az egyes entitások egyedi azonosítóit az egyértelmű fogalmi azonosíthatóság érdekében az adatkommunikációban egy egy II típusú objektum írja le, melynek root értéke az azonosító rendszer OID je, extension értéke pedig az adott azonosítási rendszer szerinti azonosító. class Ellátó azonosítás Ellátó «Represented by» II ÁNTSZ azonosító - root = OID_ANTSZ_AZONOSITO OEP azonosító - root = OID_OEP_AZONOSITO Orvosazonosító - root = OID_ORVOS_AZONOSITO Az egyes azonosítók mögött álló nyilvántartásokat a portálon elérhetővé és lekérdezhetővé kell tenni az arra jogosult szereplők körében. Egységes ellátott azonosítás Az ellátottak azonosítása terén a magyar jogrendben definiált TAJ nemzetközileg is elismerten az ágazat egyik legnagyobb előnye. A TAJ fogalomnak megfelelő egységes azonosítóval nem rendelkező külföldi rendszerek egyik legnagyobb problematikája, hogy hogyan lehet a különböző forrásrendszerekben tárolt természetes személyazonosító adatok alapján az egyes ellátottról rendelkezésre álló adatokat összekapcsolni, azokhoz hozzáférni. Ez a helyzeti előny a gyakorlatban azt jelenti, hogy az informatikai rendszerekben tárolt ellátási adatok az ellátások meghatározó hányadánál (értelemszerűen a TAJ megfelelő használata esetén) egyértelműen az ellátotthoz köthetők, és ezen adatkörökre a kereshetőséget, lekérdezhetőséget automatikusan biztosítani lehet. Ezen a körön kívül a speciális esetek kerülnek: nem magyar állampolgár ellátása, ismeretlen ellátott, képzett TAJ alkalmazása (újszülöttek esetén), stb. Az ellátottak azonosításának másik sarkalatos kérdése a természetes személyazonosító adatok használata. 19/92

A természetes személyazonosító adat jellemzően a személy családi és utóneve, születési családi és utóneve, neme, születési helye és ideje, anyja születési család és utóneve, állampolgársága (illetve bevándorolt, letelepedett vagy menekült jogállása), illetve lakó és tartózkodási helye. 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) 4 szerint: Természetes személyazonosító adat a polgár a) családi és utóneve, születési családi és utóneve, b) születési helye, c) születési ideje és d) anyja születési családi és utóneve. TAJ számmal történő azonosítás esetében a természetes személyazonosító adatok használata nem szükséges hiszen az TAJ nyilvántartás jellegénél fogva tartalmazza azokat. Ugyanakkor nem TAJ alapú azonosítások esetében a természetes személyazonosító adatok használata indokolt és célszerű lenne ez jelenleg teljességgel hiányzik a rendszerből. Minden egyes, a portálon publikált specifikációban egyértelműen meg kell adni, milyen ellátott azonosító(k) használata megengedett az adott adatszolgáltatásban. Az ellátók azonosítására használható egyes azonosító rendszereket az OID rendszerben önálló OID vel regisztrálni kell. Az egyes entitások egyedi azonosítóit az egyértelmű fogalmi azonosíthatóság érdekében az adatkommunikációban egy egy II típusú objektum írja le, melynek root értéke az azonosító rendszer OID je, extension értéke pedig az adott azonosítási rendszer szerinti azonosító. Az egyes azonosítók mögött álló nyilvántartásokat a portálon elérhetővé és lekérdezhetővé kell tenni az arra jogosult szereplők körében, különösen a ténylegesen ellátott személy valós személy személyazonosságának ellenőrzése céljából (azaz hogy az azonosításra használt TAJ azonosító valóban az adott ellátotthoz tartozik e?). Azon azonosítási módok esetében, ahol a portálon nem lehetséges az azonosító mögött álló nyilvántartás elérésének biztosítása, célszerű megfontolni az egyes jelentésekben az 1996. évi XX. törvény 4 szerint természetes személyazonosító adatok használatának kötelezővé tételét, a tényleges ellátott későbbi egyértelmű azonosíthatósága érdekében. Kódrendszerek egységes ábrázolása Az ágazat adatszolgáltatásainak jelentős része kódtáblákra, kódrendszerekre épül, és csak az adatok kisebb része tartalmaz valamilyen originális (nem kódolt) információt. Ezek jellemzően személyes adatok, mért értékek, mennyiségek. A használt kódolások jellemzően három nagy csoportba sorolhatók: 1. Nemzetközi kódrendszerek, esetleg azok hazai adaptációja. Ilyenek pl. a BNO, OEON kódok, a patológiában alkalmazott SNOMED CT kódok, vagy a labor területen széles körben alkalmazott LOINC kódok. 2. A különböző jelentésekben általánosan használt kódolások (pl. térítési kategória) 3. Az egyes jelentések, adatszolgáltatások önálló, specifikus kódrendszerei. A kódok használatának jellemző problémái az időben változó kódtáblák, illetve az egyes kódértékek jelentésének megváltozása. Az egyes kódtáblák időben eltérő megjelenéseit a kódrendszer verzióinak nevezzük. Egy időben mindig csak egy verzió lehet hatályban. A kódrendszerek egy közös adatmodellel rendelkeznek: 20/92

class Kódtáblák közös metamodellje CodingScheme - root: OID - codingschemename: string - owner: string - description: string [0..1] Version - codingschemeversion: string - description: string [0..1] - publicationdate: TS 1 0..* Code - codingvalue: string - displayname: string - description: string [0..1] - validitybegins: TS - validityends: TS - inversion: Version Az egyes kódrendszereket (kódolási sémákat) az OID rendszerben önálló OID vel regisztrálni kell. A jelentésekben használt kódok esetében a kód megadása egy CV értékkel történik, melyben a codingscheme értéke a kódrendszerhez tartozó OID, míg a codingvalue értéke maga a kód. Verziózott kódtáblák esetében meg kell adni a kódrendszer verzióját. Elfogadható olyan specifikáció, amely a verzió értékét opcionálisnak tekinti. Ebben az esetben az verziónak a kódot tartalmazó dokumentum kiadásakor érvényes kód verziót kell tekinteni. Az egyes kódrendszereket a portálon elérhetővé és letölthetővé kell tenni. A 3 as csoportba tartozó kódok esetében hatékonysági szempontból felmerülhet a kódértékek CSként azaz a coding Scheme elhagyásával, csak a kód érték szerepeltetésével történő ábrázolása, azonban ez az időben változó kódrendszerek esetében a verziók követését nehézkessé teszi, az egyértelműség rovására mehet, ezért használata nem javasolt. A portálon publikálásra javasolt kódrendszerek listáját az 5. melléklet tartalmazza. Nyilvántartások Az ágazat által használt összes kódtáblát és nyilvántartást kizárólag az ágazati portál publikálja. A nyilvántartások jellemzően: az egyes azonosítókat definiáló, az azonosított entitás egyes tulajdonságait tartalmazó nyilvántartások. Az ilyen nyilvántartásokat az azonosító forrásának nevezzük. (pl. a TAJ, mint azonosító forrása a TAJ nyilvántartás). egy másik nyilvántartás által definiált azonosítóhoz tartozó, de nem az eredeti nyilvántartás gazdája által az azonosítóhoz fűzött további adatokat tartalmazó nyilvántartások. (az előbbi példához kapcsolódva: a TAJ háziorvos összerendelés, mint nyilvántartás nem más, mint az egyes TAJ okhoz a háziorvos hozzárendelése, mint önálló jellemző.) A publikus mindenki számára hozzáférhető törzseket közvetlenül a portálba integrált közhiteles nyilvántartás szolgáltatás nyújtja, míg az érzékeny (személyes) adatot is tartalmazó nyilvántartásokat (pl. TAJ) a nyilvántartás tulajdonosa által üzemeltetett rendszer tárolja, a portál pusztán a központi hozzáférést biztosítja. Összetett nyilvántartások esetében az egyes nyilvántartások konszolidált megjelenítése a portál feladata. Az egyes nyilvántartások önálló modellel rendelkeznek, melyet a portálon publikálni kell. 21/92

Ez nyilvántartásnak egy gazdája lehet. Amennyiben egy azonosítóhoz több szervezet is kapcsolhat információt, úgy azokat külön, az eredeti elsődleges kulcsra épülő nyilvántartásként kell kezelni. A nyilvántartások elemenként változhatnak. Az rendszernek formálisan is tárolnia kell az egymásra épülő nyilvántartások között ennálló viszonyrendszert. Egy nyilvántartás megváltozása esetén a ráépülő nyilvántartások gazdáját a portálnak automatikusan értesíteni kell. A portálnak biztosítani kell legalább az alábbi funkciókat: le lehet kérdezni az adott nyilvántartás bármely kiválasztott időpontbeli állapotát, le lehet tölteni az összes verziót tartalmazó változatot (publikus nyilvántartás esetén), le lehet kérdezni, hogy megváltozott e az adott nyilvántartás, le lehet tölteni a nyilvántartás két megadott verziója közötti különbséget. A rendszernek lehetővé kell tennie a kódok (bizonyos esetekben a nyilvántartott entitások) közötti fogalmi kapcsolatok (alapvetően ekvivalencia) leírását. A rendszer által elérhetővé tett nyilvántartásokat a portálon regisztrálni kell. A nyilvántartásokat jellegük, a nyilvántartás által nyilvántartott adatok érzékenysége, stb. alapján az alábbi elérésekkel kell publikálni: a teljes nyilvántartás letöltése elemenkénti hozzáférés, szükség esetén bizonyos oszlopok elrejtésével a nyilvántartásban történő szereplés tényének lekérdezése Az egyes nyilvántartásokhoz történő hozzáférés jellege és módja is a konkrét felhasználó jogosultságaitól függően eltérő is lehet. (pl. a TAJ háziorvos összerendelés esetében az ellátó csak TAJ alapon, az konkrét TAJ hoz aktuálisan hozzátartozó háziorvoshoz férhet hozzá; az ellátott TAJ alapon, de a saját TAJ ára nézve a teljes történethez a korábbi háziorvosok listájához hozzáféhet, míg egy háziorvos a saját magához tartozó összes TAJ listázására is jogosult). A portálon publikálásra javasolt kódrendszerek listáját az 4. melléklet tartalmazza. Kommunikáció biztonságára vonatkozó ajánlások Tekintettel arra, hogy az ágazati kommunikációban egészségi állapotra vonatkozó személyes adatok kerülne továbbításra, különösen fontos az adatok megfelelő technológiákkal történő védelme. Csatorna védelme (Kommunikáció) Az küldő és a fogadó önmagában hiába tesz meg mindent az adatok védelme érdekében, ha az adatátadás csatornája nem megbízható, az egyébként titkos, bizalmas (személyes) adatokhoz illetéktelenek is hozzáférhetnek, rosszabb esetben akár módosíthatják is azokat. Ennek érdelében: az ágazatban egészségügyi adatok továbbítására csak megfelelően védett csatorna alkalmazható. a csatorna védelmére alkalmazható a végpontok között felpülő VPN kapcsolat. Ebben az esetben a végpont azonosítása már VPN szinten megtörténik, így ez a technológiai a felhasználó azonosítására is részben vagy egészben alkalmas lehet. Nem VPN en alapuló on line (http) alapú kommunikáció esetében https kapcsolat szükséges a csatorna védelmére. Nem VPN en alapuló fájl alapú kommunikáció esetében megfelelő erősségű védett protokoll (sftp, ssh) alkalmazandó. Nem VPN en alapuló fájl alapú kommunikáció esetében nem védett csatornán történő továbbítás esetén a továbbított információt megfelelő erősségű titkosítással védeni kell. Erre a javasolt megoldás a legalább 2048 bites kulccsal védett aszimmetrikus kulcsos titkosítás alkalmazása. Felhasználó azonosítás (Kommunkáció) Az egyes nyilvántartásokhoz történő hozzáférések szintje, illetve megengedett módja függhet a kliens típusától, illetve egyéb jellemzőitől. 22/92