SPLETNO NARO ČANJE PACIENTOVnivojih zdravstvenega varstva. () 1.3 PREDPOSTAVKE IN OMEJITVE Pri izdelavi spletne aplikacije ePacient, ki je predmet diplomske naloge, smo se soo čali

Diplomsko delo visokošolskega strokovnega študija Informatika v organizaciji in managementu

SPLETNO NAROČANJE PACIENTOV

Mentor: zasl. prof. dr. Vladislav Rajkovič Kandidat: Janez Žumer

Kranj, marec 2011

ZAHVALA Zahvaljujem se mentorju zasl. prof. dr. Vladislav Rajkoviču za vso pomoč in svetovanje pri izdelavi diplomskega dela ter podjetju SRC Infonet d.o.o., ki mi je omogočilo izdelavo diplomske naloge in njen preizkus v praksi. Posebno se zahvaljujem tudi svoji družini, ki me je vsa leta mojega študija podpirala in usmerjala na pravo pot.

POVZETEK Diplomsko delo obravnava izdelavo spletne strani za naročanje pacientov na pregled, preiskave, cepljenje in slikanje. Poleg spletne strani diplomsko delo obravnava tudi izdelavo predloga grafičnega vmesnika za spletno aplikacijo ter povezavo spletne rešitve z zdravstvenim informacijskim sistemom, kjer se bodo informacije prenašale kontrolirano in varno z uporabo naprednih elektronskih poti. Namen diplomske naloge je predstaviti izdelavo spletne strani za naročanje na preglede imenovano ePacient in s tem omogočiti pacientom lažji dostop do izbranega zdravnika in določitev izbranega termina pregleda. S tem bomo približali zdravstvene storitve uporabnikom. Koristi od sistema pa nimajo samo uporabniki zdravstvenih storitev, ampak tudi izvajalci. Preko sistema bodo tako lahko hitreje dostopali do informacij, ki jih bo sistem zagotavljal hitro, precizno, v primernem številu in v realnem času. Na ta način se bodo izboljšale tudi storitve izvajalcev, ki se bodo lahko hitreje in lažje odločali, saj bodo imeli na voljo več pravočasnih informacij. Izbrana metodologija razvoja spletne aplikacije temelji na principu izgradnje prototipnega modela, ki smo ga skozi izdelavo nenehno dopolnjevali in spreminjali. V diplomski nalogi so zajeti vsi potrebni koraki od popisa procesa naročanja na zdravniški pregled in spletnega grafičnega vmesnika aplikacije ePacient (CSS – Cascading Style Sheets) ter analize tveganja. Projektna rešitev omogoča pacientom lažje naročanje na zdravniške preglede ter skrajšuje čakalne dobe. KLJUČNE BESEDE:

• spletne strani, • spletno naročanje, • internet, • ePacient, • zdravniški pregled.

ABSTRACT This diploma thesis deals with constructing a website for scheduling patients' medical appointments, laboratory tests, vaccination and X-rays. Additionally, it also deals with designing a proposal of a graphical interface for the web application and its connection to the medical information system with controlled and safe information transfer using advanced electronic channels. The aim of the diploma thesis is to present the creation of a website for ordering medical appointments called ePatient, which would allow patients to have easier access to their chosen physician and select a date of their medical appointment. This will make medical services more available to the users, but also healthcare workers will benefit from the system. Namely, the system will provide access to required information rapidly, precisely, not redundantly and in real time. Moreover, the system will contribute to healthcare service improvement since healthcare providers will have access to more due information and will be able to make decisions faster and easier. The selected web application development methodology is based on the principle of building a prototype model, which was constantly upgraded during the production. This diploma thesis includes all the necessary steps from records of medical appointment scheduling process and web GUI application ePatient (CSS - Cascading Style Sheets) to risk analysis. The project solution enables patients to easily schedule a medical exam and reduces waiting times. KEYWORDS:

• web pages, • e-appointments, • internet, • ePacient, • medical appointment.

KAZALO 1 UVOD ............................................................................................................... 1

1.1 Predstavitev problema................................................................................ 1 1.2 Predstavitev okolja ..................................................................................... 2 1.3 Predpostavke in omejitve ........................................................................... 3 1.4 Cilji ............................................................................................................. 6

2 METODE DELA ................................................................................................ 6 3 ANALIZA STANJA ............................................................................................ 7 4 PREDLAGANA REŠITEV.................................................................................. 7

4.1 Koncept spletne rešitve .............................................................................. 7 4.2 Proces spletnega naročanja na pregled ................................................... 10

4.2.1 Spletno naročanje na pregled A0 ...................................................... 11 4.2.2 Naročanje na pregled A2 ................................................................... 12 4.2.3 Potrjevanje naročila A3 ..................................................................... 13

4.3 Tehnologija spletne rešitve ....................................................................... 13 4.4 Grafični uporabniški vmesnik.................................................................... 18

4.4.1 Spletno naročanje na pregled A0/A2.1 .............................................. 20 4.4.2 Registracija A1 .................................................................................. 22 4.4.3 Izbiranje storitve A2.2 ........................................................................ 24 4.4.4 Potrjevanje naročila in termina A3.3 .................................................. 29

4.5 Povezava z informacijskim sistemom Birpis21 ......................................... 30 4.5.1 Preverjanje istovetnosti A3.1 ............................................................. 30 4.5.2 Razporejanje termina pacienta A3.2 ................................................. 31

4.6 Varnost .................................................................................................... 31 4.6.1 Identifikacija in avtorizacija uporabnikov ............................................ 34 4.6.2 Varnostna shema .............................................................................. 36 4.6.3 Infrastruktura javnih ključev – PKI ..................................................... 37 4.6.4 Komunikacija odjemalec strežnik z uporabo digitalnih potrdil ............ 39 4.6.5 SSL – Secure Socket Layer .............................................................. 39

5 KRITIČNA ANALIZA ........................................................................................ 41 5.1 Ključni dejavniki uspeha ........................................................................... 41 5.2 Analiza swot ............................................................................................. 42

6 ZAKLJUČKI IN PREDLOGI ZA NADALJNJE DELO ........................................ 43 LITERATURA IN VIRI ............................................................................................ 44

Univerza v Mariboru - Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija

Janez Žumer: Spletno naročanje pacientov stran 1

1 UVOD Tehnološki napredek in razvoj interneta ter elektronskega poslovanja so tako rekoč postali temelji informacijske dobe. Le-ta prinaša velike spremembe v načinu življenja in poslovanja ljudi. Sodobna informacijska komunikacijska tehnologija nam tako daje možnost pridobivanja in izmenjave informacij, ki so povezane z našim zdravjem. Na področju zdravstvene informatike smo priča številnim tehnološkim dosežkom, ki bodo imeli pozitivne učinke na strokovnem, ekonomskem kot tudi administrativnem področju zdravstva kot panoge. Spletna storitev ePacient, ki je predmet diplomske naloge, je le ena izmed možnosti preboja sodobnih tehnologij IKT (informacijsko komunikacijske tehnologije) v sistem zdravstvenega varstva in s tem v množično uporabo. 1.1 PREDSTAVITEV PROBLEMA Predmet diplomske naloge je spletna aplikacija ePacient, ki omogoča pacientom, da na hiter in enostaven način pridejo do informacij o zdravstvenih storitvah in izvajalcih, obenem pa se preko spleta lahko naročijo na pregled, preiskavo, slikanje, cepljenje oziroma zdravstveno storitev pri želenem izvajalcu zdravstvenih storitev. Poleg tega lahko pacient v skladu z uradnimi urami ordinacije izrazi svoje želje glede termina obiska zdravnika. ePacient omogoča naročanje na pregled kadarkoli in kjerkoli – edini pogoj je zagotovljena možnost dostopa do interneta. S tem se izognemo dolgim čakalnim vrstam v ambulantah in stalno zasedenim telefonskim linijam, saj se je možno naročiti samo ob določenih urah oz. časovnih terminih. Trenutno večino naročil na specialistične preglede, preiskave in podobno še vedno sprejemajo preko telefona, sprejemnih okenc ali pošiljanja napotnic po pošti. S tem pridobimo večji pregled nad delovnim časom ambulant, ordinacij, zdravnikov in pregled nad prejeto zdravstveno dokumentacijo. Poleg tega pacientu ne bo več potrebno skrbeti oziroma odgovarjati za hrambo in prenos svoje medicinske dokumentacije, saj se bo le-ta že nahajala pri osebnem zdravniku. Prav tako mu bo omogočen 24 urni vpogled v delne zdravstvene izvide v elektronski obliki. Podatki so na ta način bolj pregledni in verjamemo, da smo z njim proces zdravljenja skrajšali in olajšali tako za pacienta kot zdravnika. Varnost Na področju zdravstva je zagotavljanje najvišje stopnje varnosti in zaupnosti informacij ključnega pomena za zaščito posameznika. V nalogi smo obravnavali tudi vidik spletne aplikacije ePacient v luči identifikacije uporabnikov informacijskih storitev in področje avtorizacije pri uporabi storitev ne ozirajoč se na to, ali storitev uporablja končni uporabnik ali neka druga storitev. Za zmanjševanje tveganja se uporabljajo metode in postopki za zagotavljanje sledljivosti, nadzora ter upravljanja samega sistema.



1.2 PREDSTAVITEV OKOLJA SRC Infonet je podjetje, ki se lahko pohvali z 20-letno tradicijo aktivnega sodelovanja pri informatizaciji slovenskega zdravstvenega sistema. Povezuje preko 40 strokovnjakov s področja matematike, računalništva in informatike, ki svoje znanje in izkušnje s področja zdravstvene informatike uspešno združujejo s svežimi, originalnimi idejami, kar je podjetju omogočilo kontinuirano rast in vodilni položaj med ponudniki programske opreme za zdravstvo v Sloveniji. Od jeseni leta 2004 je Infonet član skupine SRC. S tem so uporabniki pridobili možnost priti do še celovitejše informacijske rešitve, ki bistveno razširja in nadgrajuje potencial obstoječih zdravstvenih informacijskih sistemov. Produkti podjetja SRC Infonet ustrezajo slovenskim in evropskim standardom za izgradnjo informacijskih sistemov v zdravstvu. S svojimi informacijskimi rešitvami danes nudijo informacijsko podporo v več kot 20 slovenskih bolnišnicah, prevedeni program pa se uporablja tudi v nekaterih tujih bolnišnicah (Makedoniji, Srbiji). Prav tako uporabljajo njihove rešitve v več kot 35 zdravstvenih domovih, na 9 zavodih za zdravstveno varstvo ter pri več kot 400 zasebnih ambulantah. S tako visokim deležem uporabnikov v Sloveniji je SRC Infonet tako vodilno in daleč najmočnejše podjetje na tem področju v Sloveniji. Aplikacije tečejo na več kot 4000 računalnikih, uporablja pa jih več kot 5000 delavcev v zdravstveni in lekarniški dejavnosti. Svetovalci podjetja sodelujejo pri mnogih aktivnostih, povezanih z razvojem informacijskih sistemov v zdravstvu tako doma kot v tujini. Poslanstvo podjetja je:

