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