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
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ó
i
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
ii
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
iii
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
iv
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ázismotorra.
(ld.
adatbázismotorja még
kicserélhető a
dolgozat
Microsoft
SQL
Server
BŐVÍTHETŐSÉG,
TOVÁBBFEJLESZTHETŐSÉG című fejezetét.)
1
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.
2
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.
3
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
4
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.
5
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.
6
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
7
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 8
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.
9
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
10
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
11
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.
12
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
13
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):
14
buttonClose Kiszerelés segédűrlap megynyitása buttonCloseWindow Hatóanyagok segédűrlap megnyitása
15
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:
16
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
felhasználónévhez tartozó jelszót. A felhasználó biztonsága érdekében a
beírnia
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. 17
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" 18
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).
19
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.
20
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ő.
21
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 22
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: 23
•
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
A dokumentum szöveges jellemzője: pl. iktatási szám
(50)
vagy engedélyszám. A felhasználó tölti ki.
Az archivált dokumentumok elnevezése
24
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] 25
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]
26
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.
27
•
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.
28
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
29
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
Az ügymenet intézésének ideje napokban
Integer
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)
30
Ü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:
31
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.
32
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.
33
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
34
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.
35
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.
36
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:
37
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.
38
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
39
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.
40
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
41
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
42