• razvoj in uvajanje računalniških informacijskih sistemov v zdravstveni in lekarniški dejavnosti,

• svetovanje pri razvoju in izgradnji informacijskih sistemov, • integracija informacijskih sistemov in • vzdrževanje informacijskih sistemov.

Svoje poslanstvo pa uresničuje s pomočjo vrednot, ki so glavno vodilo vseh podjetij v skupini SRC in jih tudi uveljavlja pri svojem delu:

• zadovoljstvo naročnika in končnih uporabnikov, • zadovoljstvo zaposlenih, • širitev partnerskega sodelovanja in • nenehna rast in razvoj.

Številni poslovni partnerji, obsežni projekti, vedno nove in nove zahteve, hiter razvoj, vse to so razlogi, zaradi katerih je bilo potrebno dosegati vse večjo kvaliteto. Zato se je vodstvo pred dvema letoma odločilo, da bo v podjetju načrtno uveljavilo politiko kakovosti. Kakovost storitev je eden od temeljnih ciljev podjetja in zanj si prizadevajo vsi delavci, ki jih je danes že več kot 40. Sistem kakovosti v podjetju je obvezujoč za vse sodelavce. Da so prizadevanja uspešna, so dokazali s pridobitvijo certifikata ISO 9001.



Bolnišni čni informacijski sistem BIRPIS21 BIRPIS21 (bolnišnični integrirani računalniško podprt informacijski sistem) je najcelovitejši sestavni del programskega paketa InfoMed21 podjetja SRC Infonet in je namenjen pokrivanju vseh informacijskih potreb v bolnišnični dejavnosti. Gre za informacijski sistem, ki omogoča spremljanje vseh dogodkov v zvezi s pacientom v različnih enotah bolnišnice oziroma dejavnostih, ki jih določena bolnišnica opravlja. Vsebuje vse module, ki so potrebni za učinkovito delovanje katerekoli bolnišnice, vključno z administrativnimi funkcijami na eni strani in visoko tehnološko zahtevnimi strokovnimi medicinskimi funkcijami na drugi. Pacient je v sistemu vseskozi obravnavan kot centralna entiteta. Glede na širok spekter možnih uporabnikov so razvite številne specializirane rešitve oziroma moduli, poleg tega pa je BIRPIS21 mogoče povezati v celovito informacijsko rešitev z različnimi programskimi produkti za podporo dela v laboratoriju (npr. L@b-IS®), radiološkimi informacijskimi sistemi (npr. iRIS21) itd. BIRPIS21 podpira delo s kartico zdravstvenega zavarovanja (KZZ) in računalniško izmenjavo podatkov z ZZZS in drugimi zdravstvenimi zavarovalnicami. Z razvojem komunikacijske platforme MedGateway so vzpostavili vso potrebno infrastrukturo za izmenjavo dokumentov (napotnice oziroma naročila, izvidi, odpustna pisma itd.) tudi z drugimi zdravstvenimi institucijami oziroma med posameznimi izvajalci zdravstvenih storitev na različnih nivojih zdravstvenega varstva. (www.infonet.si) 1.3 PREDPOSTAVKE IN OMEJITVE Pri izdelavi spletne aplikacije ePacient, ki je predmet diplomske naloge, smo se soočali z omejitvami, ki jih narekujejo različni predpisi in zakoni Republike Slovenije, ki urejajo področje varovanja osebnih podatkov in elektronske komunikacije. V nadaljevanju so predstavljene zakonske omejitve, katerih smo se morali držati, kolikor smo želeli, da spletna storitev ePacient dejansko zaživi in jo državljani smejo uporabljati. ZVOP V Republiki Sloveniji dejavnosti, pri katerih se upravlja z dokumentiranim gradivom in osebnimi podatki, ureja zakonodaja, ki vsebuje več zakonskih predpisov. Vsak izmed predpisov s svojega vidika ureja načine zbiranja in obdelovanja podatkov, prav tako pa izmenjavo elektronskih podatkom med različnimi akterji in izvajalci zdravstvenega varstva. V nadaljevanju je predstavljen zakon o varovanju osebnih podatkov in zahteve sistema ePacient, ki mu sledijo. Zakon o varstvu osebnih podatkov (ZVOP-1-UPB1, Ur.l. RS, št. 86/2004, v nadaljevanju: ZVOP-1-UPB1) ureja splošna načela in pogoje za zbiranje kakršnihkoli osebnih podatkov – po definiciji ZVOP-1-UPB1 so to katerikoli podatki, ki se nanašajo na posameznika, ne glede na obliko, v kateri je izražen. Ta zakon definira tudi posameznika – to je vsaka določena ali določljiva fizična oseba. Določbe ZVOP-1-UPB1 so torej zastavljene zelo široko, kar v praksi pomeni, da



mora biti vsako zbiranje, obdelovanje ali posredovanje osebnih podatkov skladno z ZVOP-1-UPB1. Zahteve izhajajoče iz zakona ZVOP: • Hranjenje dokumentov in informacij

ZVOP-1 predvideva hrambo podatkov le toliko časa, kolikor je potrebno za dosego namena, zaradi katerega so se zbirali ali obdelovali. Vendar pa je pomembno dejstvo, da organizacija ne sme shranjevati podatkov in informacij predolgo, saj so sicer po zakonu ZVOP-1 lahko kaznovane. Rok hrambe podatkov najlažje določimo tam, kjer so ti roki zakonsko določeni (v področnih zakonih, denimo v zakonu o Davčnem postopku); po navadi kot minimalni roki hrambe. Z vidika varstva osebnih podatkov je minimalni rok hrambe hkrati tudi maksimalen, če upravljavec podatkov nima drugega pravnega naslova za daljšo hrambo podatkov. V zakonih je trajna hramba podatkov predpisana le izjemoma (npr. evidenca zaposlenih, plače), zato se lahko zgodi, da je trajno shranjevanje podatkov kaznovano. Zakon veleva, da je potrebno podatke izbrisati ali anonimizirati takoj, ko jim preteče rok hrambe. Postopek izbrisa, uničenja oziroma anonimizacije se mora zapisati v notranjem aktu o varovanju osebnih podatkov.

• Sledljivost sprememb podatkov

Zakon veleva, da je potrebno zagotavljati sledljivost sprememb podatkov tako internih kot tudi eksternih. Pri internih obdelavah je treba voditi evidenco o tem, kdaj so bili posamezni osebni podatki vneseni v zbirko, uporabljeni ali drugače obdelani in kdo je to storil, pri posredovanju podatkov uporabnikom pa, kateri osebni podatki so bili posredovani, komu, kdaj in na kakšni pravni podlagi. Zahteva za vodenje sledljivosti posredovanj podatkov navzven je logična, ker izhaja iz pravic posameznikov, ki se lahko enkrat na tri mesece obrnejo na upravljavce zbirk osebnih podatkov in od njih zahtevajo seznam uporabnikov, katerim so bili njihovi osebni podatki posredovani, kot je, na primer vpogled v zdravniške kartoteke v zdravstvenih ustanovah, pri vpogledih v prometne podatke naročnikov pri telekomunikacijskih operaterjih itd. Sledljivosti v elektronskih evidencah se zagotavlja s programiranjem aplikacije tako, da se vodijo tudi dnevniki dostopov, ne samo vpisov, sprememb in brisanj podatkov.

• Posredovanje osebnih podatkov tretjim osebam

Zakon zahteva, da so posamezniki bodisi predhodno obveščeni o tem, komu se bodo ali bi se lahko posredovali njihovi osebni podatki (in imajo pravico tako obdelavo oziroma posredovanje svojih podatkov odkloniti) ali pa imajo posamezniki po posredovanju pravico do vpogleda v to, komu so bili njihovi podatki posredovani. Uporabniki podatkov (v Sloveniji, v EU in v tretjih državah) so navedeni v katalogih zbirk osebnih podatkov, podjetja pa je treba preveriti, ali podatke res posredujejo samo uporabnikom iz katalogov.

• Izvoz osebnih podatkov v tretje države

Tretje države so po ZVOP-1 države, ki niso članice Evropske unije ali Evropskega gospodarskega prostora ali ki zanje kako drugače ne velja pravni red EU. Za izvoz podatkov v tretje države velja nekaj posebnosti; tak izvoz je npr. dovoljen, če je tretja država na seznamu držav, za katere je bilo



ugotovljeno, da zagotavljajo ustrezno raven varstva osebnih podatkov (na tem seznamu sta trenutno Švica, Argentina, ni pa npr. Hrvaške, Rusije, ZDA). Če države ni na tem seznamu in če ni izpolnjen vsaj en od dodatnih pogojev, npr. ta, da tak izvoz določa zakon ali obvezujoča mednarodna pogodba, da je podana eksplicitna osebna privolitev posameznika za izvoz njegovih podatkov, da je izvoz potreben za izpolnitev pogodbe med posameznikom, na katerega se nanašajo osebni podatki, in upravljavcem osebnih podatkov in še nekaterih drugih, mora upravljavec za izvoz pridobiti dovoljenje informacijskega pooblaščenca.

• Povezovanje zbirk osebnih podatkov

Zbirke osebnih podatkov se lahko povezujejo na trajni osnovi (z nastankom nove, združene zbirke) ali pa tudi samo za posamezna dejanja (npr. vpogled v dve različni zbirki zaradi uparitve, primerjanja ali česa drugega). Bistveno je, da se je potrebno držati omejitev, katere obstajajo s posamezno zbirko. Če je operacija na povezani zbirki znotraj pooblastil na obeh zbirkah, potem je tako povezovanje oz. uporaba možna, sicer pa ne. Prav tako morajo upravljavci, ki povezuje dve ali več zbirk osebnih podatkov, ki se vodijo za različne namene, o tem predhodno pisno obvestiti državni nadzorni organ; če pa vsaj ena zbirka vsebuje občutljive podatke ali če bi povezovanje imelo za posledico razkritje občutljivih podatkov ali je za izvedbo povezovanja potrebna uporaba istega povezovalnega znaka (kot npr. davčna, EMŠO), povezovanje ni dovoljeno brez predhodnega dovoljenja državnega nadzornega organa.

