Pentaschool Oktatási Központ
Számítástechnikai programozó
SZAKDOLGOZAT
DREAM - Gyógyszerügyi nyilvántartó rendszer
Dr. Zajzon Gergely
Számítástechnikai programozó
OKJ 54 4641 04
Budapest
2007
i
NYILATKOZAT
Alulírott Dr. Zajzon Gergely, számítástechnikai programozó szakos
hallgató kijelentem, hogy az általam készített DREAM - Gyógyszerügyi
nyilvántartó rendszer című szakdolgozat és annak részei egyenként is saját
szellemi termékek.
Ellenkező esetben az előírt hivatkozásokat az előírásoknak megfelelően
alkalmaztam.
Tudomásul veszem továbbá, hogy plágium esetén a szakdolgozat, az
elbírálás bármelyik fázisa során elégtelennek minősíthető.
Budapest, 2007. március 30.
Dr. Zajzon Gergely
Számítástechnikai programozó
ii
TARTALOMJEGYZÉK
BEVEZETŐ ........................................................................................................................ 1
Informatikai háttér........................................................................................................... 1
FELHASZNÁLÓI KÖVETELMÉNYEK .......................................................................... 2
A végrehajtás célja .......................................................................................................... 2
Törzskönyvezés (Forgalomba hozatali engedélyezés).................................................... 2
Jelenlegi helyzet áttekintése............................................................................................ 3
RENDSZERTERV.............................................................................................................. 4
Adatbázis tervezés........................................................................................................... 4
Az adatbázis tervezésének menete .................................................................................. 4
Elméleti model – Conceptual Data Model .................................................................. 4
Fizikai model – Physical Data Model ......................................................................... 4
Adatbázis generálása .................................................................................................. 5
Az adatbázisban használt névkonvenciók....................................................................... 5
Táblák elnevezései....................................................................................................... 6
Mezők elnevezése ........................................................................................................ 6
Az adatbázis szerkezete................................................................................................... 6
A Gyógyszernyilvántartó adatbázis táblái .................................................................. 7
Az Ügymenetkövető rendszer táblái ............................................................................ 8
A KEZELŐI FELÜLET LEÍRÁSA.................................................................................. 10
Alkalmazott névkonvenciók ......................................................................................... 10
A RENDSZER FŐ FUNKCIÓINAK LEÍRÁSA ............................................................. 10
Bejelentkező űrlap - frmLogin ...................................................................................... 10
buttonLogin ............................................................................................................... 10
Menü űrlap – frmMenu ................................................................................................. 10
buttonProductSelector............................................................................................... 10
buttonCaseSelector ................................................................................................... 11
buttonRegistry ........................................................................................................... 11
buttonQuit ................................................................................................................. 11
TERMÉK ADATBÁZIS............................................................................................... 11
iii
Termékválasztó űrlap - frmProductSelector ................................................................. 11
buttonProductAdd ..................................................................................................... 11
buttonProductEdit ..................................................................................................... 11
Termék adatlap – frmProductCard................................................................................ 12
buttonPacksize........................................................................................................... 12
buttonIngredient ........................................................................................................ 12
buttonManufacture .................................................................................................... 12
buttonAnnex............................................................................................................... 12
Termék adatlap - segédűrlapok ..................................................................................... 12
frmProductPacksize - frmProductPacksizeSub......................................................... 12
frmProductIngredient - frmProductIngredientSub ................................................... 12
frmProductManufacture - frmProductManufactureSub ........................................... 12
frmProductAnnex - frmProductAnnexSub................................................................. 13
ÜGYMENETKÖVETŐ................................................................................................ 13
Ügymenet választó űrlap – frmCaseSelector ................................................................ 13
buttonCaseAdd .......................................................................................................... 13
buttonCaseEdit.......................................................................................................... 13
Ügymenet adatlap - frmCaseSelector........................................................................... 13
IKTATÓKÖNYV – REGISTRY.................................................................................. 14
Iktatott levél választó űrlap - frmRegistryLetterSelector.............................................. 14
buttonRegistryAdd..................................................................................................... 14
buttonViewLetter ....................................................................................................... 14
Iktatókönyv adatlap – frmRegistry Add........................................................................ 14
buttonClose ............................................................................................................... 15
buttonCloseWindow .................................................................................................. 15
ALKALMAZOTT MEGOLDÁSOK RÉSZLETES LEÍRÁSA....................................... 16
1. Belépés a rendszerbe ............................................................................................. 16
2. Dokumentum archiválás a DREAM rendszerrel................................................... 23
Az archivált dokumentumokkal kapcsolatos információk tárolása........................... 24
Az archivált dokumentumok elnevezése .................................................................... 24
A dokumentum feltöltés menete ................................................................................. 25
iv
A feltöltött dokumentumok visszakeresése ................................................................ 29
3. Ügymenetek határidejének követése..................................................................... 29
ÜZEMELTETÉSI DOKUMENTÁCIÓ............................................................................ 31
A rendszer első üzembehelyezéséhez szükséges lépések ............................................. 31
A rendszert működtető szerver beállításai ................................................................ 31
Javaslat a könyvtárrendszerre .................................................................................. 31
ANNEX alkönyvtár .................................................................................................... 32
LETTER alkönyvtár................................................................................................... 32
TASK alkönyvtár ....................................................................................................... 32
Kliens igény ............................................................................................................... 33
Napi feladatok ............................................................................................................... 33
Havi feladatok ............................................................................................................... 33
BŐVÍTHETŐSÉG, TOVÁBBFEJLESZTHETŐSÉG ..................................................... 34
FOGALOMTÁR............................................................................................................... 36
BIBLIOGRÁFIA .............................................................................................................. 41
MELLÉKLETEK.............................................................................................................. 42
1
BEVEZETŐ
A DREAM a gyógyszerek törzskönyvezési (Regulatory), engedélyezési
folyamatainak követésére kialakított informatikai rendszer.
Miért DREAM? - tehetik fel jogosan a kérdést. A DREAM a Drug Regulatory
Electronic Affair Management elnevezést röviditő mozaikszó, amely angolul az álom
szót is jelenti. Bízom benne, hogy az általam kialakított gyógyszerügyi nyilvántartó
rendszer felhasználói számára a gyógyszerek engedélyezésével kapcsolatos bonyolult
munkafolyamatokat valóban álomszerűen egyszerűvé varázsolja.
A Drug Regulatory Electronic Affair Management szóösszetétel ötlete a
gyógyszertörzskönyvezési ügyek intézésével foglalkozó csoportok „DRA” (Drug
Regulatory Affairs) elnevezéséből született meg.
Informatikai háttér
A szakdolgozatban bemutatott verzió Microsoft Accesst használ adatbázis
motornak. A felhasználók számára elkészített kezelői felület elkészítéséhez 4. generációs
fejlesztő eszközként szintén a Microsoft Accesst használtam, illetve az Access nyújtotta
lehetőségeket VisualBasic kódokkal egészítettem ki.
A Microsoft Access mint adatbázismotor használata csak néhány (maximum 5-10)
felhasználó esetében javasolt. A rendszer szükség esetén átalakítható, pl. amennyiben a
felhasználók száma vagy a nyilvántartásra, feldolgozásra kerülő adatok mennyisége
növekszik, a rendszer adatbázismotorja kicserélhető Microsoft SQL Server
adatbázismotorra. (ld. még a dolgozat BŐVÍTHETŐSÉG,
TOVÁBBFEJLESZTHETŐSÉG című fejezetét.)
2
FELHASZNÁLÓI KÖVETELMÉNYEK
A rendszer alapdokumentumainak a gyógyszertörzskönyvezés folyamatát szabályozó
törvények, rendeletek és rendelkezések tekinthetőek. Ennek megfelelően a rendszerterv
elkészítésekor az Országos Gyógyszerészeti Intézetben törzskönyvezési folyamatokkal
kapcsolatban szerzett ismereteimet használtam fel, illetve felmérő interjú során ezekben
leírt folyamatok szerint készítettem interjúkat a megrendelő törzskönyvezési (DRA vagy
Regulatory csoport) szervezeti egységeinek szakembereivel.
A végrehajtás célja
A DREAM rendszer célja az alábbiakban foglalható össze:
A DREAM rendszer gyógyszergyártással foglalkozó cégek képviseletei számára
készül.. A rendszer felállításával a cél a gyógyszerekkel kapcsolatos komplex
ügyek intézésének megkönnyítése.
Törzskönyvezés (Forgalomba hozatali engedélyezés)
• A törzskönyvezés az Országos Gyógyszerészeti Intézet (továbbiakban OGYI)
által végzett gyógyszer engedélyezési folyamat, mely elvégeztetése nélkül
Magyarországon nem lehet gyógyszert forgalomba hozni (kivételt képeznek
2004. május 1, Magyarország EU csatlakozása óta, az EMEA által
engedélyezett ún. centralizált készítmények).
• A Regulatory Csoport (DRA Csoport) feladata a törzskönyvezési folyamat
koordinálása, kapcsolattartás az OGYI-val. A törzskönyvezési feladatok
előkészítése.
3
Jelenlegi helyzet áttekintése
Magyarországon nagyon kevés gyógyszer cég Regulatory csoportja
rendelkezik önálló, hazai célokra kifejlesztett nyilvántartó rendszerrel.
A DREAM rendszer kialakításának célja, hogy a magyarországon
törzskönyvezéssel foglalkozó cégek saját programrendszerrel, önállóan, a
hazai speciális igényeknek megfelelően tudják végezni az adataik
nyilvántartását. Többek között azért, hogy a törzskönyvezési adatok
rögzítésével az adatbázis rendszernek köszönhetőn az adataikat több
célúan újra tudják használni.
4
RENDSZERTERV
Adatbázis tervezés
Az adatbázis tervezéséhez a Sybase Power Designer nevű fejlesztő eszközét használtam.
Az adatbázis tervezésének menete
Elméleti model – Conceptual Data Model
A tervezést az elméleti adatmodel (CDM) elkészítésével kezdtem el. Az elméleti
adatmodel elkészítése során a törzskönyvezéssel foglalkozó cégektől összegyüjtőtt
információk, illetve az OGYI-s tapasztalatok alapján felmértem, hogy milyen adatokat
kell a rendszerben nyilvántartani, milyen táblákra lesz szükség az adatbázisban.
A DREAM rendszert két fő részre bontottam fel:
1. Product Database – Terméknyilvántartó adatbázis
2. WFM – Work Flow Management – Ügymenetkövető rendszer
Az elméleti adatmodell készítésének lépései az alábbiak voltak:
1. Entitások (entity) listájának készítése
2. Entitások leírásának készítése
3. Attributumok definiálása (entity attributes)
4. Kapcsolatok (relationships) definíálása
5. Elméleti model ellenőrzése
Az elkészített Conceptual Data Modelről szóló jelentést és adatkapcsolati ábrát
mellékletként csatoltam a dolgozathoz.
Fizikai model – Physical Data Model
5
A fizikai modelt az elméleti model (CDM) ellenőrzését követően generáltam a Power
Designer segítségével. A fizikai adat modelben, szemben a CDMel, már részletesen
definiáltam a táblakapcsolatokat, beillesztettem a táblákba a kapcsolatokhoz szükséges
foreign key mezőket.
Adatbázis generálása
A PowerDesignerben lehetőség van fizikai modelből adatbázis generálására. Ehhez első
lépésként be kell állítani az adatbázis kapcsolatot. A dolgozatban bemutatott rendszer
Microsoft Acesst használ adatbázismotorként, ezért a kapcsolatokat ennek megfelőlen
kellett beálítani.
Az adatbázis tábláinál elsődleges kulcsként integer mezőt állítottam be az elméleti
adatmodelben. Szemben az Accessel, más SQL alapú adatbázis motoroknál lehetőség
van a fizikai adatmodelben az integer mező automatikas nővelésének beállítására
(AutoIncrement). A Microsoft Access esetében ebben az esetben az adattípust kell
integerről AutoIncrementre (AutoNumber vagy Számláló). Ezért a fizikai model összes
olyan táblájában, ahol integer volt a primary key, el kellett végezni az adattípus
átállítását.
Kivételt képezett a dicCountry (ország szótár –PK az ISO-3166 táblában használt 2
karakterből álló ország azonosító) és a dicTDoc (dokumentu típus szótár tábla – PK pl. a
doc a Microsoft Word dokumneumoknál vagy pdf a PDF állományok esetében), mivel
itt char adattípusú PK-t használtam.
A megfelelő beállítások elvégzése után generáltam a dream_data.mdb táblát, amely a
rendszer adattábláit tartamazza.
Az adatbázisban használt névkonvenciók
Az adatbázis kialakítása során a könnyebb áttekinthetőség érdekében az alábbi
elnevezési szabályokat alkalmaztam.
6
Táblák elnevezései
CORE főtábla
DIC szótártábla
SUB altábla
SYS a rendszer működéséhez szükséges adminisztratív táblák
A DICT kezdetű táblákban a T a type szóra utal, ez különböző típusszótárakat jelöl, pl.
DICTDOC (dicTDOC) = Documentum Type szótártábla
Mezők elnevezése
MINTA_ID azonosításra szolgáló mező (unique identifier, Primary Key,
általában AutoIncrement, integer)
MINTA_STR szöveges mező (általában varchar, 255)
MINTA_NUM szám mező (általában integer)
MINTA_DT dátum mező (datetime)
MINTA_LOG logikai mező (bit)
Az adatbázis szerkezete
A DREAM rendszerhez használt adatbázis két elkülöníthető adatbázisrészből tevődik
össze:
1. Gyógyszer nyilvántartó adatbázis
2. Ügymenetkövető rendszer
Az adatbázis részletes szerkezeti leírását és kapcsolati rajzát a mellékletként csatolt
Physical Data Model – Report tartalmazza. Az alábbiakban csak az adatbázis két ő
részének táblái kerülnek felsorolásra.
7
A Gyógyszernyilvántartó adatbázis táblái
Főtáblák:
coreTradename Márkanevek litája
coreProduct Termék tábla
corePacksize Kiszerelés tábla
Altáblák:
subAnnex A gyógyszerek és a hozzájuk tartozó mellékletek összerendelése
subIngredient A gyógyszerek és a hozzájuk tartozó hatóanyagok összerendelése
subManufacture A gyógyszerek és a hozzájuk tartozó gyártóhelyek összerendelése
Szótártáblák:
dicAtc ATC kódok listája
dicCountry Ország lista
dicDosageForm Gyógyszerformák listája
dicEffectCross Hatáserősségi kereszt besorolás lehetséges értékei
dicIngredient Hatóanyagok, segédanyagok listája
dicMah Forgalomba Hozatali Engedély Jogosultak listája
dicManufacture Gyártócégek listája
dicMeasureUnit Mértékegységek listája
dicQuantityOperator Mennyiség operátor
dicPrescription Kiadhatóság (Rendelhetőség) szótár
dicStatus Törzskönyvi státusz
dicTAnnex Csatolt mellékletek típusa
dicTDoc Dokumentum típus lista
dicTIngredient Hatóanyag típus lista
8
dicTManufacture Gyártó típus szótár
dicTProduct Terméktípus szótár
A táblák és adatmezők részletes leírását a mellékletként csatolt Physical Data Modelről
szóló jelentés tartalmazza.
Az Ügymenetkövető rendszer táblái
Főtáblák:
coreCase ügymenet tábla
coreClockStop óra leállítások táblája
coreCompany cég tábla
coreProduct termék tábla
coreTask feladat tábla
coreRegistry iktatókönyv
Altáblák:
subContact a cégekhez tartozó személyek adatait tartalmazó altábla
subLetterCase ügymenetek és levelek összerendelése
subCaseUser ügymenet felelősőket tartalmazó altábla
Szótártáblák:
dicTCase ügymenettípus lista
dicTDoc fájl kiterjesztés lista
dicTLetter levelek típusa: kimenő / bejövő
dicTTask esemény típus lista
sysUser felhasználók listája
9
A táblák és adatmezők részletes leírását a mellékletként csatolt Physical Data Modelről
szóló jelentés tartalmazza.
10
A KEZELŐI FELÜLET LEÍRÁSA
Alkalmazott névkonvenciók
buttonXXX gomb
frmXXX űrlap
lstXXX lista, kombinált lista
qryXXX lekérdezés
txtXXX beviteli mező
A RENDSZER FŐ FUNKCIÓINAK LEÍRÁSA
Bejelentkező űrlap - frmLogin
Gomb(ok):
buttonLogin
Jelszóellenőrzés, belépés az adatbázisba
Menü űrlap – frmMenu
A menü űrlap funkciója a DREAM alkalmazásban való eligazódást segítése. A menü
űrlap a rendszerbe történő bejelentkezést követően az alkalmazásból való kilépésig
végig nyitva van.
Gomb(ok):
buttonProductSelector
Termék adatbázis rész - Termékválasztó űrlap megnyitása
11
buttonCaseSelector
Ügymenetkövető rész - Ügymenetválasztó űrlap megnyitása
buttonRegistry
Iktatókönyv megnyitása
buttonQuit
Kilépés az adatbázisból
TERMÉK ADATBÁZIS
A nyilvántartott gyógyszerek alapvető adatainak karbantartására, illetve visszakeresésére
szolgáló programrész.
Termékválasztó űrlap - frmProductSelector
A termékválasztó űrlap segítségével választható ki, hogy melyik gyógyszer adatait
akarjuk megtekinteni vagy szerkeszteni, illetve innen van lehetőség új gyógyszer
felvételére is.
Gomb(ok):
buttonProductAdd
Új termék felvétele – az frmProductCard termék adatlap megnyitása hozzáadás (add)
módban.
buttonProductEdit
Termék adatlap megnyitása – a lstProduct kombinált lista vezérlőelemben kiválasztott
gyógyszer megnyitása szerkesztésre
12
Termék adatlap – frmProductCard
A termék adatlap a rendszerben nyilvántartott készítmények alapvető adatait tartalmazó
űrlap. Azok az adatok, melyek esetében egy termékhez több adat is tartozhat,
segédűrlapok segítségével kerülnek megjelenítésre. Ilyen pl. a kiszerelés vagy a
hatóanyag, hiszen egy gyógszernek több féle hatóanyaga is lehet és több kiszerelésben is
forgalmazhatják.
Gomb(ok):
buttonPacksize
Kiszerelés segédűrlap megynyitása
buttonIngredient
Hatóanyagok segédűrlap megnyitása
buttonManufacture
Gyártók segédűrlap megnyitása
buttonAnnex
Csatolt mellékletek segédűrlap megnyitása
Termék adatlap - segédűrlapok
frmProductPacksize - frmProductPacksizeSub
Termék kiszerelésével kapcsolatos adatok megjelenítésére szolgáló űrlap.
frmProductIngredient - frmProductIngredientSub
Termék hatóanyagaival kapcsolatos adatok megjelenítésére szolgáló űrlap.
frmProductManufacture - frmProductManufactureSub
Termék gyártóival kapcsolatos adatok megjelenítésére szolgáló űrlap.
13
frmProductAnnex - frmProductAnnexSub
Termékhez tartozó mellékletek feltöltésére szolgáló űrlap.
Az frmProductAnnex űrlap részletes leírása megtalálható a dolgozat ALKALMAZOTT
MEGOLDÁSOK RÉSZLETES LEÍRÁSA című részében.
ÜGYMENETKÖVETŐ
Ügymenetkövető modul leírása
Xxx
Ügymenet választó űrlap – frmCaseSelector
Az ügymenetválasztó űrlap segítségével választható ki, hogy melyik ügymenetet akarjuk
megtekinteni vagy szerkeszteni, illetve innen van lehetőség új gyógyszer felvételére is.
Gomb(ok):
buttonCaseAdd
Új ügymenet felvétele – az frmCaseManager ügymenet adatlap megnyitása hozzáadás
(add) módban.
buttonCaseEdit
Az ügymenet adatlap megnyitása – a lstCase kombinált lista vezérlőelemben kiválasztott
ügymenet megnyitása szerkesztésre
Ügymenet adatlap - frmCaseManager
Ügymenet adatlap leírása
14
IKTATÓKÖNYV – REGISTRY
A törzskönyvezési ügymenetek kezelése során rengeteg levél, e-mail, fax keletkezik. A
szoros határidők betartásához elengedhetetlen, hogy elküldött / beérkezett üzeneteinket
könnyen megtaláljuk. Ezért volt szükség a DREAM rendszerben egy elektronikus
iktatókönyv kialakítására. Az iktatókönyv modulban üzeneteink elektronikus formában
kerülnek eltárolásra és lehetőség van az érintett termék, illetve érintett ügymenet(ek)
megjelölésére is. Így lehetővé válik az ügymenetekezelő felületen keresztül az adott
ügymenethez kapcsolodó levelek visszakeresésére is.
Iktatott levél választó űrlap - frmRegistryLetterSelector
Az iktatott levél választó űrlap segítségével választható ki, hogy melyik gyógyszer
adatait akarjuk megtekinteni vagy szerkeszteni, illetve innen van lehetőség új gyógyszer
felvételére is.
Gomb(ok):
buttonRegistryAdd
Új levél felvétele – az frmRegistryAdd űrlap megnyitása hozzáadás (add) módban.
buttonViewLetter
Levél adatlap megnyitása – a lstRegitry kombinált lista vezérlőelemben kiválasztott
levél megnyitása szerkesztésre
Iktatókönyv adatlap – frmRegistry Add
Az iktatott levél adatlap a rögzítésre kerülő levelek adatait tartalmazó űrlap.
Gomb(ok):
15
buttonClose
Kiszerelés segédűrlap megynyitása
buttonCloseWindow
Hatóanyagok segédűrlap megnyitása
16
ALKALMAZOTT MEGOLDÁSOK RÉSZLETES LEÍRÁSA
Az alábbiakban részletesen bemutatásra kerülő megoldásokat azért emeltem ki, mert
itt jól látható,hogy az alkalmazás nem csupán a Microsoft Accessben elérhető varázslók
használátával készült, hanem egyedi Visual Basic kódokat is alkalmaztam.
Az alkalmazásokban található Visual Basic kódok elsősorban az űrlapok, illetve a
hozzájuk tartozó gombok eseményein keresztül kerülnek meghívásra.
1. Belépés a rendszerbe
2. Dokumentum archiválás a DREAM redszerrel
3. Ügymenetek határidejének követése
1. Belépés a rendszerbe
A Microsoft Access Eszközök menü Indítás pontjában került beállításra, hogy az
elkészített alkalmazás az „frmLogin” beléptetésre szolgáló űrlappal induljon.
Az alábbi ábrán látható az „frmLogin” űrlap nézetben:
17
A „Username:” címkével ellátott beviteli mező neve txtUID. Ebbe a mezőbe kell beírni a
felhasználónevet.
A „Passwd” címkével ellátott beviteli mező neve txtPWD. Ide kell beírnia a
felhasználónévhez tartozó jelszót. A felhasználó biztonsága érdekében a txtPWD
beviteli mező beviteli maszkját a tulajdonságok lapon, az „Adat” lapon található Bevitel
maszk pont alatt „Jelszó”-ra állítottuk, hogy a bevitt karakterek helyén „*” karakterek
látszódjanak, ahogy ez a fenti ábrán, az „frmLogin” űrlap nézeténél is látható.
Beviteli maszk beállítása
A bevitt felhasználónév és jelszó ellenőrzése:
Az „frmLogin” űrlap tervező nézetén látható, hogy a txtUID (Username) beviteli mező
felett egy rejtett listaelem található, melynek neve lstPwd.
Ez a listaelem szolgál a bevitt felhasználónév és a hozzátartozó jelszó ellenőrzésére.
18
Az alkalmazáshoz tartozó adatbázis sysUser nevű táblájában kerülnek tárolásra a
felhasználó adminsztrációhoz szükséges adatok.
A lstPwd listaelem sorforrása:
SELECT sysUser.passwd_str, sysUser.login_str
FROM sysUser
WHERE (((sysUser.login_str)=Forms!frmLogin.txtUID));
Az ellenőrzés módszere tehát azon alapszik, hogy a sysUser táblában tárolt jelszavak
közül annak értékét veszi fel a lstPwd, melyre igaz, hogy a txtUID beviteli mezőbe beírt
felhasználónév megtalálható a sysUser tábla login_strben tárolt belépési nevei között.
Az ellenőrzési folyamat a BELÉPÉS gomb (buttonLogin) lenyomása után történik meg.
A buttonLogin-hez tartozó VisualBasic kód az alábbi lépéseket végzi el:
Private Sub buttonLogin_Click()
Me.Recalc
If Len(Me.txtPWD) > 0 And Me.lstPWD.ItemData(0) =
Me.txtPWD Then
DoCmd.OpenForm "frmMenu"
Let Forms![frmMenu].txtLogin = Me.txtUID
Forms![frmMenu].Recalc
DoCmd.Close acForm, "frmLogin"
19
Else
MsgBox "Login failed. Incorrect username or
password"
End If
End Sub
Me.Recalc utasítás újraszámolja az frmLogin űrlapon az ott található listaelemhez
tartozó értékeket. Itt kerül tehát tulajdonképpen kitöltésre a lstPwd, a sorforrássul
megadott SQL utasítás alapján.
Ezt követi a jelszó tényleges ellenőrzése.
A kód először ellenőrzi, hogy kitöltésre került-e a jelszó bevitelre szolgáló „txtPWD”
vagyis hogy a bevitt szöveg hossza a „Len” függvénnyel ekiszámítva nagyobb-e mint 0.
Len(Me.txtPWD) > 0
A „Me.” az aktuális űrlap (amelyhez a Visual Basic kód tartozik) elemeire való
hivatkozást jelenti.
Az alkalmazás tehát nem engedi meg azt, hogy egy rendszerbe felvett felhasználó esetén
a jelszó üresen maradjon.
Ezt követi a bevitt jelszó tényleges ellenőrzése, vagyis a rendszer megnézi, hogy a
sysUser táblából a „lstPwd” mezőbe átvitt jelszó megegyezik a „txtPWD” mezőbe beírt
jelszóval.
Me.lstPWD.ItemData(0) = Me.txtPWD
Ha tehát a bevitt felhasználónév és jelszó megfelelő, akkor megnyitásra kerül az
alkalmazás főmenüje (frmMenu).
20
DoCmd.OpenForm "frmMenu"
Ha a bevitt felhasználónév és jelszó nem megfelelő, akkor az ellenőrzés hamisságán
továbbhaladva az alábbi hibaüzenetet kapjuk a rendszertől:
Else
MsgBox "Login failed! Incorrect username or
password."
A hibaüzenet szövegének beállítása a kód MsgBox utasításának paraméterezésével
történt meg.
A rendszer biztonságát növeli, hogy a belépéshez a felhasználónév pontos ismerete is
szükséges, nem listából kerül kiválasztásra a felhasználónév, hanem beviteli mezőbe kell
begépelni.
Ha a felhasználó rossz felhasználó nevet ad meg, akkor a rendszer eleve nem talál
hozzátartozó jelszót, így üresen marad a lstPwd, tehát az else ágra kerülve hibaüzenetet
kapunk.
Az alkalmazás főmenüjén megjelenik a belépett felhasználó neve.
21
Ezt a rendszer a következőképpen éri el.
Az frmLogin beléptető űrlap buttonLogin gombjának lenyomásakor kitöltödik a
„txtLogin” rejtett beviteli mező értéke az frmMenu űrlapon.
Let Forms![frmMenu].txtLogin = Me.txtUID
Az frmMenu txtLogin mezőjének értéke az frmLogin txtUID mezőjével lesz egyenlő.
22
A Belépett felhasználó neve a lstUser listában tárolódik.
Ennek sorforrása az alábbi:
SELECT sysUser.name_str, sysUser.login_str
FROM sysUser
WHERE (((sysUser.login_str)=Forms!frmMenu!txtLogin));
A lstUID rejtett listaelem, amely a belépett felhasználóhoz tartozó user_id-t veszi át a
sysUser táblából.
SELECT sysUser.user_id, sysUser.login_str
FROM sysUser
WHERE (((sysUser.login_str)=Forms!frmMenu!txtLogin));
Ennek a rejtett listaelemnek a jelentősége az, hogy alapvető log információk készítésére
használható. Az alkalmazás működése közben az frmMenu űrlap végig nyitva marad a
belépést követően. Ezt a listaelemet tulajdonképpen változószerűen használjuk, egyes
23
táblákban ennek értékével töltjük fel azt a mező automatikusan, mely az adatot rögzítő
felhasználóhoz tartozó user_id-t rögzíti.
A lstUser és lstUID mezők értékének kiszámítására szintén az frmLogin buttonLogin
gombjához tartozó kódban kerül sor. Fontos, hogy ez a lépés az frmMenu txtLogin
beviteli mezőjének automatikus kitöltése után történjen, hiszen a két listaelem ennek
alapján lesz számítható.
Forms![frmMenu].Recalc
2. Dokumentum archiválás a DREAM rendszerrel
A gyógyszerek engedélyezési folyamataiban rengeteg különböző levél, beadvány,
hivatalos határozat születik. Fontos a felhasználó számára, hogy ezeket a
dokumentumokat megfelelően tudja rendszerezni, archiválni. A rendszernek biztosítania
kell, hogy a felhasználó mindig megtalálja az adott készítményre vonatkozó aktuális
határozatot, de fontos az is, hogy a korábban elfogadott alkalmazási előírás verziók se
vesszenek el.
A DREAM rendszerben egy egyszerű „dokumentumkezelő” megoldást alkalmaztam.
A dokumentum fájlok archiválására kijelölünk egy könyvtárat, célszerű egy olyan
fájlszerveren lévő könyvtárat kijelölni, amelyről napi mentés készül. Olyan könyvtárat
válasszunk, melyet a felhasználók nem használnak más célra.
Célszerű a felhasználók közül kijelölni egy vagy két főt, akik a dokumentumok
archiválásával foglalkoznak. Ez a törzskönyvező csoportok esetében általában egy
adminisztrátor szokott lenni. A dokumentum archiválással megbízott felhasználó(k)
számára írási és olvasási (RW) jogot kell biztosítani a kiválasztott könyvtárra.
A többi felhasználó, akik csak keresnek az archivált dokumentumok között, csak
olvasási (RO) jogot kap a könyvtárra.
A dokumentum archiválással kapcsolatban célszerű egy SOP (Szabványműveleti
eljárás) készítése, melyben rögzítjük az alábbiakat:
24
• A dokumentum archiválásra kijelölt könyvtárat a felhasználók csak a DREAM
által biztosított felhasználói felületen keresztül használják.
• Ha egy dokumentumból új verzió készül, ne javítsuk a már feltöltött, archivált
dokumentumot, hanem töltsük fel az új verziót. Ha a felhasználónak javítania,
változtatnia kell, a szerkesztés megkezdése előtt, használjuk a Mentés másként
funkciót szövegszerkesztőnkben, majd az új változatot a fentiek szerint töltsük
fel újra a DREAM rendszerbe.
Az archivált dokumentumokkal kapcsolatos információk tárolása
Az archivált dokumentumokkal kapcsolatos információkat az adatbázis subAnnex nevű
táblájában tároljuk:
Mezőnév Adattípus Leírás
annex_id (PK) integer A coreAnnex tábla elsődleges kulcsa, ez alapján történik
meg a feltöltött dokumentum elnevezése.
tannex_id integer A feltöltött dokumentum típusának besorolása, pl.
alkalmazási előírás, forgalomba hozatali engedély
Forrás: dicAnnexType
annex_dt date A dokumentum keletkezésének dátuma, a felhasználó
tölti ki, nem a feltöltés dátuma
product_id integer Ez a mező határozza meg, hogy melyik adatbázisban
tárolt készítményre vonatkozik a feltöltött dokumentum.
Forrás: coreProduct
tdoc_id char (3) A feltöltött dokumentum formátumának meghatározása.
Forrás: dicDocType
annex_str varchar
(50)
A dokumentum szöveges jellemzője: pl. iktatási szám
vagy engedélyszám. A felhasználó tölti ki.
Az archivált dokumentumok elnevezése
25
Az archivált dokumentumokat a coreAnnex tábla annex_id és annextype_fk mezői
alapján nevezzük el: pl. ha az 568. feltöltött fájl egy Microsoft Word dokumentum,
akkor a feltöltésre kerülő fájl neve: 568.doc lesz.
A dokumentum feltöltés menete
Űrlap, ábra
A dokumentum feltöltésre szolgáló ablakban a felhasználónak ki kell töltenie az
alábbiakat:
• Melyik termékhez kapcsolódik a feltöltendő dokumentum
• Milyen típusú a dokumentum? – pl. betegtájékoztató
• Mi a határozat száma vagy iktatási száma a dokumentumnak?
• Mikor keletkezett a dokumentum?
Az űrlap alján található a dokumentum kitallózására szolgáló gomb: buttonUpload.
Ennek a gombnak a megnyomása az alábbi kódot indítja el:
Private Sub buttonUpload_Click()
On Error GoTo Err_buttonUpload_Click
Dim regi_nev As String
Dim kiterjesztes As String
Dim uj_nev As String
Dim uj_ut As String
Dim intAnnexId As Integer
Dim strAnnexId As String
DoCmd.RunCommand acCmdSaveRecord
intAnnexId = [annex_id]
26
strAnnexId = CStr(intAnnexId)
CommonDialogUpload.Action = 1
regi_nev = CommonDialogUpload.FileName
kiterjesztes = Right(regi_nev, 3)
uj_nev = strAnnexId + "." + kiterjesztes
uj_ut = "C:\filepool\annex\" + uj_nev
FileCopy regi_nev, uj_ut
doctype_fk.Value = kiterjesztes
DoCmd.Close acForm, "frmAnnexUpload"
Exit_ buttonUpload _Click:
Exit Sub
Err_ buttonUpload _Click:
MsgBox Err.Description
Resume Exit_ buttonUpload _Click
End Sub
A kód első részében a használt változók meghatározása történik. Majd elmentjük az
űrlapba írt adatokat. Erre azért van szükségünk, mert a dokumentum elnevezéséhez
szükségünk van az annex_id értékére, amely egy auto increment tulajdonságú mező és
az Access csak a rekord elmentésékor határozza meg értékét.
Ezt követően átvesszük az űrlapról a kódba az annex_id értékét.
intAnnexId = [annex_id]
27
Az annex_id az adatbázisban egy numerikus érték, de a fájl átnevezési műveletben
nekünk szöveges értékként kell használnunk, ezért szükséges átalakítani string
adattípussá a CStr utasítással:
strAnnexId = CStr(intAnnexId)
A fájl műveletek elvégzéséhez egy CommonDialog vezérlőt kell használnunk. Ez a
vezérlő néhány szabványos Windows párbeszédablak használatát teszi lehetővé. Ezen
funkciók használatához az űrlapunkon szükséges elhelyezni a CommonDialog vezérlőt:
A CommonDialog vezérlő segítségével olyan Windowsos alkalmazásokban gyakori
párbeszédablakokat használhatunk, mint az Open, a Print vagy a Save as. Ezek közül mi
a fájlok kitallózására szolgáló párbeszédablakot használjuk alkalmazásunkban.
Az űrlapra beillesztett CommonDialog vezérlőnek az alábbi tulajdonságokat állítjuk be:
• Az ActiveX vezérlőelemet CommonDialogUpload-nak neveztem el, így lehet
hivatkozni rá a kódban.
28
• A FileName megadásával, azt határozzuk meg, hogy milyen fájlok jelenjenek
meg a tallózó ablakban. Pl. ha ide a 1.*-ot írjuk be, akkor csak az 1 nevű,
különböző kiterjesztésű fájlok jelennek meg, mint pl. 1.txt, 1.doc, stb
• A DialogTitle tulajdonságánál adható meg, hogy a megjelenő párbeszédablaknak
mi legyen a címe.
• A Filter tulajdonságnál a fájlok típusára három lehetséges szűrőt állítottunk be:
*.* vagyis minden fájl megjelenítése, illetve csak doc vagy csak rtf formátumú
fájlok megjelenítése a fájllistában
• Az InitDir tulajdonsággal határozhatjuk meg azt a könyvtárat, ahonnan
alapértelmezett módon kezdheti a tallózást a felhasználó. Ide célszerű pl. azt a
közös hálózati meghajtót beállítani, ahol a DRA csoport munkatársai tárolják
állományaikat vagy esetleg azt a mappát ahová scannelt dokumentumaink
automatikusan bekerülnek.
A CommonDialogUpload Active X vezérlő Action tulajdonságát 1 értékre állítva
elindul a Fájl kiválasztása párbeszédablak. A kiválasztott fájl neve a a vezérlő FileName
tulajdonságába kerül bele.
regi_nev = CommonDialogUpload.FileName
kiterjesztes = Right(regi_nev, 3)
Ennek a kitallózott fájl nevének értékét átadjuk a regi_nev változónak.
A fájl kiterjesztésének meghatározása a régi névből az utolsó 3 karakter Right
függvénnyel történő kiválasztásával történik meg.
uj_nev = strAnnexId + "." + kiterjesztes
uj_ut = "C:\filepool\annex\" + uj_nev
Az új név meghatározása a soron következő annex_id és a kiterjesztés karakterláncba
fűzésével történik meg.
29
A fájl feltöltése a FileCopy utasítással történik meg. A fájl új elhelyezési neve, tehát az
archiválásra kiválasztott az uj_ut változó megadásánál kerül bele a kódba. A bemutatott
kódrészletben a C: meghajtó filepool nevű könyvtárának annex alkönyvtárát használtam
archiválásra.
FileCopy regi_nev, uj_ut
doctype_fk.Value = kiterjesztes
A feltöltött fájl kiterjesztésének értékét végül átadjuk az adatbázisnak. Ennek az a
jelentősége, hogy a fájlok visszakeresése adatbázisból történik meg.
A feltöltött dokumentumok visszakeresése
A visszakeresésre szolgáló űrlapon a fájl helyét hyperlinkként építjük fel egy Access
lekérdezésből véve az adatokat. A lekérdezésben a fájl helyének megadása a
következőképpen történik:
"#c:\filepool\annex\" & [coreAnnex]![annex_id] & "." &
[coreAnnex]![doctype_fk] & “#”
Az így összerakott elérési útvonalat a visszakeresésre szolgáló űrlapon jelenítem meg,
ahol a hiperhivatkozás tulajdonságot igen értékre állítom. Így a felhasználó a linkr
kattintva azonnal meg tudja nyitni a keresett dokumentumot.
Ha egy dokumentumtípusból, egy termékhez több is feltöltésre kerül, pl. az alkalmazási
előírásnak az idők folyamán három változata készült el, akkor az élő (érvényes)
listákban az adott termékhez, adott dokumentumtípusból a legkésőbbi dátummal (Max
függvénnyel szűrve) rendelkezőt választom ki.
3. Ügymenetek határidejének követése
30
A DREAM rendszerben nyilvántartott ügymenetek határidejének követéséhez a
következő adatbázistáblákat használjuk:
coreCase
coreClockstop
dicCaseType
A dicCaseType tartalmazza az egyes ügymenettípusok nevét és a hozzájuk tartozó
ügyintézés hosszát:
Mezőnév Adattípus Leírás
casetype_id Integer, AutoIncr, PK Tábla azonosító
casetype_short_str Varchar (255) Ügymenet típusa
duration_num Integer Az ügymenet intézésének ideje napokban
Az ügymenet kezdetét a coreCase tábla start_dt mezője tartalmazza.
Az ügymenethez kapcsolodó óraleállítások idejét az alábbiak szerint számíthatjuk ki:
Egy óraleállítás időtartama: (clockrestart_dt – clockstop_dt).
Ezt egy lekérdezésben minden óraleállítási sorra meghatározhatjuk.
Az össz óraleállítás időtartama: az ügymenethez tartozó összes óraleállítás szummája:
sum(clockrestart_dtügy-clockstop_stügy). Ezt az előbbi egy-egy óraleállítás időtartamát
meghatározó lekérdezés case_fk szerint csoportosított (group by) lekérdezés
segítségével tehetjük meg.
A végső határidő tehát a következőképpen számítható ki:
Deadline_dt = Start_dt + Duration_num + sum(clockrestart_dtügy-clockstop_stügy)
31
ÜZEMELTETÉSI DOKUMENTÁCIÓ
Az üzemeltetési dokumentáció a feladatok időbeli végrehajtásának gyakoriságától
függően három alapvető csoportba összefoglalva ismerteti a problémák leírását. A
rendszer üzembehelyezésekor, ill a naponta és havonta végrehajtandó feladatcsoportokat
képez.
A rendszer első üzembehelyezéséhez szükséges lépések
A rendszert működtető szerver beállításai
A DREAM rendszer v.1.0 Microsoft Accesre épül. Működtetéséhez szerveroldalon egy
tetszőleges fájlszerver szükséges (pl. Windows 2000, 2003 Server Active directoryval,
Novell, tetszőleges Linux disztribució Samba eléréssel).
A kiválasztott fájlszerveren a database könyvtár tartalmazza az adatbázis felhasználói
felületét (dream_user.mdb) és a hozzátartozó adat fájlt (dream_data.mdb).
A database könyvtár mellett szükséges egy további olyan könyvtár létrehozása, melyben
a rendszerhez csatolt állományok rendezetten tárolhatóak. A megbízóval külön
egyeztetés után, mellékletben kerül rögzítésre a csatolt állományok elhelyezésének
könyvtárrendszere.
Javaslat a könyvtárrendszerre
A DREAM rendszerhez csatolt állományok elhelyezésére az alábbi könyvtár rendszert
és fájl elnevezési SOP kidolgozását javaslom:
32
FILEPOOL nevű könyvtár, ezen belül a három dokumentum csatoló résznek
megfelelően:
ANNEX alkönyvtár
Ehhez a könyvtárhoz minden adatbázis felhasználónak olvasási jogot adunk és mindenki
kap rá írási jogot, aki jogosult bármilyen típusú csatolt ANNEX fájl kezelésére,
archiválására. (Pl. alkalmazási előírás, betegtájékoztató, forgalomba hozatali engedély,
stb.)
LETTER alkönyvtár
Ehhez a könyvtárhoz minden adatbázis felhasználónak olvasási jogot adunk és mindenki
kap rá írási jogot, aki jogosult a DREAM rendszerhez tartozó IKTATÓKÖNYV modul
kezelésére, ill. azon belül a levelek archiválására.
TASK alkönyvtár
Ehhez a könyvtárhoz minden adatbázis felhasználónak olvasási jogot adunk és mindenki
kap rá írási jogot, aki jogosult a DREAM rendszer ÜGYMENETKÖVETŐ modul
kezelésére, ill. azon belül az ügymenetek eseményeihez dokumentumok archiválására.
Az egyes dokumentumtípusokhoz tartozó könyvtárakhoz célszerű külön külön
felhasználót felelősként megjelölni, csak ezek az egyes felhasználók kapnak írási jogot.
A DREAM rendszer nem igényli külön fájl szerver működtetését. A database, és a
filepool könyvtárak helyét a már működő, rendelkezésre álló fájlszerveren a megbízó
rendszergazdáival együtt határozzuk meg. A database mappára az Accessre épülő verzió
esetében célszerű az összes adatbázisfelhasználónak írási/olvasási jogot kell biztosítani a
biztonságos üzemeltetés érdekében.
33
Kliens igény
A DREAM v.1.1 Microsoft Access XP telepítését igényli a kliens számítógépen, ehhez
operációs rendszerként Windows 2000/XP Profesional alkalmazását javasoljuk.
Hardver igény: a kliens hardver alkalmas legyen Windows 2000/XP operációs rendszer
futtatására. (Ajánlott minimum kliens konfiguráció: Pentium III, 256 MB RAM, 10 GB
winchester).
Napi feladatok
A fájlszerver database, és filepool könyvtárairól napi mentés készítendő. A napi
mentések készülhetnek szalagos egységre vagy újraírható CD-re illetve DVD-re. Az
adatbázisról készített napi mentéseket a mentés elkészítése után egy hétig megőrzendő.
Havi feladatok
A fájlszerver database és filepool könyvtáráról havonta, hónap végén egy aktuális
mentés készítendő, melyet archíválni kell.
34
BŐVÍTHETŐSÉG, TOVÁBBFEJLESZTHETŐSÉG
Alkalmazásunkban az adattáblákat egy második MS-Access fájlban
(dream_data.mdb) helyeztük el, és a kliens alkalmazásként használt dream_user.mdb
fájlban csak csatolt táblaként szerepelnek. Ennek előnye, hogy adataink így nagyobb
biztonságban vannak, ha véletlenül megsérül az alkalmazás, az adatainkat ez általában
így nem érinti.
Ha adatbázismotorként a fentebb említett SQL alapú szerverek valamelyikét
választjuk a jelenlegi alkalmazáson az alábbi változatatásokat kell végrehajtani:
• a kiválasztott szerveren létre kell hozni a tábláinkat. Ez MS-SQL esetében
kényelmesen elvégezhető, MS-Access projekt segítségével közvetlenül is
csatlakozhatunk MS-SQL szerverhez, így akár egyszerűen be is importálhatjuk
MS-Access adattábláinkat az MS-SQL szerverre, a meglévő adatokkal együtt is.
Fontos azonban, ha ezt a módszert választjuk, szükséges a táblák elsődleges
kulcsainak újbóli létrehozására, mert ezek elvesznek az importálás során.
• az SQL szerveren létrehozott táblákat a dream_user alkalmazásba ODBC
kapcsolat beállításával kapcsolhatjuk be. Az ODBC kapcsolat beállítását a
függelékben ismertetjük.
A becsatolt táblákat legegyszerűbb átnevezni a megfelelő Access tábláink nevének
megfelelően, és ezáltal máris műkődőképessé tettük alkalmazásunkat valódi szerver –
kliens környezetben.
A felhasználók autentikálásánál MS-SQL szerver esetében két módszer közül
választhatunk:
1. SQL Server Authentication - ebben az esetben külön felhasználókat kell
létrehoznunk az MS-SQL szerveren, az így léterhozott felhasználóknak
csoportosan is adhatunk meg jogokat, ha Role-kat hozunk létre. Előnye, hogy
35
nőveli a biztonságot, mivel a rendszerbe belépéskor mielőtt bármely táblát
elérnénk a felhasználónak meg kell adnia felhasználó nevét és jelszavát.
2. Windows Authentication – ebben az esetben a Windowsba való belépéshez
használt nevet és jelszót használjuk az alkalmazásunk autentikálásához. Ez a
felhasználó szempontjából kényelmesebb lehet, hiszen kevesebbszer kell
jelszavát begépelnie. Ebben az esetben azonban, ha a felhasználó nincs a gépénél
és az nincs zárolva, akkor könyebben férhetnek illetéktelenek a rendszer
adattábláihoz.
36
FOGALOMTÁR
Forgalomba hozatali engedélyezés (korábbi nevén: Törzskönyvezés)
A gyógyszer engedélyezési folyamata. Magyarországon az Országos Gyógyszerészeti
Intézet (továbbiakban OGYI) végzi a gyógyszerek engedélyezését. Ez alapján a
gyógyszereknek hat különböző státuszát különíthetjük el:
E – Törzskönyvezés előtti – A cég tervezi a készítmény benyújtását
törzskönyvezésre
A – Törzskönyvezés alatti – A cég beadta a törzskönyvezés iránti kérelmet az
OGYI-nak és az eljárás folyamatban van.
EL – Elutasított – Az OGYI a törzskönyvezés befejezése előtt elutasította a
törzskönyvezés iránti kérelmet.
V – Visszavont – a cég a törzskönyvezés befejezése előtt visszavonja a
törzskönyvezés iránti kérelmet.
TK - Törzskönyvezett gyógyszer
TT - Törzskönyvből törölt – A korábban az OGYI által törzskönyvezett
gyógyszert a cég kérésére vagy más okból (pl. súlyos mellékhatás
előfordulása, komoly minőségi kifogás, stb.) törlik a törzskönyvből. A
törölt készítmények a törlési határozat dátumától számítva a lejárati
időnek megfelelő ideig még forgalomban lehet, ezért a törölt
készítmények adatai nem törölhetők automatikusan. Azokat célszerű
továbbra is megőrizni, legalább a lejárati idő végéig.
37
A további fogalmakat ABC sorrendbe rendezve tüntettük fel:
Alaki hiba
Az engedélyezett címkeszövegtől eltérő csomagolásban a gyógyszer forgalmazását az
OGYI határozott időre engedélyezheti Alaki hibás engedély kiadásával. Az alaki hibás
csomagolás külső része lehet nem magyar nyelvű, de a dobozban vagy a készítményhez
csatoltan mindig szerepelnie kell a magyar nyelvű betegtájékoztatónak.
Alkalmazási előírás
Az orvos, illetve a gyógyszerész részére szóló, a forgalomba hozatali engedélyben
szereplő szakmai előírás, amely a gyógyszer legfontosabb adatait, az alkalmazás
feltételeit és az esetleges mellékhatásait tartalmazza.
ATC-kód
A gyógyszer hatástani kódja. Besorolását az Egészségügyi Világszervezet (WHO –
World Halth Oganization) végzi és folyamatosan karbantartja. Például a gyógyszer
vérnyomáscsökkentő, szív- és érrendszeri betegségek gyógyítására alkalmas.
Gyógyszerészek által használt kód, a gyógyszerek csoportosítását segíti elő hatástanuk
alapján.
Betegtájékoztató
A felhasználónak (betegnek) szóló, a forgalomba hozatali engedélyben szereplő
közérthető tájékoztatás, amely a gyógyszer legfontosabb adatait, az alkalmazás feltételeit
és az esetleges mellékhatásait tartalmazza
Címkeszöveg
A forgalomba hozatali engedély melléklete (Annex 5.). A címkeszövegben rögzíteni
kell a gyógyszer közvetlen és külső csomagolásán feltüntetett adatokat. Törvényi
szabályozás szerint a gyógyszer csomagolásán magyar nyelven, közérthetően fel kell
tüntetni:
38
a) a gyógyszer nevét,
b) a forgalomba hozatali engedély jogosultjának nevét és székhelyét,
c) a gyógyszer törzskönyvi számát,
d) gyártási tétel számát,
e) a gyártás időpontját,
f) a hatóanyagok nevét és adagolási egységenkénti mennyiségét,
g) az alkalmazás módját,
h) a gyógyszer eltarthatósági idejét,
i) a szükséges tárolási intézkedések megjelölését,
j) a gyógyszerre vonatkozó alkalmazási utasításokat,
k) "A gyógyszer gyermekektől elzárva tartandó" szövegű külön figyelmeztetést,
l) a gyógyszerrel kapcsolatos további információk elérhetőségéről szóló
tájékoztatást.
Csomagolás
A csomagolás leírását az OGYI az alkalmazási előírásban és a forgalomba hozatali
engedélyen rögzíti.
Közvetlen csomagolás: az a csomagolási forma, amely közvetlen kapcsolatban van a
gyógyszerrel;
Külső csomagolás: azt a csomagolási formát jelenti, amely a közvetlen csomagolást
foglalja magában;
EAN kód
Nemzetközileg meghatározott kód, mely az egyes gyógyszerek kiszereléseihez
rendelhető és fő célja a gyógyszer azonosítása a gyógyszer forgalmazásának, illetve
forgalmi adatainak követése során.
Felújítás
A gyógyszer forgalomba hozatali engedélyében és mellékleteiben rögzített adatok az
engedélyezést követő 5 évenként kötelezően végrehajtandó újraértékelése az OGYI által.
39
Ha egy készítmény az újraértékelés során támasztott követelményeknek nem felel meg,
törölhető a törzskönyvből.
Forgalomba hozatali engedély (FHE)
Az OGYI, mint illetékes hatóság által kiadott, a gyógyszer embergyógyászati célra
történő alkalmazhatóságát engedélyező és a törzskönyvi bejegyzést igazoló hatósági
határozat. A FHE egy fő példányból és 7 mellékletből áll.
Forgalomba hozatali engedély jogosultja
Az a gazdálkodó szervezet, amely rendelkezik az OGYI által kiadott forgalomba
hozatali engedéllyel, mint a gyógyszer forgalmazására jogosító hatósági engedéllyel.
Jogosult az Országos Egészségügyi Pénztárral (továbbiakban OEP) a gyógyszer
támogatási tárgyalások megkezdésére.
Gyártó
A gyártó az a gazdálkodó szervezet, amely rendelkezik a gyógyszer gyártására jogosító
hatósági engedéllyel.
Hatáserősség
A gyógyszerek hatáserősség szerinti besorolása elsősorban a gyógyszer hatóanyagának
tulajdonságai alapján (pl. farmakológiai hatások, hozzászokás veszélye, mellékhatások
mértéke, visszaélés lehetősége) történik az OGYI által.
Kiadhatóság
Az egyes gyógyszerek kiszerelései külön-külön kiadhatósági csoportba kerülnek
besorolásra az OGYI által (korábban ezt az Egészségügyi Minisztérium végezte el). A
kiadhatósági besorolás alapját elsősorban a gyógyszer hatóanyaga, hatáserőssége illetve
a kiszerelés nagysága határozza meg. A kiadhatósági besorolás alapján lehet pl. vény
nélküli illetve csak ovosi rendelvényre kiadható.
Kiszerelés
40
Az engedélyezett gyógyszer csomagolási egységei.
Módosítás (Törzskönyvi módosítás)
A forgalomba hozatali engedély tulajdonosa köteles az engedélyezett gyógyszer
adatainak változásait (pl. gyártóhely változás, új kiszereés megjelenése vagy már
engedélyezett kiszerelés megszűntetése, összetétel változása) folyamatosan, naprakészen
jelenteni. A törzskönyvi okmányban történő ezen változásokat az OGYI a Forgalomba
hozatali engedély módosításában hagyja jóvá és tartja nyilván.
Törzskönyvi szám
Az Országos Gyógyszerészeti Intézet által a törzskönyvezett gyógyszerekhez adott
nyilvántartási szám. Gyógyszerenként egyedi. Jelenlegi formája: OGYI-T-00000/01. A
per „/” után szereplő rész a gyógyszer egyes kiszereléseinek elkülönítésére szolgál.
TTT-kód
Az OEP által meghatározott kód, mely az egyes gyógyszerek kiszereléseihez rendelhető
és célja a gyógyszer azonosítása a gyógyszer forgalmi adatainak követése során.
41
BIBLIOGRÁFIA
1. Peter G. Aitken: Programozás VISUAL BASIC 6 nyelven (KISKAPU
KIADÓ, Budapest, 1999.)
2. 1997. évi CLIV. Törvény az egészségügyről
3. 2005. évi XCV. Törvény az emberi alkalmazásra kerülő gyógyszerekről
és egyéb, a gyógyszerpiacot szabályozó törvények módosításáról
42
MELLÉKLETEK
CONCEPTUAL DATA MODEL – REPORT
CONCEPTUAL DATA MODEL – PRODUCT DATABASE - DIAGRAM
CONCEPTUAL DATA MODEL – WORK FLOW MANAGEMENT -
DIAGRAM
PHYSICAL DATA MODEL – REPORT
PHYSICAL DATA MODEL – PRODUCT DATABASE - DIAGRAM
PHYSICAL DATA MODEL – WORK FLOW MANAGEMENT - DIAGRAM