ZEPEP Zakon o elektronskem poslovanju in elektronskem podpisu (ZEPEP, Ur. L. RS št. 57/2000, 98/2004) ureja elektronsko poslovanje, ki zajema poslovanje v elektronski obliki z uporabo informacijske in komunikacijske tehnologije in uporabo elektronskega podpisa v pravnem prometu. Zakon opredeljuje podatke v elektronski obliki, elektronski podpis, kvalificirana potrdila in overitelje. Zakon opredeljuje elektronski podpis, kod niz podatkov v elektronski obliki, katerih namen je tudi identifikacija podpisnika. Pri tem loči med elektronskim podpisom in varnim elektronskim podpisom. Pri slednjem so izpolnjene tudi zahteve glede nedvoumne povezave med elementom, ki je podpisan in podpisnikom ter možnost zanesljivega ugotavljanja, kdo je podpisnik. Z vpeljavo nove KZZ je potrebno zakon upoštevati tudi pri uporabi elementov identifikacije, ki so shranjeni na KZZ.



1.4 CILJI Cilj diplomske naloge je oblikovati funkcionalno, pregledno ter uporabniško prijazno spletno aplikacijo za elektronsko naročanje imenovano ePacient, ki bo omogočala:

• naročanje na pregled kadarkoli in kjerkoli – edini pogoj je zagotovljena možnost dostopa do interneta,

• nadzorovano, varno, zanesljivo in pravno formalno dostavo dokumentov: tako k osebnim zdravnikom in specialistom ali v bolnišnico kakor od vseh naštetih nazaj k pacientu,

• pravno formalno hranjenje dokumentov v ustreznem arhivu, • 24-urni vpogled v delne zdravstvene izvide v elektronski obliki, • dostop do informacij o zdravstvenih storitvah in izvajalcih, • naročila na pregled, preiskavo, slikanje, cepljenje oz. zdravstveno storitev pri

želenem izvajalcu zdravstvenih storitev, • obveščanje o novostih, spremembah, potrjenih napotnicah itd. preko

elektronske pošte ali mobilnih sms sporočil, • izdelava platforme, na podlagi katere bomo lahko v prihodnosti ponudili

popolnoma nove storitve, ki jih danes še ni moč ponuditi: obveščanje pacientov s popolnimi izvidi - trenutno so možni le delni, saj nam zakon več ne dopušča (Zakon o varovanju podatkov).

2 METODE DELA Izbrana metoda dela sloni na prototipnem načinu izdelave rešitev, kakor je prikazano na sliki 1. S pomočjo izdelanega prototipa spletne aplikacije ePacient in delovnih sestankov smo spoznali probleme trenutnega načina dela in želje ter zahteve pacientov in zdravstvenih delavcev. Spletno rešitev smo zasnovali ob kritični analizi obstoječega načina naročanja pacientov na preglede ter obdelavi njihovih naročil. Analizirali smo možnost povezave storitvene aplikacije ePacient z obstoječimi informacijskimi sistemi kot na primer BIPRIS21 podjetja SRC Infonet d.o.o., saj bi tako pacienti preko aplikacije ePacient imeli možnost naročila neposredno v sam informacijski sistem za podporo zdravstvenim dejavnostim.



Slika 1: Prototipno razvijanje (Benedik, 2009)

3 ANALIZA STANJA Sistem spletnega naročanja in obveščanja pacienta o njegovih izvidih in rezultatih preiskav danes v večini zdravstvenih ustanovah poteka ročno preko pripomočkov, kot so elektronska pošta in telefon. Pacientovo naročanje je sestavni del vsakdanjega dela za zdravstvene delavce, od majhnih ordinacij in ambulant do velikih bolnišnic, vendar pa je časovno in stroškovno zelo potraten proces, ki pa tudi ni preveč učinkovit. Velik problem, ki ga predstavlja običajno naročanje, je premajhna kapaciteta sprejemanja naročil ter obravnavanja posameznega naročila. Zdravstveno osebje lahko istočasno sprejema in obdeluje le eno naročilo, s čimer onemogoči komunikacijo z drugimi pacienti.

4 PREDLAGANA REŠITEV 4.1 KONCEPT SPLETNE REŠITVE Koncept spletne aplikacije ePacient temelji na že razviti storitveno usmerjeni arhitekturi (Service-oriented architecture - SOA) imenovani MedGateway podjetja SRC Infonet d.o.o. Tak način omogoča povezovanje različnih aplikacij, modulov med seboj v poslovne procese.



Pri snovanju spletne rešitve smo sledili naslednjim zahtevam, ki jih spletna aplikacija mora dosegati (Dolenc 2011):

• enostavnost in uporabnost, • kakovost elektronske storitve, • varnost, • hitrost, • preglednost, • neomejen dostop, neomejen čas (7x24).

Uporabnik se bo v okviru spletne aplikacije ePacient, na kateri so vzdrževani šifranti zdravstvenih ustanov, njihovih enot in storitev, elektronsko naročil na storitev, pri čemer se bo zdravstveni ustanovi poslalo elektronsko podpisano HL7 XML sporočilo preko storitvene platforme MedGateway. To sporočilo bo sprejel bolnišnični informacijski sistem (Birpis21), ga prebral in vložil v ustrezne tabele. Bolnišnični informacijski sistem Birpis21 bo ob akciji osebe, ki je zadolžena za naročanje (case-manager), prebral vsebino teh tabel in omogočil potrjevanje oziroma zavračanje zahtevkov, terminov; ob tem bo prišlo do elektronsko podpisanega odgovora v HL7 XML obliki. Spletna storitev s podatkovno bazo in poslovno logiko, ki posameznim uporabniškim vmesnikom, preko katerih se občan naroča, zagotavlja delovanje je del storitvene platfrome MedGateway. V večini delov je model pripravljen tudi na bodočo razširitev sistema z naročanjem s strani zdravnika (zdravnik naroči svojega pacienta na neko storitev v isti ali drugi ustanovi). Osnovni princip izmenjave podatkov je ponazorjen na sliki 2 :

• pošiljatelj dokumenta (uporabnik spletne aplikacije ePacient) pošlje HL7v3 dokument znanemu prejemniku (določena zdravstvena ustanova). HL7v3 XML dokument vsebuje želeni čas in kraj termina zdravstvenega pregleda,

• prejemnik sporočila (določena zdravstvena ustanova) s pomočjo storitve MedGateway in IS - BIRPIS21 zahteva seznam dokumentov, ki so mu namenjeni,

• prejemnik sporočila (zdravstvena ustanova) izbere dokument ( xml sporočilo z vsebino časa in kraja želenega termina) in potrdi njegov sprejem. Nato pošiljatelja umesti v urnik in nadaljuje s potrjevanjem termina.

Potrjevanje termina pregleda poteka na enak način, vendar v obratni smeri.



Slika 2: Koncept spletne rešitve



Storitveno vodilo MedGateway Storitveno vodilo je namenjeno povezovanju storitev v poslovne procese. Storitve lahko povezujemo sinhrono ali asinhrono. Vsa komunikacija med uporabniki in sistemom spletnega naročanja poteka preko storitvenega vodila MedGateway. Storitveno vodilo MedGateway je sestavljeno iz več delov (Bajželj, 2011):

• MedGateway Central, • MedGateway Proxy, • MedGateway Client .

Okolica Okolico predstavljajo bolnišnični informacijski sistemi (BIRPIS21), ki komunicirajo s sistemom spletnega naročanja na zdravniški pregled. 4.2 PROCES SPLETNEGA NAROČANJA NA PREGLED Preden smo pričeli z izgradnjo aplikacije ePacient, smo natančno popisali in predvideli način dela ter izrisali procese, ki potekajo od oddaje naročila do potrditve naročila. Proces spletnega naročanja na zdravniški pregled – A0 smo razdelili na 3 glavne procese:

• registracija spletnega naročanja na spletno storitev ePacient - A1, • naročanje na pregled - A2, • potrjevanje naročila - A3.

Nadalje smo procesa A2 in A3 razdelili na več podprocesov.



4.2.1 Spletno naro čanje na pregled A0

Slika 3: Spletno naročanje na pregled A0

Slika 3 prikazuje proces spletnega naročanja na zdravstveni pregled v izbrani zdravstveni ustanovi. Pri prvi uporabi spletne storitve ePacient se mora uporabnik registrirati (registracija pacienta A1). Registracija uporabniku dodeli uporabniško ime in geslo, s katerima se uporabnik naroči na želeni zdravniški pregled in dobi potrdilo naročila na pregled, preiskavo, slikanje idr. Proces Registracija pacienta se izvrši le ob prvi prijavi v sistem ePacient.



4.2.2 Naročanje na pregled A2

Slika 4: Naročanje na pregled A2

Slika 4 prikazuje proces naročanja na pregled, kjer je uporabnik že pridobil uporabniško me in geslo (registracija uporabnika A1), s katerima se lahko prijavi na spletno storitev. V procesu A2 uporabnik izbere želeno zdravstveno storitev (ustanova, aktivnost, storitev), izbere želeni termin zdravstvenega pregleda ter dokončno potrdi svoje naročilo.



4.2.3 Potrjevanje naro čila A3

Slika 5: Potrjevanje naročila A3

Slika 5 prikazuje proces potrjevanja naročila, kjer zaledni sistem posreduje uporabnikovo zahtevo po naročilu določenemu zdravstvenemu sistemu v ustanovi (Preverjanje istovetnosti pacienta A3.1). Informacijski sistem v izbrani zdravstveni ustanovi pacienta razporedi na želeni termin ter dokončno potrdi naročilo in termin na pregled (potrjevanje naročila in termina A3.3) in pošlje sporočilo o potrdilu preko zalednega sistema nazaj k pacientu na spletni portal ePacient. 4.3 TEHNOLOGIJA SPLETNE REŠITVE Sistem spletne storitve ePacient je centraliziran. Glavne komponente sistema so aplikacijski strežnik in podatkovni strežniki za hranjenje podatkov, ki v storitveni platformi MedGateway predstavlja MedGateway Client. V nadaljevanju je obrazloženo storitveno vodilo MedGateway, na katerem sloni celotna aplikacija ePacient (Bajželj, 2011). Centralni sistem (osrednja certificirana to čka) - MedGateway Central MedGateway Central je storitev (slika 6), ki skrbi za komunikacijo med vsemi ustanovami v zdravstvenem sektorju, kjer se pošiljajo dokumenti v elektronski obliki preko koncentratorske točke. Osnovni namen storitve je nadzorovana, varna, zanesljiva in pravno-formalna dostava dokumentov med dvema institucijama ter pravno-formalno hranjenje dokumentov v ustreznem arhivu. Hkrati pa storitev predstavlja platformo, na podlagi katere bo v prihodnje možno ponuditi popolnoma



nove storitve (inteligentno obveščanje pacientov o izvidih, informiranje pacientov o času obiska pri zdravniku, inteligentne čakalne vrste, virtualna lekarna, pacientov portal...).

Slika 6: Logična shema ideje povezanega sistema

Predstavlja jedro aplikacije, in nudi: • varno in zanesljivo izmenjavo elektronskih dokumentov (napotnice,

laboratorijski izvidi, ipd). Elektronski dokumenti imajo standarden format (naprimer HL7),

• centralni arhiv podatkov kot nadomestilo današnjim številnim registrom in evidencam. Vsi dokumenti, ki si jih medicinske ustanove izmenjujejo, so shranjeni na centralnem informacijskem sistemu,

• inteligentno obveščanje in informiranje pacientov, • možnost vpogleda in nadzor nad izvajalci zdravstvenih storitev, • inteligentno obveščanje skrbnika o delovanju sistema.

Dokumenti, podatki ali samo njihovi kazalci se hranijo na centralnem sistemu, tako imenovani osrednji certificirani točki. Sam sprejem in obdelavo podatkov v tej osrednji točki lahko razdelimo v dve fazi:

• varnostno preverjanje, preverjanje digitalnega podpisa, validacija, • izvedba poslovne logike.

Lokalna vstopna to čka (certificirana to čka) - MedGateway Proxy To je storitev, nameščena v okolju izvajalca zdravstvenih storitev (v lokalnem omrežju), ki želi uporabljati funkcionalnosti storitvene platforme “MedGateway Central”. Izvajalec izdravstvenih storitev mora storitev MedGateway Proxy najprej pravilno namestiti na računalniški sistem, nato pa storitev MedGateway Proxy registrirati preko administracijskega modula (Web GUI) sistema MedGateway Central. Ob registraciji dobi MedGateway Proxy enoličen naslov (ProxyID), s katerim se vedno identificira.

Institucija Institucija Institucija Institucija

Partner A Partner B

Partner C

medGateway



Sistem MedGateway Proxy s storitveno platformo MedGateway Central komunicira s pomočjo spletnih storitev preko varne povezave SSL (SOAP/HTTPS). MedGateway Proxy zagotavljala naslednje funkcionalnosti:

• od ene ali več storitev MedGateway Client, ki so nameščene pri izvajalcu zdravstvenih storitev sprejema digitalno podpisane dokumente in jih posreduje storitveni platformi MedGateway Central,

• od ene ali več storitev MedGateway Client, ki so nameščene pri izvajalcu zdravstvenih storitev sprejema zahtevke (poizvedbe), s katerimi izvajalci zdravstvenih storitev preverjajo oz poizvedujejo po dokumentih, ki so jim namenjeni,

• digitalno podpisane XML dokumente v kriptirani obliki shranjuje v lokalno podatkovno bazo (Oracle), ki si jo deli skupaj s klientom MedGatewayClient,

• od sistema MedGateway Client periodično sprejema zahtevke, s katerimi preverja ali je na sistemu MedGateway Central kaj novih dokumentov.

Naloge sistema »MedGateway Proxy« so:

• Vsebinske: o shranjevanje vsakega dokumenta za izmenjavo v kriptirani obliki v

lokalno podatkovno bazo (Oracle Database 10g), o pošiljanje digitalno podpisanih in nekriptiranih dokumentov sistemu

»MedGateway Central« preko varne transportne povezave, o povpraševanje centralnega sistema »MedGateway Central« ali

obstajajo dokumenti, ki so namenjeni določenemu »MedGateway Proxy-u« oz. lokalni MedGateway storitvi.

• Sistemske: o Periodično pošiljanje podatkovnih paketov (ping), ki sporoča sistemu

»MedGateway Central«, ali je »MedGateway Proxy« povezan v komunikacijsko omrežje.

Odjemalec - MedGateway Client To je samostojna aplikacija, nameščena pri izvajalcu(ih) zdravstenih storitev. V fazi pilota aplikacija omogoča naročnikom (zdravnikom, zasebnikom, bolnišnicam, zdravstvenim domovom in drugim institucijam v zdravstvu), da elektronsko naročijo laboratorijske preiskave v ustrezen laboratorij in da od njega v elektronski obliki prejmejo izvide. V fazi pilota bosta nadgrajena odjemalca ISOZ21 (Informacijski sistem osnovnega zdravstva) in L@b-IS (Biokemični laboratorij) HL7 standard

HL7 je ameriški standard, ki vsebinsko pokriva celotno medicinsko domeno od registracije vseh zdravstvenih subjektov do evidentiranja vseh možnih medicinskih podatkov ter do sporočanja statistik in poročil državnim institucijam (Health Level Seven International,2011).



HL7 Transmission Wrapper

HL7 Control Act Wrapper

HL7 Medical Data

Slika 7: Struktura dokumenta HL7

HL7v3 sporočilo je sestavljeno iz medicinskih podatkov (HL7 Medical Data), ki jih obkrožata dve ovojnici (Slika 8):

• HL7 Control Act Wrapper (vsebuje informacijo o dogodku, ki je sprožil nastanek določenega HL7 dokumenta. Control Act Wrapper je obvezen element v vsakem HL7 sporočilu, razen v potrditvenih sporočilih),

• HL7 Transmission Wrapper (vsebuje informacije o prejemniku, naslovniku in pošiljatelju dokumenta).

XML struktura Extensible Markup Language, specifikacija razvita pri W3C. XML je okleščena verzija SGML, načrtovana predvsem za spletne dokumente. Načrtovalcem dovoljuje kreiranje lastnih oznak (tagov), kar omogoča definicijo, prenos, validacijo in interpretacijo podatkov med aplikacijami in med organizacijami. XML je tričrkovna okrajšava za angleški izraz Extensible Markup Language, razširljiv označevalni jezik, in je jezik, ki ga pogosto srečate, če brskate po Internetu. XML je preprost računalniški jezik podoben HTML-ju, ki nam omogoča format za opisovanje strukturiranih podatkov ali arhitektura za prenos podatkov in njihovo izmenjavo med več omrežji. XML spreminja mnogo aspektov računalništva, še posebej na področju komuniciranja aplikacij in strežnikov. Da pa se ga tudi razširiti, saj ima namreč to možnost, da si lahko sami izmislimo imena etiket (angleško TAG). Zelo je uporaben za komunikacije, saj ima preprosto in pregledno zgradbo. XML je razdeljen na 3 dele:

• podatkovni (vanj shranimo podatke v neki obliki z želenimi etiketami (tag)),

• deklarativni (skrbi za to, da lahko pri dodajanju novih podatkov vidimo, kaj kakšna etiketa predstavlja),

• predstavitveni (z njim oblikujemo izpis podatkov).



Razvijalci XML povečujejo vsebino tega jezika in s tem njegovih standardov tehnologije, ki vsebujejo podatke, ki se jih da enostavno preoblikovati in zamenjati v neenakih sistemih. SOAP (Bajželj, 2011) SOAP (Simple Object Access Protocol) je specifikacija protokola namenjenega izmenjavi strukturiranih informacij pri implementaciji spletnih storitev v računalniškem omrežju. Naslanja se na XML (Extensible Markup Language) za obliko sporočil in (običajno) na HTTP protokol (Hypertext Transfer Protocol) za sporazumevanje in prenos. HTML HTML predstavlja jezik, ki ga uporabljamo za pisanje spletnih strani. Vsebuje nabor posebnih oznak, ki pa so neodvisne od platforme. Glavna lastnost HTML jezika je njena enostavnost, saj je bil zasnovan tekstovno z minimalnim naborom znakov. Tako je bilo omogočeno hitro učenje in pisanje s poljubnim urejevalnikom teksta. HTML jezik se je skozi leta dopolnjeval in dograjeval z različnimi dodatki. Proizvajalci, ki so prevzeli nadaljnji razvoj HTML jezika, dodajajo vedno nove oznake in tako mu omogočajo, da se jezik razvija tudi v drugih različicah kot na primer XHTML, DHTML, VML in druge. Tako kot smo omenili že zgora, naj bi HTML predstavljal semantično strukturo in smiselno hierarhijo dokumenta, medtem ko CSS nastopa v vlogi predstavitev različnih elementov strukture HTML. CSS CSS je kratica in pomeni Cascading Style Sheets. Prevedli bi jo lahko kot predlogo, ki določa, kako bo izgledala spletna stran v brskalniku. Je poskus, da se izdelovalcem spletnih strani omogoči ločevanje vsebine spletnih strani od dizajna. In ta poskus je v celoti uspel. Preboj CSS-a se je začel, ko se je pojavila potreba po lepših, boljših in predvsem zahtevnejših spletnih straneh. CSS je vse to poenostavil. Medtem ko je HTML, kot nekakšen vojak iz prve vrste, je CSS general iz ozadja, ki določa, kako se bo ta vojak obnašal, katere vrste uniformo bo imel, s kakšnim orožjem bo oborožen. Kot že rečeno je ena od značilnosti CSS-a, da je dizajn spletnih strani ločen od kode, kar v praksi pomeni, da je tudi menjavanje izgleda spletne strani enostavnejše. Saj na primer z nekaj preprostimi ukazi zamenjamo celoten videz spletne strani. Postavitev menijev je na vseh predlogah enaka, dimenzije spletne strani so enake, zamenja se samo barvna shema in strani dobijo popolnoma drug izgled. To nam omogoča CSS z enim ukazom, ki določa barvo menijev in ozadja.



Slika 8: Primer oblik zgradbe modela CSS

Uporaba CSS-a pa prihaja do izraza pravzaprav šele danes, ko imamo veliko število spletnih brskalnikov, ki vsak nekoliko drugače prikazuje spletno stran. In ravno CSS nam omogoča, da se za vsak brskalnik posebej napiše predloga. Prav tako nam CSS omogoča, da spletno stran pravilno prikažejo tudi drugi prikazovalniki in ne samo spletni brskalniki. Spletni brskalniki, ki standarda CSS ne podpirajo, bodo prikazali običajen HTML- dokument brez oblikovanja. 4.4 GRAFIČNI UPORABNIŠKI VMESNIK V okviru diplomske naloge smo izdelali tudi vizualne podobe spletne aplikacije. Pri izdelavi vmesnika smo se ozirali tudi na želje vseh obstoječih in bodočih uporabnikov. Grafični uporabniški spletni vmesnik je narejen s tehnologijo CSS – Cascading Style Sheets v programu DreamViewer.



Osnovni namen spletne strani je zadovoljiti uporabnika. Da pa lahko spletna stran zadovolji uporabnika, mora zadostiti določenim kriterijem. Kriteriji za izdelavo dobre spletne strani so: (Marjetič, 2003):

- oblikovna podoba, - navigacija, - vsebina, - uporabnost, - interaktivnost, - trženjski vidik.

Oblikovna podoba je prvi stik uporabnika s spletno stranjo. Izkušnje narekujejo, da je preprosta spletna stran, ki ne vsebuje nepotrebnih odvečnih elementov, najbolj zaželena med uporabniki. Ko oblikujemo spletno stran, je potrebno veliko pozornosti nameniti:

- všečnosti, - navigaciji, - barvi, - ozadju, - grafičnim elementom, - tipografiji, - velikosti pisave,

Skrt (2003) navaja, da je potrebno pri oblikovanju grafične podobe upoštevati naslednje stvari:

- količina barv ne sme biti pretirana, - izogibati se je potrebno nekoristnim animacijam, slikam, utripajočim

premikajočim napisom, zvoku …, - ozadje ne sme izstopati, - grafični elementi morajo popestriti spletno stran, ne pa zadušiti, - grafični elementi morajo biti optimizirani za nalaganje, - uporaba temne pisave na svetli podlagi.

Dobro oblikovana spletna stran naredi vtis harmonije barv in vsebine, vendar pa je potrebno biti pozoren tudi na vsebino, saj spletna stran brez primerne vsebine nima uporabne vrednosti. Pri oblikovanju spletne strani ePacient smo se držali načela čim večje preprostosti predvsem zaradi populacije, kateri je spletna stran namenjena, ter všečnosti spletne strani. V nadaljevanju so prikazani elementi strukture spletne strani glede na proces, ki ga podpirajo.



4.4.1 Spletno naro čanje na pregled A0/A2.1 Ob vstopu na spletni portal ePacient se prikaže vstopna stran, na katero se lahko vrnemo ob pritisku na gumb .

Slika 9: Vstopna stran

Za vstop na spletni portal je potrebno vnesti uporabniško ime, katerega predstavlja veljavna številka ZZZS (Devetmestna KZZ številka se nahaja na kartici zdravstvenega zavarovanja) ter geslo. Kolikor uporabnik še ni prijavljen v sistem, to lahko stori s klikom na polje v nasprotnem primeru po vnosu zahtevanih prijavnih podatkov uporabnik klikne na polje . V primeru izgube gesla lahko le-tega pridobi uporabnik nazaj preko elektronske

pošte s klikom na .



Slika 10: Pozabljeno geslo



4.4.2 Registracija A1 Za uporabo portala ePacient se je potrebno predhodno registrirati. Za registracijo poleg osebnih podatkov uporabnik potrebuje številko ZZZS ter EMŠO.

Slika 11: Registracija uporabnika

Po vnosu osebnih podatkov registracijo zaključimo s klikom na . Registracijo nadaljujemo s potrditvijo aktivacije, ki jo uporabnik prejme preko spletne pošte.



Slika 12: Obvestilo o aktivaciji registracije

Preko spletne pošte uporabnik aktivira registracijo in se tako lahko prijavi na portal preko svoje ZZZS številke ter osebnega gesla, ki si ga je izbral ob registraciji.



4.4.3 Izbiranje storitve A2.2 Na strani Naročilo na pregled uporabnik izbere ustrezno ustanovo, kjer se želi naročiti na pregled, nato ambulanto znotraj izbrane ustanove ter storitev izbrane ambulante. V polju Namen pregleda vpiše razloge oz. namen pregleda, ki ga želi opraviti. Potek priprave naročila je prikazan na vrhu strani Naročilo na pregled. Na desni strani je prikazan delovni čas ordinacije, ki mu pomaga izbrati primerno uro pregleda. Naročilo na pregled uporabnik nadaljuje s klikom na .

Slika 13: Naročilo na pregled 1/3

V prazno polje uporabnik vpiše želeni termin in zdravnika za pregled v ustanovi/ambulanti, katero je predvidel na prejšnji strani.




Po zaključku procesa izbire termina se prikaže stran s povzetkom naročila. To omogoča pregled naročila, popravilo naročila s klikom na ter potrditev oz. oddajo naročila s klikom na .




Po uspešno oddanem naročilu se prikaže okno : Naročilo uspešno zaključeno.

Slika 16: Potrdilo Naročila na pregled



Osnovni podatki Na zavihku Osnovni podatki lahko uporabnik pregleda svoje osebne podatke ter jih po potrebi tudi ureja. Poleg osnovnih podatkov prikazuje stran tudi število naročil, ki čakajo na odobritev s strani zdravstvene ustanove

Slika 17: Osnovni podatki

Slika 18: Osnovni podatki / Urejanje



Aktualna naro čila Stran omogoča vpogled v vsa aktualna naročila (naročila, ki čakajo na potrditev ali pa so že potrjena). Prikazane so vsi podatki naročila.

Slika 19: Aktualna naročila



4.4.4 Potrjevanje naro čila in termina A3.3

Pacient takoj, ko ga v zdravstveni ustanovi razporedijo na prosti termin v čakalni knjigi, prejme na portal ePacient potrjeno naročilo na pregled, ki ga lahko natisne in prinese s sebj na dogovorjen termin k zdravniku. V primeru, da s terminom uporabnik ni zadovoljen lahko zamenja termin, lahko pa tudi prekliče naročilo. Sistem omogoča tudi obveščanje o novostih, spremembah, potrjenih napotnicah itd. preko elektronske pošte ali mobilnih sms sporočil.

Slika 20: Potrjevanje naročila in termina



4.5 POVEZAVA Z INFORMACIJSKIM SISTEMOM BIRPIS21 4.5.1 Preverjanje istovetnosti A3.1

Pacientovo naročilo se pojavi na seznamu Elektronsko naročenih pacientov. Na tem seznamu so naročeni pacienti, ki jih zdravstveni delavec še ni uvrstil v čakalno knjigo. Z akcijo ga upari s pacientom (uporabnikom spletne aplikacije ePacient) v registru pacientov – iskanje po različnih kriterijih.

Slika 21: Uparjenje pacienta

Slika 22: Preverjanje istovetnosti pacienta



4.5.2 Razporejanje termina pacienta A3.2 Naročila, ki so poslana iz ePacienta, se avtomatsko pokažejo v uporabnikovem zdravstvenem sistemu (ISOZ21, BIRPIS21). Poslana naročila mora zdravstveno osebje samo razporediti na določen termin.

Slika 23: Razporejanje termina pacient

4.6 VARNOST Vse večja uporaba informacijskih rešitev na različnih področjih, vključno s področjem zagotavljanja zdravstvenega varstva, zahteva oblikovanje primernih načinov identifikacije in avtorizacije uporabnikov, saj klasični načini identifikacije praviloma niso možni, (kadar pa so, negativno vplivajo na uporabnost in sprejemljivost novih rešitev). Namen identifikacije je nedvoumna predstavitev uporabnika ali storitve informacijskemu sistemu pred uporabo sistema. Na podlagi identifikacije bo sistem uporabniku dovolil ali zavrnil dostop do sistema ali njegovega dela. Pri uporabi vse večjega števila sodobno podprtih storitev, ki jih poznamo po predponi e-storitve, se le-te tudi medsebojno povezujejo; pri tem pa je potrebno zagotoviti smiselne avtorizacijske sheme. Avtorizacijske sheme preprečujejo nepooblaščeno uporabo storitev in dostop do informacij tako končnim uporabnikom kot tudi drugim sistemom in storitvam. Pomembno pri tem je, da so načini identifikacije in avtorizacije med seboj skladni. Na področju zdravstvenega varstva v Republiki Sloveniji je ustaljen način identifikacije z uporabo Kartice zdravstvenega zavarovanja (KZZ). Kartica rešuje problem enolične identifikacije v domeni zdravstvenega varstva, saj vpelje številko



zavarovane osebe, ne omogoča pa globalne unikatne identifikacije med različnimi domenami. V nadaljevanju obravnavamo področje identifikacije uporabnikov storitve ePacient in področje avtorizacije pri uporabi storitev ne oziraje se na to, ali storitev uporablja končni uporabnik ali kaka druga storitev. Podajamo pregled standardov in zakonodaje za področje zdravstvene informatike in elektronskega poslovanja, ki predstavlja ključne tehnološke pristope in rešitve na področju identifikacije uporabnikov. Osnovni namen storitve ePacient je povečanje dostopnosti, uporabe in preglednosti informacij v zdravstvene namene z vpeljavo možnosti spletnega naročanja na zdravniški pregled. Ker spletna aplikacija temelji na storitveni platformi MedGateway, je potrebno poudariti dvoje:

• problem identifikacije uporabnikov storitev, • problem avtorizacije uporabnikov in storitev pri medsebojnem povezovanju

skozi infrastrukturo platforme MedGateway. Pri identifikaciji je potrebno zagotoviti enolično razpoznavo uporabnikov spletne storitve in zdravstvenih storitev z dovolj učinkovitimi mehanizmi in tehničnimi rešitvami, ki zagotavljajo sprejemljivo stopnjo varnosti in zanesljivosti. Imeniške storitve standarda ISO21091 Standard Zdravstvena informatika - Imeniške storitve za varnost, komunikacijo in identifikacijo zdravstvenega osebja in pacientov (ISO/DIS 21091:2008, Health informatics — Directory services for security, communications and identification of professionals and patients) je namenjen podpori komunikacijskih in varnostnih zahtev pri izvajanju kliničnih in administrativnih nalog v zdravstvu. Zdravstvo zahteva šifriranje podatkov na najvišjem nivoju in dodelan sistem za nadzor dostopa do podatkov. Za zagotavljanje varnosti z javnim ključem zdravstvene infrastrukture bo za vodenje tako poslovnih kot tudi strokovnih informacij na voljo register potrdil, ki bo vključeval prepoznavanje posameznih vlog v okviru celotnega zdravstvenega sistema (vloge lahko upravljajo z različnimi podatki). V sistemu morata biti registracija in funkcija upravljanja razširljivi in vključevati vso zdravstveno skupnost. Podpora za te zahteve mora biti na voljo tudi preko imeniških storitev. Ker postaja delo z imeniškimi storitvami vse bolj priljubljeno, bo za dodatne potrebe zmogljivosti potrebno razširiti imenik obstoječe sheme za vključitev zaposlenih v zdravstvu.

Smernice za zavarovanje osebnih podatkov v informac ijskih sistemih bolnišnic Informacijski pooblaščenec je leta 2008 izdal smernice, ki odgovarjajo na pogosta vprašanja glede upoštevanja Zakona o varstvu osebnih podatkov v bolnišnicah. Podlaga za smernico je 49. člen ZVOP-I-UPBI, ki določa, da gre za neobvezno smernico oziroma priporočilo. Smernica je dopolnilo k zakonskemu okvirju, ki ga določa ZVOP glede varovanja osebnih podatkov v bolnišnicah in drugih zdravstvenih ustanovah, saj se pri nudenju zdravstvenih storitev neizogibno srečamo z obdelavo občutljivih osebnih podatkov, ki zahtevajo primerno varovanje. Smernica povzema ključne elemente 24. člena ZVOP-I-UPBI, nato pa podaja odgovore glede uporabe in implementacije bolnišničnega informacijskega sistema



BIS, da bo le-ta skladen z zahtevami ZVOP glede varovanja osebnih podatkov. Informacijski pooblaščenec v enem izmed odgovorov navaja tri nivoje sledljivosti pri uporabi sistemov BIS, in sicer:

• sledljivost sprememb, • sledljivost dostopa do podatkov in • popolna sledljivost z beleženjem dostopov, sprememb podatkov in hrambo

revizijske sledi. Pri tem poda mnenje, da tretji nivo sledljivosti z zakonom ni zahtevan, je pa tehnično izvedljiv, medtem ko je drugi nivo za občutljive osebne podatke potrebno zagotoviti ne glede na okoliščine dostopa in uporabe tovrstnih podatkov (npr. urgenca). Pri tem odsvetuje uporabo skupinskih uporabniških imen in gesel in/ali skupinskih dostopov z uporabo ene prijave. Izjemoma dopušča možnost uporabe skupinskih dostopnih pravic (npr. urgentni tim), kjer gre za utemeljene razloge, vendar pa mora biti skupina ljudi, ki je v posameznem časovnem obdobju sestavljala skupino, jasno evidentirana. Informacijski pooblaščenec posebej opozarja, da nepraktičnost pogostega odjavljanja in prijavljanja uporabnikov v informacijski sistem ni razlog za uporabo skupinskih prijav oziroma dostopov do podatkov in poudarja, da je neprestana dosegljivost delovne postaje nedopustna in je potrebno poskrbeti za samodejno zaklepanje po določenem času neaktivnosti. Za storitveno platformo iHub je tudi pomembno mnenje informacijskega pooblaščenca glede samodejnega pošiljanja podatkov med različnimi informacijskimi sistemi (npr. uporaba nove KZZ) in elektronsko izmenjavo podatkov. Podatke je pri prenosu po telekomunikacijskih omrežjih potrebno ustrezno zavarovati (uporaba kriptografskih metod in kvalificiranih digitalnih potrdi), posebna obravnava pa je potrebna v primeru povezovanja zbirk osebnih podatkov, kjer je z zakonom zahtevano dovoljenje pooblaščenca. Evropske smernice za zdravstvene delavce o zaupnost i in zasebnosti v zdravstvu Smernice obravnavajo zaupnost v zdravstvu in zasebnost osebnih podatkov in so namenjene vsem zdravstvenim delavcem. Obravnavajo tri področja:

• varovanje, rabo in razkrivanje osebnih podatkov o bolnikih za njihove zdravstvene potrebe,

• varovanje, rabo in razkrivanje osebnih podatkov o bolnikih za rabo v zdravstvene namene, ki niso neposredno povezani z njihovimi zdravstvenimi potrebami in

• obveznosti in upravičenost do razkritja osebnih podatkov o bolnikih za rabo v namene, ki niso povezani z njihovimi zdravstvenimi potrebami.

Smernica ni namenjena delovanju in uporabi informacijskih sistemov, vendar pa uporaba le-teh pri delu od informacijskih sistemov zahteva, da zdravstvenim delavcem omogočijo spoštovanje smernic. Zakon o elektronskem poslovanju in elektronskem pod pisu Zakon o elektronskem poslovanju in elektronskem podpisu (ZEPEP, Ur. L. RS št. 57/2000, 98/2004) ureja elektronsko poslovanje, ki zajema poslovanje v elektronski obliki z uporabo informacijske in komunikacijske tehnologije in uporabo elektronskega podpisa v pravnem prometu. Zakon opredeljuje podatke v elektronski



obliki, elektronski podpis, kvalificirana potrdila in overitelje. Zakon opredeljuje elektronski podpis, kod niz podatkov v elektronski obliki, katerih namen je tudi identifikacija podpisnika. Pri tem loči med elektronskim podpisom in varnim elektronskim podpisom. Pri slednjem so izpolnjene tudi zahteve glede nedvoumne povezave med elementom, ki je podpisan, in podpisnikom ter možnost zanesljivega ugotavljanja, kdo je podpisnik. Z vpeljavo nove KZZ je potrebno zakon upoštevati tudi pri uporabi elementov identifikacije, ki so shranjeni na KZZ. 4.6.1 Identifikacija in avtorizacija uporabnikov Identifikacija uporabnika je razpoznava posameznika in povezava s podatki, ki jih o uporabniku hrani informacijski sistem. Podatki lahko zajemajo osebne podatke uporabnika, pravice za dostop do podatkov drugih uporabnikov, dostop do poslovnih podatkov na sistemu in pravice za izvajanja funkcij tega ali drugih povezanih sistemov. Osnovni trije principi identifikacije uporabnikov so:

• nekaj, kar imaš (ang. Samething you have) – v primeru storitve ePacient kartica zdravstvenega zavarovanja in kvalificirano digitalno potrdilo,

• nekaj, kar veš (ang. Things you have) – geslo, • nekaj kar si (ang. Things you are) - npr. prstni odtis, prepoznava roženice

očesa, prepoznava glasu ipd. Pri prvem principu je pomembno, da uporabnik poseduje posebno stvar, na podlagi katere ga lahko identificiramo, saj druge osebe tega nimajo. Pred računalniško dobo je ta princip predstavljal pečat, poseben simbol (insignia) ali ključ. Z uporabo računalnikov lahko gre zgolj za posebno datoteko, ki vsebuje identifikacijske karakteristike posameznika. Pogosto so podatki zapisani na ločenem, zunanjem, nosilcu, ki poveča varnost principa, npr. magnetna kartica, pametna kartica, naprava za generiranje identifikacijske številke. Za lažje sklicevanje na različne načine izvedbe tega principa ga bomo v sklopu dokumenta poimenovali žeton. Avtentikacija na podlagi žetona je v primerjavi z avtentikacijo na principu "nekaj kar veš" z uporabo gesla, bolj varna, saj temelji na fizičnem elementu, ki ga je potrebno pridobiti za vstop in delo na sistemu. Pri žetonih je tudi lažje ugotoviti, ali je bil žeton ukraden ali izgubljen. Slabost tega principa je višja cena in možnost strojnih napak. Pri tem velja opozoriti, da so bile določene izvedbe žetonov že varnostno kompromitirane, zato se uporaba v sistemih, kjer se zahteva visoka stopnja varnost, odsvetuje. Primer takšnega žetona je kartica z magnetnim zapisom, saj se lahko magnetni zapis relativno enostavno prebere in ustvari nova kartica, ki omogoča dostop nepooblaščeni osebi. Pri drugem principu je identifikator uporabnika skrivna informacija, ki jo pozna samo uporabnik. Pred uporabo računalnikov je ta princip predstavljalo skrivno geslo, ki se je preneslo ustno, ali kombinacija za odpiranje ključavnice oziroma trezorja. Z uporabo računalnikov se je razširila uporaba gesla, fraze ali osebne identifikacijske številke ( Personal Identification Number, PIN). Prednost tega pristopa je enostavna in cenovno ugodna rešitev, slabost pa ranljivost za napade. Tretji princip je povezan s fizično lastnostjo ali obnašanjem uporabnika, na podlagi česar ga lahko enolično razpoznamo.



Najbolj razširjen način identifikacije uporabnikov za dostop in uporabo informacijskih sistemov je uporaba uporabniškega imena in gesla. Gre za niz znakov, ki jih uporabniku določi administrator informacijskega sistema ali informacijski sistem samodejno na podlagi algoritma in jih lahko uporabnik delno (samo geslo) ali v celoti (uporabniško ime in geslo) spremeni. Ob prijavi v informacijski sistem se vneseni podatki povežejo s podatki uporabnika na sistemu - praviloma na podlagi uporabniškega imena, preverjanje pristnosti (avtentikacija) uporabnika pa se izvede s pomočjo gesla. Identifikacija na podlagi uporabniškega imena in gesla ima številne slabosti:

• nezanesljivost identifikacije - uporabniško ime in geslo ne zagotavljata, da se je v sistem prijavila oseba, za katero predvidevamo, da se je. Lahko gre za odtujitev podatkov ali pa nekdo namenoma "posodi" uporabniško ime in geslo drugi osebi,

• slab nadzor nad uporabo - kljub vpeljavi pravil glede uporabe uporabniških imen in gesel se v praksi srečujemo s številnimi problemi. Navedimo nekaj primerov: predpisana dolžina gesel, kompleksnost gesla, zamenjava gesel, hranjenje gesel ipd.. Uporabniki si pogosto nastavijo preveč enostavna gesla, gesla hranijo na lahko dostopnih krajih, ne upoštevajo predpisane strukture gesla (možno preverjanje, vendar ni zmeraj učinkovito), ne zamenjujejo gesel v predpisanih intervalih ali ob zahtevanih časovnih trenutkih (npr. po inicializaciji sistema) – kar je sicer možno preverjati,

• zahtevno odkrivanje kompromitiranih gesel - ker gre za niz znakov, ki ga lahko napadalec bodisi prestreže, zabeleži s posebnimi napravami, dešifrira, najde v primeru, ko je geslo neprimerno shranjeno ipd., je zaznava gesel, ki so bila tako ali drugače razkrita, izredno težka. Uporabimo lahko metode preverjanja prijav, vendar je za večje število uporabnikov metoda nepraktična.

Pri spletni aplikaciji ePacient uporabljamo naslednje načine identifikacije uporabnika:

• uporabniško ime in geslo - praviloma se uporablja za vpoglede ne pa tudi za izvajanje transakcij,

• kvalificirano digitalno potrdilo - avtorizacija se izvede na podlagi javnega ključa, komunikacija se šifrira z uporabo simetrične kriptografije, kjer se šifrirni ključ izmenja z uporabo kriptografije, ki temelji na javno/privatnih ključih. Najprej se izmenja simetrični ključ za varno izmenjavo vsebin, nato se z njim šifrirajo vsebine.



4.6.2 Varnostna shema Varnostna shema aplikacije sistema obravnava varnost na vseh sistemskih in aplikacijskih nivojih (Bajželj, 2011):

• varovanje identitete informacij (digitalno podpisovanje dokumentov uporabnikov sistema(PKI),

• varovanje spletnih in aplikacijskih strežnikov. (Gostiteljski operacijski sistemi imajo odstranjene vse servise, ki niso potrebni za delovanje sistema. Spletni in aplikacijski strežniki imajo odstranjene vsa privzeta gesla in vse vzorčne aplikacije),

• varovanje komunikacije (HTTP preko SSL), • varovanje transakcij. (Vse poslovne transakcije se beležijo. Občutljivi podatki

so kriptirani), • varovanje sporočil. (Sporočila so med prenosom varovana ne samo na

transportnem nivoju ampak tudi sporočilnem nivoju: digitalni podpisi in enkripcija),

• varno beleženje in revizija (Implementirani so mehanizmi za forenzično poizvedovanje),

• razpoložljivost (Sistem ima vsaj en zaleden sistem, ki v primeru izpada primarnega sistema transparentno prevzame njegovo vlogo. Sistem hrani tudi vse varnostne kopije – backup – svojih podatkov).

Slika 24: Varnostna arhitektura storitvene platforme MedGateway (Bajželj, 2011)



4.6.3 Infrastruktura javnih klju čev – PKI Infrastruktura javnih ključev je nabor strojne in programske opreme, uporabnikov, politik in postopkov za izdelavo, upravljanje, hrambo, distribucijo in odpoklic digitalnih potrdil. Infrastruktura javnih ključev naslavlja naslednje probleme, povezane z uporabo asimetrične kriptografije: • Avtentičnost ključev - Z uporabo digitalnega potrdila povežemo uporabnika

(običajno pravno ali fizično osebo, strežnik) z javnim ključem. Na ta način lahko preverimo, komu pripada javni ključ, še preden ga uporabimo in se s tem izognemo napadom moža v sredini.

• Odpoklic ključev - Ključe, ki jih izdelamo za uporabo v asimetrični kriptografiji,

običajno uporabljamo dlje časa. Kako lahko vse ostale uporabnike našega javnega ključa obvestimo, da je nekdo pridobil dostop do našega računalnika in prekopiral naš zasebni ključ? Ali kako vse paciente obvestimo, da oseba (npr. zdravnik, medicinska sestra) z določenim javnim ključem pri nas ni več zaposlena in zato ne sme več uporabljati javnega in zasebnega ključa, ki ga je prejela od delodajalca (npr. zdravstvene ustanove)?

Eden pomembnejših elementov infrastrukture javnih ključev je overitelj. To je zaupanja vredna tretja oseba, ki izdaja digitalna potrdila (podobno kot upravna enota, ki izda osebno izkaznico). Digitalno potrdilo je, poenostavljeno rečeno, datoteka, v kateri je zapisano: • kdo je imetnik javnega ključa, • podatki o overitelju digitalnega potrdila, • javni ključ imetnika, • serijska številka digitalnega potrdila, • datum veljavnosti digitalnega potrdila in • elektronski podpis digitalnega potrdila, ki ga izdela overitelj – ta je dodan

digitalnemu potrdilu z namenom preprečevanja ponarejanja digitalnih potrdil. Naloge overitelja so: • Izdaja lastnega digitalnega potrdila. To je posebno digitalno potrdilo, ki ga

overitelj izdela sam zase – izda in podpiše ga sam sebi oziroma sam jamči za svojo identiteto. Imenujemo ga tudi korensko digitalno potrdilo overitelja.

• Izdajanje digitalnih potrdil. Potrdilo izda tako, da prej preveri identiteto bodočega imetnika (npr. tako, da preveri podatke s pomočjo osebnega dokumenta). Kako natančno oziroma s katerimi postopki preveri identiteto bodočega imetnika, zapiše v svoji politiki (politika overitelja).

• Vodenje registra preklicanih digitalnih potrdil. Če nekdo odtuji zasebni ključ imetnika, če imetnik ne želi več uporabljati digitalnega potrdila, v primeru prekinitve delovnega razmerja ipd., to javi overitelju in overitelj doda serijsko številko tega digitalnega potrdila v register preklicanih digitalnih potrdil. Na ta način lahko vsi uporabniki digitalnih potrdil, ki jih izdaja ta overitelj, v registru preverijo, ali je digitalno potrdilo še veljavno.



Za postopke izdajanja digitalnih potrdil ZEPEP v 31. členu določa, da mora overitelj s pomočjo uradnega osebnega dokumenta s fotografijo za fizične osebe ali z uradno potrjenimi dokumenti za pravne osebe zanesljivo ugotoviti identiteto in druge pomembne lastnosti osebe, ki zahteva potrdilo. Določba se smiselno navezuje na 4. tč. 2. čl., ki definira varen elektronski podpis kot elektronski podpis, ki izpolnjuje naslednje zahteve:

• da je povezan izključno s podpisnikom, • da je iz njega mogoče zanesljivo ugotoviti podpisnika, • da je ustvarjen s sredstvi za varno elektronsko podpisovanje, ki so

izključno pod podpisnikovim nadzorom, • da je povezan s podatki, na katere se nanaša, tako da je opazna vsaka

kasnejša sprememba teh podatkov ali povezave z njimi.

V Sloveniji je po zadnjih podatkih (informacijskadruzba.si) registriranih šest kvalificiranih overiteljev: • Ministrstvo za javno upravo (SIGEN-CA za fizične osebe in poslovne subjekte

ter SIGOV-CA za državne organe), • HALCOM informatika d.o.o. (HALCOM-CA), • AC NLB, • Pošta®CA (POŠTA CA), • MORS, Direktorat za obrambne zadeve, Urad za informatiko in komuniciranje,

SiMoD-CA-Root, • MORS, Direktorat za obrambne zadeve, Urad za informatiko in komuniciranje,

SiMoD-CA-Restricted.

Slika 25: Prikaz digitalnega potrdila v internetnem brkljalniku



4.6.4 Komunikacija odjemalec strežnik z uporabo dig italnih potrdil Pri elektronskem komuniciranju gre za komunikacijo med odjemalcem in strežnikom v javnem omrežju (internet), kjer potrebno poskrbeti za primerno identifikacijo uporabnikov in za mehanizme varovanja identitete in komunikacije, da ne pride do zlorab povezanih z napačno, ukradeno ali zamenjano identiteto uporabnikov. Najbolj pogost način komunikacije je z uporabo varnih protokolov, npr. SSL (ang. Secure Socket Layer), kjer se za identifikacijo uporabnikov in opreme (npr. strežnikov) uporabljajo kvalificirana digitalna potrdila. Z namestitvijo kvalificiranega digitalnega potrdila so izpolnjeni osnovni pogoji, da lahko uporabnika identificiramo in avtenticiramo, lahko pa tudi elektronsko podpišemo dokumente in sporočila. Uporabljeni varni protokol določa način identifikacije in določitev nivoja varnosti komunikacije.

Slika 26: Varna komunikacija med odjemalci in strežniki v sistemu

4.6.5 SSL – Secure Socket Layer SSL je okrajšava za Secure Sockets Layer. Skupaj s TLS-jem (Transport Layer Security), ki je naslednik SSL-ja zagotavlja varno komunikacijo po medmrežju, na primer med bančnim strežnikom in uporabnikom. Med SSL-jem in TLS-jem obstajajo nekatere razlike, vendar so osnovni principi delovanja enaki. SSL je Netscape predstavil leta 1994, zastavili pa so si naslednje cilje:

• varnost in zasebnost povezave, • odprtost (lahko so ga začeli uporabljati vsi razvijalci spletnih aplikacij), • možnost povečanja varnosti z novimi, boljšimi algoritm.

Netscape je zadano nalogo opravil tako dobro, da je SSL postal standard. Komunikacija v SSL-u poteka tako, da uporabnikov brskalnik pošlje zahtevo za spletno stran z varovanim prenosom SSL (ali TLS). Strežnik se predstavi z javnim ključem. Ta proces uporablja enkripcijo z javnim ključem in digitalnim potrdilom. Tako strežnik potrdi, da je, kar trdi, da je. Ko se strežnik predstavi, brskalnik ustvari ključ za enkripcijo s simetričnim ključem, ga zakodira s strežnikovim javnim (public) ključem in mu ga pošlje. Strežnik prejme ključ, ga dekodira s privatnim ključem. Od tu naprej poteka povezava prek veliko hitrejše enkripcije. To je enkripcija s



simetričnim ključem. Je bistveno hitrejša za kodiranje in dekodiranje podatkov, hitro pa lahko tudi odkrije, če so bili podatki med prenosom spremenjeni. Strežnik včasih zahteva tudi uporabnikovo predstavitev. Ta se (podobno kot strežnik) predstavi z digitalnim potrdilom / certifikatom. HTTPS - Hypertext Transfer Protocol Secure je varnejša različica HTTP standarda in se uporablja za elektronsko poslovanje in druge transakcije, kjer se prenašajo občutljivi osebni podatki. Uporablja SSL ali TLS za kodiranje in s tem zaščiti promet pred vmesnimi opazovalci, ki bi drugače lahko videli vsebino prenosa. Ta komunikacijski protokol navadno uporablja vrata številka 443. SSL, ki je bil narejen za HTTP in je posebno primeren, saj omogoča zavarovanje tudi takrat, kadar prihaja informacija za kodiranje samo s strani strežnika.



5 KRITIČNA ANALIZA 5.1 KLJUČNI DEJAVNIKI USPEHA Tehnologija

Prednosti: • enostavno dodajanje novih storitev, • ločenost podatkovnih predmetov od mehanizma za branje in

shranjevanje, • branje po potrebi, • prenosljivost med zbirkami podatkov, • nadgradljivost, • hitrost delovanja.

Slabosti: • zahteva veliko znanja, • možnost vdorov v sistem, • zagotavljanje 24/7 način delovanja.

IT Infrastruktura

Prednosti: Do spletne aplikacije tako lahko dostopajo vsi uporabniki svetovnega spleta. Nadgradnja aplikacije, se lahko naredi na enem mestu in je sprememba vidna psi vseh uporbanikih. Slabosti: Možnost vdora in posledično razkritje občutljivih medicinskih informacij.



5.2 ANALIZA SWOT Analiza SWOT omogoča prepoznavanje prednosti, slabosti, morebitnih priložnosti in nevarnosti. Analiza SWOT omogoča menedžmentu, da se osredotoči na ključne kompetence in področja, kjer je podjetje močno. Analiza SWOT vsebuje:

• prednosti (strength), • slabosti (weakness), • priložnosti (opportunities), • nevarnosti (threats).

Prednosti

• hitrejše naročanje na zdravniški pregled, • kvalitetnejše delo zdravstvenega osebja, • krajše čakalne dobe, • enostavna uporaba, • preprost in učinkovit vmesnik.

Slabosti:

• morebitne slabosti se bodo pokazale v procesu implementacije same rešitve.

Priložnosti:

• delamo stvari, ki jih do sedaj nismo mogli, • povezovanje z drugimi zdravstvenimi informacijskimi sistemi.

Nevarnosti:

• vdor nepooblaščenih oseb, • zagotavljanje varnosti osebnih podatkov, • vdori črvov, • občutljivost zdravstvene dokumentacije.



6 ZAKLJU ČKI IN PREDLOGI ZA NADALJNJE DELO Spletna aplikacija ePacient prinaša številne prednosti tako za uporabnike zdravstvenih storitev kot tudi za zdravstveno osebje, hkrati zmanjšuje potrebo po iskanju najrazličnejših dokumentov ter pošiljanju vabil in izvidov po pošti in s tem znižuje stroške poslovanja zdravstvene ustanove. Eden glavnih namenov storitve je tudi nadzorovana, varna, zanesljiva in pravno formalna dostava dokumentov tako k osebnim zdravnikom in specialistom ali v bolnišnico kakor od vseh naštetih nazaj k pacientu. Drug cilj pa je pravno formalno hranjenje dokumentov v ustreznem arhivu. Spletna aplikacija ePacient je namenjena vsem potencialnim uporabnikom zdravstvenih storitev – se pravi vsem državljanom, ki so oziroma bodo potrebovali ustrezno oskrbo v primeru kakršnihkoli zdravstvenih težav. ePacient kot spletna storitev v prihodnosti predstavlja platformo, na podlagi katere bomo ponudili popolnoma nove storitve, ki jih danes še ni moč ponuditi:

• obveščanje pacientov s popolnimi izvidi - trenutno so možni le delni, saj nam zakon več ne dopušča (Zakon o varovanju podatkov),

• možnost, da zdravnik pošlje napotnico v elektronski obliki v ustrezno specialistično ambulanto druge zdravstvene ustanove. Pacient bo v takem primeru preko spletne aplikacije sprejel ali zavrnil predlagan termin obiska. V primeru zavrnitve se bo bolniku predlagal nov termin. Vsi pretekli obiski in zdravstvene informacije bodo bolniku vedno na voljo preko portala ePacient,

• izmenjava izvidov med specialistom in osebnim zdravnikom (npr.: ob odpustu iz bolnišnice specialist s pomočjo ePacienta posreduje odpustno pismo neposredno osebnemu zdravniku),

• inteligentne čakalne vrste - viden čas čakanja pri določenih zdravnikih, tako da se bo pacient sam lahko prijavil v vrsto ali tja, kjer je kdo termin preklical.

Na ePacientu bi lahko tako dobili, npr. seznam zadnjih 20 zdravil, ki so mu jih predpisali zdravniki oziroma izdali v lekarni, laboratorijske izvide, informacije o cepljenjih in morebitnih alergijah itd.



LITERATURA IN VIRI

• Vladislav, R. (2008). Zapiski predavanj: Baze podatkov. Fakulteta za organizacijske vede.

• Garland, J., Anthony R.(2003). Large Scale Software Architecture, A practical guide using UML, Indianapolis, Wiley publishing, Inc.

• Gril, M. (2003). Diplomsko delo, Varnost in tehnološka zaščita informacijskega sistema v bankah, Ljubljana.

• Podlipnik, D. (2003). Analiza uporabnosti spletnih uporabniških vmesnikov v elektronskem bančništvu in predlogi za njihovo nadgradnjo, Magistrsko delo, Ljubljana.

• Devet ključnih »Malenkosti« varovanja osebnih podatkov, dosegljivo na: http://www.sistem-on.net/40573/praksa/devet-kljucnih-malenkosti--varovanja-osebnih-podatkov/ ( 20.9.2010).

• Trije zakoni, ki jih mora poznati vsak informatik, dosegljivo na: http://www.sistem-on.net/41400/praksa/trije-zakoni-ki-jih-mora-poznati-vsak-informatik/ (20.9.2010).

• Kako do pravih podatkov, dosegljivo na: http://www.sistem-on.net/si/_detajl/?id=40808 (20.9.2010).

• Zakon o varstvu osebnih podatkov (2005). ZVOP-1, Ur. l. RS, št. 86/2004, 113/2005, dostopno na: http://zakonodaja.gov.si/rpsi/r03/predpis_ZAKO1973.html, (05.01.2011).

• Schung, S.H., eHealth Interoperability in Europe. • Boone, K. (2006). IHE Workshop 2006 - IHE Patient Care Coordination

Education . • Harno, K. Current practice on data-exchange and plans for a national

network • Comer, E. D. (2005). Internetworking with TCP/IP, Vol 1. • Stroetmann, K. A., Spichtinger D., Stroetmann V. N. (2005). Interoperability

and Knowledge Management in Health – A European Perspective . • Standards for electronic interchange of clinical, financial and administrative

information among health care oriented computer system, dosegljivo na: www.hlz.org (20.9.2010).

• Healthcare Information Technology Standards Pane , dosegljivo na: http://www.ansi.org/standards_activities/standards_boards_panels/hisb/hitsp.aspx?menuid=3 (10.1.2011).

• Healthcare standards and HL7, dosegljivo na: http://www.hl7standards.com/ (10.1.2011).

• Models of Healthcare Delivery (Next Generation), dosegljivo na: http://www.nextgenmd.org/vol3-7/models_healthcare_delivery.html (10.1.2011).

• Thomas, E. (2004). Service Oriented Architecture: Field Guide to Integrating XML and Web Services. New Jersey : Prentice Hall.

• Marčun, T., Rančić, V. in Velkaverh, B., Storitvena arhitektura vstopne točke zdravstvenega zavarovanja, dostopno na: http://www-05.ibm.com/si/ibmforum/pdf/day_2/IBMForum2010_Online3.pdf (10.1.2011).

• Johnson, R., Hoeller, J.(2004) Expert One-on-One J2EE Development without EJB, Wiley Publishing, Inc., Indianapolis, Indiana.



• Bernik, M., Florjančič J., Rajkovič V.(2002). Upravljanje z znanjem in uporaba informacijskih tehnologij, Moderna organizacija, str. 473-477.

• Brezavšček, A. (2009). Zapiski predavanj: Zanesljivost in varnost informacijskih sistemov. Fakulteta za organizacijske vede Kranj.

• CSS Tutorial dosegljivo na: http://www.w3schools.com/css/ (20. 1. 2011). • Gričar, J. (2009). Zapiski predavanj: Poslovni informacijski sistemi. Fakulteta

za organizacijske vede Kranj. • Milanič, S.: Kako izkoristiti infrastrukture javnih ključev v poslovanju

dosegljivo na: www.astec.si/slo/files/08_Milanic_Kako_izkoristiti.pdf (maj 2009).

• Nash, A., Duane, W., Joseph, C., Brink, D. (2001) PKI: Implementing and Managing E-Security, Brandon A. Nordin, USA.

• Lah, P. (2000). Kako dolgi morajo biti ključi za dovolj varno šifriranje podatkov?, dosegljivo na : http://www.sigov.si/tecaj/kripto/dolz-klj.htm (19.1.2011).

• L@b-IS, Popolna rešitev za vaš laboratorij, dosegljivo na: http://www.fin-pro.si/ (09.01.2011).

• XML, Wikipedija, dosegljivo na: http://sl.wikipedia.org/wiki/XML (12.10.2010) • Marko Štrukelj (November 2004), Hibernate, Monitor, dosegljivo na

http://www.monitor.si/clanek/hibernate/ (12.10.2010). • Interna dokumentacija, MedGateway (2011), Src Infonet d.o.o. • Bajželj, M. (2011). E-naročanje laboratorijske napotnice in izvida, diplomsko

delo, Univerza v Mariboru, Fakulteta za organizacijske vede. • Marjetič, J. (2003). Razvoj aktivnih spletnih strani za potrebe podjetja Elprof

d.o.o.,diplomsko delo, Univerza v Ljubljani, Ekonomska fakulteta. • Avelpo d.o.o., Kaj je HTTPS, dosegljivo na:

http://www.avelpo.si/index.php?option=com_content&task=view&id=43 (5.1.2011).

• Izdelava spletnih strani, dosegljivo na: http://izdelava-spletnih-strani-1a.blogspot.com/2009/11/kaj-je-css-in-zakaj-se-uporablja.html (5.1.2011).

• Bride, W. M.(1995). Barvna harmonija 2: priročnik za ustvarjanje kreativniih barvnih kombinacij, SOFT project, Ljubljana, str 160.

• Jennifer, S., 02Website 101 - improve your web pages by following these ten easy steps!, dosegljivo na: http://www.write101.com/101web.htm] (5.1.2011).

• Rolih, R., Kako privabiti potencialne kupce na spletno stran? (2. del), dosegljivo na: http://www.uspeh.com/index.php?mid=01&s=uim004&d=31 (5.1.2011).

• Skrt R., Plačevanje s plačilnimi karticami v spletni trgovini, dosegljivo na: http://www.nasvet.com/doc/placilne.php] (5.1.2011).

• Skrt, R. (2002). Vpis strani v iskalnike in imenike. Moj Mikro, Ljubljana, 9, str. 62-64.

• Skrt, R. (2002). Vsebina po meri uporabnika. Moj Mikro, Ljubljana, 9, str. 64-65.



KAZALO SLIK Slika 1: Prototipno razvijanje (Benedik, 2009) .......................................................... 7 Slika 2: Koncept spletne rešitve................................................................................ 9 Slika 3: Spletno naročanje na pregled A0 ............................................................... 11 Slika 4: Naročanje na pregled A2 ........................................................................... 12 Slika 5: Potrjevanje naročila A3 .............................................................................. 13 Slika 6: Logična shema ideje povezanega sistema ................................................ 14 Slika 7: Struktura dokumenta HL7 .......................................................................... 16 Slika 8: Primer oblik zgradbe modela CSS ............................................................. 18 Slika 9: Vstopna stran ............................................................................................ 20 Slika 10: Pozabljeno geslo ..................................................................................... 21 Slika 11: Registracija uporabnika ........................................................................... 22 Slika 12: Obvestilo o aktivaciji registracije .............................................................. 23 Slika 13: Naročilo na pregled 1/3 ............................................................................ 24 Slika 14:

Documents

SPLETNO NARO ČANJE PACIENTOVnivojih zdravstvenega varstva. () 1.3 PREDPOSTAVKE IN OMEJITVE Pri izdelavi spletne aplikacije ePacient, ki je predmet diplomske naloge, smo se soo čali