Zbornik predavanj, 7. izobraževalni dan programa ZORA – ZORA 2017 54 Uvod Prenova informacijskega sistema DP ZORA (IS DP ZORA) se je pričela že decembra 2015, ko mi je di- rektor Maranda Tomaž Gornik dal nalogo, naj se vključim v projekt. Prvotni namen projekta je bila tehnološka preno- va, ki naj bi vključevala predvsem spremembo v načinu hranjenja kliničnih podatkov s prehodom na platformo openEHR. Navodilo direktorja, ki sem ga dobil, pa je vodilo v drugačen način razmišljanja in drugačne cilje projekta. Ko sem se jeseni leta 2015 pridružil Marandu, sem bil vključen v razmišljanja, kako presejalne progra- me in registre izgraditi na drugačen način, kot se je to delalo v preteklosti. Rešitve za posameznega naročnika so se izdelovale v obliki t. i. aplikacij, čr- nih škatel, narejenih po specifikacijah naročnika. Tovrstne rešitve imajo mnogo pomanjkljivosti in Koncept in tehnične rešitve prenove informacijskega sistema DP ZORA Miklavž Muster Marand d. o. o., Koprska ulica 100, Ljubljana Povzetek Kljub temu da je bil projekt prenove presejalnega programa za zgodnje odkrivanje predrakavih sprememb materničnega vratu in raka ZORA (DP ZORA) v začetku namenjen tehnični prenovi apli- kacije, se je celotna projektna skupina kmalu poenotila, da ima smisel samo celovita prenova, ki bo postavila temelje za možnosti nadaljnjega razvoja politik presejalnega programa in bo obenem tvorila tako robustno kot tudi prilagodljivo platformo, ki bo uporabniku omogočila, da bo vsebinske nadgradnje in prilagoditve izvajal čim bolj samostojno. Z vidika dobavitelja (Marand d. o. o.) je projekt zaradi obsega problematike in vsebinskih izzivov zahteval uvajanje novih tehnologij in metodologij razvoja. Tehnologija, ki temelji na procesnih plat- formah, odprtokodnih rešitvah in možnosti spletnega povezovanja, nam je ponujala konceptualne rešitve, ki vse deležnike poveže v celoto, kar zagotavlja izvajanje procesov v skladu s pričakovanji. V celoto izvajanja presejalnega procesa smo povezali ginekologe in laboratorije, jim ponudili in- formacijske rešitve po njihovi meri in DP ZORA umestili kot skrbnika in upravljavca, ki bo skrbel za nemoteno delovanje sistema in z njegovimi nastavitvami skrbel za doseganje zastavljenih ciljev. Projekt je pomenil vsebinski izziv za naročnika in tehnološki izziv za dobavitelja, naše primarno vo- dilo pa je bilo zagotoviti učinkovit sistem, ki bo omogočil doseganje ciljev presejalnega programa in bo obenem predstavljal informacijsko podporo vsem deležnikom, da bodo izvajali postopke in procese v skladu s predpisanimi politikami in smernicami. To pomeni doseganje maksimalne koristi za posamezno žensko v presejalnem programu in izogibanje nepotrebnim in škodljivim posegom, ki bi lahko ogrožali njeno zdravje. Ključne besede: informacijski sistem DP ZORA, procesna platforma, odprtokodne rešitve, spletno povezovanje, robustnost, prilagodljivost, samostojnost upravljavca zahtevajo veliko prilagajanja in dopolnjevanja, ki ga vedno izvaja dobavitelj aplikacije. Takšen odnos dolgoročno vodi v rešitev, ki postaja s časom vse manj transparenta in razumljiva, in že redno vzdrževanje zahteva veliko dela in naporov. Običajno dosežejo kritično točko možnosti vzdrže- vanja in dograditev novih funkcionalnosti v 5 do 10 letih. Takrat se ponovno opravi analiza odmikov obstoječih funkcionalnosti od želenega stanja, pri- pravijo se nove specifikacije in zgodba se prične od začetka. Nova spoznanja na področju izgradnje informa- cijskih rešitev temeljijo na drugačnih pristopih, ki zahtevajo tudi drugačna znanja in metodologije. Izgrajena rešitev mora biti prilagodljiva, učinkovita in zadovoljiti mora vse obstoječe funkcionalnosti ter pustiti odprta vrata pričakovanim (in nepriča- kovanim) spremembam. Zbornik predavanj, 7. izobraževalni dan programa ZORA – ZORA 2017 55 Sodobne tehnologije vse bolj v ospredje postavlja- jo izgradnjo rešitev, ki temelji na metodologiji upo- rabe posameznih gradnikov. Takšen modularen pristop, v katerem zna vsak gradnik učinkovito po- skrbeti za posamezno opravilo, je zelo fleksibilen, enostaven za izgradnjo, s seboj pa nosi tudi nekaj tehnoloških in vsebinskih pasti. Da bi se izognili preohlapni rešitvi, smo v Maran- du začeli iskati rešitev v arhitekturi, ki bi zagotovila pričakovano fleksibilnost, obenem pa zagotovila ustrezno robustnost in varnost. Poleg izgradnje rešitve kot platforme sta nas na tem projektu čakali še dve nalogi. Izpolnitev le-teh zagotavlja, da bo uporabnik dobil rešitev v priča- kovanem obsegu in kvaliteti ter tudi v ustreznem času in za dogovorjeno ceno. Za dosego prvega cilja smo popolnoma prenovili način pisanja specifikacij, in sicer tako, da posta- nejo čim enostavnejše za branje in razumevanje s strani uporabnika in hkrati zagotovijo ustrezen prenos informacij v postopek izgradnje rešitve. Za doseganje rokov in rezultatov smo načinu dela prilagodili tudi projektno vodenje, ki podpira iz- gradnjo modularne rešitve in obenem zagotavlja sprotno dobavo in vključenost uporabnika v celo- tnem ciklu razvoja rešitve. Za prenovo informacijskega sistema DP ZORA je bila definirana projektna skupina, zadolžena za vsebinske sklope prenove, v katero je člane imeno- val DP ZORA. Ekipa Maranda je zagotavljala ustre- zna znanja na področjih, ki jih je prenovljena reši- tev zahtevala. Občasno je skupina vključevala tudi druge strokovnjake tako s vsebinskega kot tudi tehnološkega področja, da bi pridobila dodatne in- formacije, preverila koncepte in rešitve ter seznani- la deležnike presejalnega programa s pričakovanji in zahtevami nove rešitve. Poslovna analiza Kljub temu da smo v začetku razumeli projekt pre- nove kot tehnološki projekt, smo hitro vzpostavili sodelovanje na nivoju, ki je presegalo samo teh- nološki vidik, ampak smo se posvetili predvsem poslovni problematiki. Zato se ta faza ni končala s funkcionalnimi specifikacijami, ki opisujejo, kako bo rešitev delovala, ampak smo morali najprej napraviti poslovno analizo problematike, ki se je ukvarjala s problematiko, kaj bo nova rešitev zaje- mala in šele nato tudi kako bo rešitev izgledala. Zaradi spremenjenega načina dela rešitev ni pri- kazana v obliki, ki je že prilagojena dobavitelju, temveč je popolnoma generična. To naročniku omogoča, da po zaključku faze presoja predvide- no rešitev. Naročnik presojo izvaja v smeri pričako- vanih pozitivnih rezultatov, slabosti nove rešitve, priložnosti, ki jih prinaša, in nevarnosti za neuspeh (SWOT, PSPN analiza). Analize SWOT zaradi načina dela nismo formalizirali, smo pa v procesih analize posameznih segmentov nove rešitve obravnavali tudi te vidike, kot bo predstavljeno v nadaljevanju. Analizi delovanja informacijskega sistema DP ZORA smo se posvetili s treh vidikov. Obravnavali smo obstoječe stanje, odmike od želenega stanja in pomanjkljivosti v funkcionalnostih, obenem pa smo obravnavali tudi pričakovane spremembe v prihodnosti presejalnega programa. Izgradnja dokumentacije Dokumentacija, kot jo predvidevajo funkcijske spe- cifikacije, je relativno zahtevna, zato smo za potre- be poslovne analize uporabljali generična orodja (Word, orodje za risanje procesov in orodje za risa- nje ekranov). Dokumentacijo smo vsebinsko razdelili po sklopih, ki predstavljajo posamezne zaključene funkcio- nalnosti celotnega procesa presejanja. Poleg pro- cesov, ki so predmet poslovanja DP ZORA, smo v analizo vključili tudi procese delovanja drugih de- ležnikov, ki so vključeni v presejalni program, npr. ginekologe in laboratorije. Pri oblikovanju dokumentacije smo upoštevali me- todologijo razvoja rešitev, ki temelji na logiki po- slovnih procesov. Metodologija predvideva vrstni red postopkov, definiranih z gradniki poslovnega procesa, in predvideva naslednje faze analize po- slovnega procesa: • definicija delovnega toka (angl. flow, workflow), • definicija podatkov procesa, • definicija ekranskih vmesnikov, • definicija avtomatiziranih opravil, • integracija na zunanje sisteme, • dokončna definicija uporabniških vmesnikov (ki je nismo izvajali, ker je vezana na dobavitelja in se izvaja v delu definicije funkcionalnih spe- cifikacij) in • zagotovitev robustnosti sistema. Način dela in izdelki, ki izhajajo iz vsake posame- zne faze, so opisani v nadaljevanju. Metodologije nismo uporabljali kot osnove za naše delo, niti ni- smo upoštevali njenih omejitev (potrjevanje vsake faze), ker zaradi kompleksnosti celotnega procesa to ni bilo smiselno. Držali pa smo se njenih smernic za bolj konsistentno in organizirano delo. Zbornik predavanj, 7. izobraževalni dan programa ZORA – ZORA 2017 56 • Delovni tok Posamezne poslovne procese smo narisali in jih uporabljali kot osnovo za analizo, kako v resnici po- teka delo posameznega procesa, kdo so deležniki, ki v procesu sodelujejo, kaj so vhodi in izhodi in kaj je potrebno zagotoviti, da procesi potekajo nemo- teno. • Podatki procesa V naslednji fazi smo opredeljevali, katere podatke potrebujemo za delovanje posameznega procesa. Podatke, ki smo jih pridobili v fazi opisovanja posa- meznih nalog, smo razdelili tudi z vidika njihovega namena. Posamezne podatke smo tako opredelje- vali kot podatke, ki jih potrebujemo za izvajanje procesa DP ZORA, in podatke, ki jih moramo zbirati zaradi drugih deležnikov v procesu. V presejalnem programu nastane vrsta podatkov, ki so pomembni in jih je treba hraniti (klinični podatki izvidov), niso pa vsi ključni za izvajanje presejalnega programa (npr. z vidika citološkega izvida je za potrebe pro- cesov DP ZORA pomembna samo vodilna diagno- za). Podatke, ki smo jih v analizi opredelili, smo opisali v obliki logičnega podatkovnega modela, ki opisuje entitete (tabele, datoteke) in posamezne atribute teh entitet. V tej fazi analize bi se posameznikom tak pristop lahko zdel nekoliko kompliciran, vendar se je v naslednjih korakih analize to pokazalo kot potrebno in koristno. • Ekranski vmesniki Ko smo opredelili podatke in potek procesa, smo se pričeli ukvarjati z ekranskimi vmesniki v tistih fazah procesa, kjer proces vključuje nalogo, ki jo mora opraviti posameznik preko ekranskega vmesnika. V tej fazi analize se nismo omejevali z izgledom in er- gonomijo vmesnika. Fokus je bil na funkcionalnih zahtevah, podatkih, ki jih za posamezno opravilo potrebujemo, in na akcijah, ki jih izvaja posameznik za izvedbo posameznega opravila. • Avtomatizirana opravila Poleg človeških opravil se v procesih izvajajo tudi avtomatizirana opravila. Tudi za te je potrebno definirati, kaj in kako naj se izvede. V procesih DP ZORA je kar nekaj takšnih opravil, ki včasih pote- kajo popolnoma samostojno (vabljenje), včasih pa potekajo v sodelovanju s človeškimi opravili (usklajevanje postopkov z ginekologi in laborato- riji). • Integracija na zunanje sisteme Sistem DP ZORA ni zaprt sistem, ampak vključuje veliko deležnikov, s katerimi si izmenjuje podat- ke. Nekateri izmed deležnikov samo zagotavljajo podatke (centralni register prebivalstva - CRP , ...), drugi pa se preko svojih informacijskih sistemov aktivno vključujejo v IS DP ZORA (laboratorijski in ginekološki informacijski sistemi). Za vse takšne in- tegracije smo definirali potrebne informacije, ki se morajo izmenjevati za nemoteno delovanje posa- meznega procesa. Iz okolja lahko pridejo nepredvideni signali in sporočila, ki vplivajo na izvajanje posameznega procesa. Tudi takšne povezave so vključene v de- lovne tokove in omogočajo relativno enostavno sprejemanje sporočil iz drugih sistemov in proce- sov. • Robustnost procesov Robustnost procesov ima dva dela. Prvi se fokusi- ra na vsebinske zaplete, ki nastajajo pri izvajanju posameznih procesov, in je bil tudi predmet naše analize. Drugi del je vezan na možnosti napak, ki se dogajajo v informacijskih okoljih, in je izrazito teh- ničen, zato ga v tej fazi nismo obravnavali. Večino problematike robustnosti smo obravnavali z vidika neustreznega izvajanja posameznih člove- ških opravil. V fazah, kjer v procese vstopa človek, gre večkrat kaj narobe, kar vodi do tega, da naloga ni dokončana v dogovorjenem času ali pa sploh ni opravljena. V procesnem okolju takšne anomalije rešujemo z eskalacijami, kar pomeni, da se pričnejo vzporedni postopki ali procesi, ki zagotavljajo iz- vedbo posamezne naloge (obveščanje sodelavcev ali nadrejenih, določanje druge osebe za izvedbo itd.). Poleg navedenih dveh aktivnosti, ki jih izvajamo znotraj posameznega procesa, obstaja še en vidik zagotavljanja robustnosti: neodvisnost od dobavi- telja. V povezavi s posameznimi procesi smo obrav- navali dve področji iz omenjenega segmenta: o Visoka stopnja parametrizacije sistema. Kjerkoli je možno, smo namesto definicije posamezne vrednosti, ki vpliva na izvajanje postopkov in njenega zapisa v programsko kodo, definirali parametre, ki jih lahko uporabniki sami določa- jo. Na ta način lahko do neke mere zagotovimo prilagajanje sistema spremembam v okolju ali poslovni logiki. V isti segment spadajo tudi od- ločitvene tabele, ki vplivajo na izvajanje posa- meznih procesov. o Odpravljanje napak, ki se dogajajo v rednem delu, in aktivnosti, ki niso del rednih dogodkov Zbornik predavanj, 7. izobraževalni dan programa ZORA – ZORA 2017 57 v poslovnih procesih. Ta del je v začetku našega skupnega dela predstavljal veliko spremembo v razmišljanju uporabnikov, saj smo namesto tega, kako napako odpraviti s posegi v podatke in strukture, definirali pomožne procese, ki na kontroliran in avtoriziran način omogočajo, da se takšen popravek ali sprememba izvede. Vizualizacija rešitve Pretekle izkušnje so pokazale, da načini dela, ki omogočajo veliko mero vizualizacije, prinašajo tudi mnogo boljše rezultate. Dolga besedila z mnogo podrobnostmi zahtevajo velike vložke v pripravo in razumevanje ter vzdrževanje in spreminjanje zahtev in opisov rešitev. Enake zahteve kot smo jih postavili pred arhitek- turo: modularnost, fleksibilnost in nadgradljivost, smo postavili tudi kot izhodišče za analizo. V vsaki točki naše analize, kjer je bilo to smiselno, smo si pomagali z tremi vizualizacijami: • delovni tok procesov, • ekranski vmesniki in • logični podatkovni model. Kljub temu da so bili v projektni skupini ljudje, ki po izobrazbi niso informatiki, smo se skupaj nau- čili osnovnih gradnikov vseh treh vizualnih nivojev rešitve. Tak način je omogočal hitrejše in boljše ra- zumevanje predlagane rešitve, boljše razumevanje soodvisnosti procesov in obvladovanje podatkov preko podatkovnega modela, ki je v vsaki točki iskanja rešitev predstavljal vezivo posameznih gra- dnikov. Tak način dela nam je poleg lažjega in bolj struk- turiranega načina dela zagotovil tudi konsistentne izdelke, ki jih potrebujemo v naslednjih fazah pro- jekta in predstavljajo pripravo projektnega načrta, funkcijskih specifikacij in izgradnji rešitve. Izzivi v fazi analize V fazi analize smo se poleg običajnih vsebinskih zapletov okoli izvajanja poslovnih procesov in op- timizacije tega izvajanja srečali s štirimi velikimi izzivi: • smernice, • terjatve, • vključevanje laboratorijev in ginekologov v pre- sejalni proces, • definicija strukturiranih izvidov. • Smernice za celostno obravnavo žensk s pre- drakavimi spremembami materničnega vratu Vsaka ženska, ki je vključena v DP ZORA, je vključe- na v določen protokol izvajanja aktivnosti, ki se od nje in drugih deležnikov pričakujejo. Za zdrave ženske, ki so vključene v redno preseja- nje, naj bi se v določenih intervalih izvedel preven- tivni pregled. Obravnava je odvisna od tega, ali se ženska na novo vključuje v program ali pa že dlje časa izvaja protokol rednih pregledov v določenih časovnih intervalih. V primeru da rezultati pregleda odstopajo od pri- čakovanih vrednosti, ki vodijo v naslednji redni preventivni pregled, se ženska vključi v posto- pek kontrolnih pregledov z namenom potrditve suma oz. dodatne diagnostike za natančno do- ločitev statusa ženske. V takih primerih ženska ni več vključena v redno presejanje, ampak je za njeno obravnavo zadolžen izbrani ginekolog, ki po potrebi vključi tudi sekundarni in terciarni nivo obravnave. Ko smo se v fazi analize posvetili smernicam, smo ugotovili, da so smernice dober priročnik za usmer- janje ginekologov v nadaljnje postopke, vendar pa bi se jih dalo uporabiti tudi širše in njihov namen razširiti na dodatne funkcionalnosti, ki jih lahko tako pripravljene smernice zagotovijo. V fazi analize smo nenehno obravnavali posame- zne situacije, v katerih se lahko znajde ženska, ven- dar jih smernice ne pokrivajo, ter pričakovanja, da se bodo smernice prilagajale tako strokovnim zah- tevam kot tudi spremembam v politikah presejanja in nadzora. Poleg ohlapnih in neoprijemljivih definicij obstoje- čih smernic se je skozi postopek analize pojavljalo vedno več podobnih primerov, zato so se parcialne rešitve za posamezne probleme pokazale kot ne- primerne. Potrebovali smo celovito, robustno ter hkrati prilagodljivo platformo za obvladovanje ce- lovite rešitve. Pričeli smo razmišljati v smeri izgra- dnje visoko parametriranega sistema, ki je temeljil na odločitvenih tabelah, procesih in parametrira- nih tranzicijah znotraj procesa in med procesi. Ta nekonvencionalna vsebinska rešitev je zahtevala tudi inovativen pristop s strani informatike. Skozi več iteracij konceptov in preverjanj smo nazadnje prišli do rešitve, ki zagotavlja možnost definicije in izvajanja poljubnih procesov, ki so odvisni od spe- cifičnih dogodkov posamezne ženske. Rešitev temelji na pravilih, ki vedno predvidijo, kaj bo naslednja akcija, ki bo posledica dogodka, ki se Zbornik predavanj, 7. izobraževalni dan programa ZORA – ZORA 2017 58 je zgodil, in podatkov tega dogodka. Ko se kakr- šenkoli dogodek zgodi, se vedno preveri, ali je bil le-ta pričakovan in ali se je zgodil v pričakovanem časovnem okviru. Za dogodke, ki bi se morali zgo- diti, a se niso, prav tako predvidimo ukrepe. Princip, ki temelji na sistemu dogodkov, ki so se zgodili, in sistemu pričakovanj, smo definirali v obliki odločitvenih tabel, kar nam omogoča defi- nicijo parametrov, ki vplivajo na postopek in pro- cedure obravnave posamezne ženske. Definicija procesov in parametrov, ki vplivajo na delovanje celotnega sistema, je v celoti v rokah uporabnika. Tak princip nam je omogočil tudi definicijo proce- sov, ki sicer niso zajeti v smernicah. Postopki redne- ga presejanja so se lahko umestili v isti sistem. Prav tako smo lahko opredelili nekatere neobstoječe procedure v obliki procesov in jih s tem umestili v enoten sistem obvladovanja obravnave. • Terjatve V prejšnjem poglavju smo pojasnili, kako smo vse postopke, ki se izvajajo v celostni obravnavi ženske v vseh štirih fazah glede na DP ZORA (ženske, ki še niso vključene v proces, ženske, ki so vključene v redno presejanje, ženske, ki so v postopku obrav- nave, in ženske, ki so izločene iz sistema ZORA za- radi kakršnega koli razloga, npr. starosti, histerekto- mije, …), uspeli definirati kot procese in definirati tudi dogodke in parametre, ki vplivajo na njihovo obnašanje. Takoj se je zastavilo vprašanje, kako ukrepati v pri- merih odstopanj. Odstopanja so običajno nepri- čakovani dogodki (dogodki, ki so se zgodili izven predvidenih časovnih okvirov itd.) in neizvršeni do- godki, ko ne prejmemo nobenega izvida ali druge informacije v pričakovanem času. Za te primere smo definirali odločitvene tabele, s katerimi upravlja uporabnik, in odločajo, ali bomo dogodek ignorirali, ukrepali samo na nivoju obve- ščanja ginekologov (npr. ginekolog napačno ozna- čuje namen odvzema na citološkem izvidu, kar ima za posledico kontrolni izvid namesto rednega presejalnega in s tem nepredviden dogodek), ali pa bomo do ginekologa sprožili terjatev. Terjatev do ginekologa pomeni standardiziran vprašalnik, ki opredeljuje, kaj je bilo pričakovano in kakšno informacijo smo prejeli. Skladno s tem se prikažejo tudi opisi neskladij, ki ginekologu poma- gajo, da lažje analizira zakaj je do odstopanja prišlo. Ginekolog ima na vprašalniku možnost odgovora na terjatev, kjer strukturirano izbira med posame- znimi možnostmi. Ena od možnosti je, da preiskave ni bilo zaradi subjektivnih ali objektivnih razlogov, ki jih lahko ginekolog navede. Naslednja možnost je, da v sistemu manjka poseg (npr. kolposkopija), ki bi žensko usmerila v ustrezen proces, in bi bil potem izvid logičen itd. Odgovori se obravnavajo avtomatično, parametrizacija je ponovno rešena z odločitveno tabelo. Terjatve se lahko prožijo tudi na podlagi vprašal- nika, ki ga izpolni ženska ob prejemu vabila. Tak primer je odgovor na vprašalniku »Na pregled mi sedaj ni treba. Bris mi je bil odvzet dne xx.xx.xx«. Register DP ZORA izvida očitno ni prejel, zato prič- nemo s terjatvijo do ginekologa. • Vključevanje ginekologov in laboratorijev v presejalni proces Že v povezavi s terjatvami se odpira vprašanje, kako bo potekala dvosmerna interakcija z ginekologom, ki odgovarja na strukturiran vprašalnik. Takšnih vprašanj se nam je tekom projekta nabra- lo veliko: kako urediti elektronsko izmenjavo zah- tevkov, zahtevke za vzorce med laboratoriji, vnos strukturiranega izvida itd. Med analizo smo prišli do spoznanja, da obstaja veliko točk, kjer se v projekt vključuje delo gineko- logov in laboratorijev. Ugotovili smo, da ni realno upati, da bo celoten proces presejanja deloval, če vsem deležnikom ne zagotovimo ustrezne infra- strukture. Sodobne tehnologije, ki temeljijo na procesih, v polni meri izkoriščajo možnosti elektronskih po- vezav in ponujajo možnost izgradnje portalov, kjer se informacijski sistem DP ZORA lahko povezuje z zunanjimi deležniki. Za ginekologe smo predvideli portal, kjer gineko- log lahko pričenja svoje naloge (zahtevki za labora- torije, vnosi terminov za vabljenje, …), prejema do- ločene informacije, povezane s statusom ženske, in naloge, vsebuje pa tudi naloge, ki so povezane s presejalnim programom (terjatve). Posebej je treba poudariti cilj projekta, da se v vseh postopkih izdelajo procedure, ki minimizirajo na- pake, zahtevajo spremembe v načinu organizacije dela in elektronsko povezavo deležnikov. V priho- dnosti bo izvid, ki nastane kjerkoli v sistemu in na zahtevo kogarkoli, vedno posredovan tudi izbrane- mu ginekologu, vedno v elektronski obliki. Prav tako bo vsem deležnikom, ki imajo odprto zadevo do posamezne ženske, preko portala omo- Zbornik predavanj, 7. izobraževalni dan programa ZORA – ZORA 2017 59 gočen dostop do relevantnih predhodnih izvidov (tako ginekologom kot laboratorijem). • Strukturirani izvidi Projekt prenove informacijskega sistema DP ZORA zahteva tudi drugačen način hranjenja vseh klinič- nih podatkov. Platforma openEHR (angl. Electronic Health Records) omogoča hranjenje strukturiranih in standardiziranih kliničnih zapisov, zagotavlja varnost skladno z zakonskimi zahtevami in mo- žnost multidisciplinarnih analiz. V procesu presejalnega programa se izvaja veliko obdelav, ki temeljijo na podatkih iz izvida. Tudi to je eden od razlogov, da smo se morali spoprijeti z definicijami in opisi izvidov, ki danes niso v stan- dardizirani obliki. Pri tem kot osnovo uporabljamo mednarodne terminologije, ki pa se lahko dodatno razširijo zaradi posameznih specifičnih zahtev. Pri strukturiranih izvidih smo se v analizi soočali s tremi težavami: definicijo izvida, vnosom izvida in sinoptičnim izvidom. Definicijo izvida smo izvajali, oziroma še izvaja- mo, v več korakih. Prvi je, da v fazi analize okvirno strukturiramo izvid, kar opravimo s pomočjo stro- kovnjakov s specifičnega področja (laboratoriji, gi- nekologi, …). Iščemo tudi mednarodne standarde, ki najbolj ustrezajo potrebam. V drugem koraku strokovnjaki, ki so specialisti za strukture EHR v mednarodnih knjižnicah, poiščejo strukture, ki že obstajajo za obravnavano področje. Tako prido- bljene strukture ponovno obravnavamo znotraj delovnih skupin za posamezno področje, saj EHR strukture opredeljujejo najširši nabor podatkov za posamezno področje in je treba opredeliti, kaj v resnici potrebujemo in česa ne. Tako opredelje- na struktura predstavlja tudi vzorec za vnos izvida (ang. template), ki služi za izdelavo vnosne maske in vsebuje pravila, vezana na posamezen podatek in celotno strukturo zapisa. Vnos strukturiranega izvida se radikalno spremeni od vnosa nestrukturiranega ali delno strukturirane- ga izvida. Strukturiran izvid zahteva sistematično obravnavo vsakega zahtevanega podatka, kar po eni strani pomeni več »klikanja«, po drugi strani pa večjo zanesljivost, saj tak način preprečuje, da bi se kaj prezrlo ali pozabilo. Praksa pokaže, da tak način s časom postane rutinski, kar pomeni večjo zane- sljivost, manjšo obremenjenost in lažje uvajanje novih sodelavcev. Pri vnosu izvida smo morali upoštevati tudi tiste laboratorije, ki bodo svoje laboratorijske sisteme (LIS) prilagodili vnosu EHR. Za takšne laboratorije bomo po dokončni definiciji strukture in vsebine, ki jo bo definirala strokovna skupina, pripravili ra- čunalniško definicijo strukture in vsa pravila ter ši- frante, ki jih mora vnos upoštevati, da bi se lahko izvid zapisal v EHR. Izvid v strukturirani obliki je lahko kompleksen in vsebuje veliko podatkov, ki ne predstavljajo doda- ne vrednosti v informaciji za naročnika – ginekolo- ga. Zaradi boljše preglednosti se iz strukturiranih izvidov (ang. check list) lahko izdelajo sinoptični izvidi, ki predstavljajo poročilo o opravljenem iz- vidu v kar najbolj učinkoviti in razumljivi obliki. Za izdelavo sinoptičnega izvida je potrebno definirati njegov izgled in pravila njegove izdelave, kar po- novno terja sodelovanje in usklajevanje laboratori- jev in ginekologov. Potrjevanje koncepta V fazi poslovne analize smo definirali vrsto proce- sov, ki se izvajajo v procesu spremljanja posamezne ženske v IS DP ZORA v celotnem ciklusu obravnave. Po zaključku izdelave vseh procesnih specifikacij in definiciji arhitekture smo se odločili, da ponov- no preverimo, ali smo v tej fazi v resnici našli kon- ceptualno rešitev, ki bo omogočala celoten cikel obravnave ženske v vsaki možni situaciji in vklju- čevala vse deležnike, kot je bilo zamišljeno v fazi analize posameznega procesa. Izvedli smo dvodnevno delavnico na lokaciji, ki nam je omogočala, da smo se nemoteno in zbrano posvetili konceptu. Povabili smo tudi zunanje stro- kovne sodelavce in nekatere tehnične sodelavce s specifičnimi vedenji o obravnavani problematiki. Naloga skupine je bila, da v dveh dneh intenzivne- ga dela »zruši« koncept z vidika pričakovanj rešitve, tehnoloških možnosti in pričakovanih sprememb v prihodnosti. Intenzivno smo se izmenjevali v vlo- gah tožilcev in advokatov in iskali slabosti in po- manjkljivosti. Po dveh dneh razčiščevanja, prepričevanja in do- kazovanja so projektna skupina in sponzorji potr- dili koncept zastavljene rešitve in rešitev označili kot tako, ki zagotavlja željene funkcionalnosti in je z vidika zasnove dovolj robustna in odprta, da bo omogočala prilagajanje prihajajočim spremem- bam brez večjih posegov dobavitelja, ampak samo z nastavitvami in parametrizacijo sistema. Zaključek Projekt prenove informacijskega sistema DP ZORA se je iz začetnega relativno tehničnega projekta Zbornik predavanj, 7. izobraževalni dan programa ZORA – ZORA 2017 60 spremenil v projekt celovite vsebinske in tehno- loške prenove. Projektna skupina je po začetnem vzpostavljanju razumevanja, vzpostavljanja zaupa- nja in prenosa znanj v obe smeri kmalu prišla v fazo iskanja novih in svežih idej, preverjanja konceptov in iskanja najboljših rešitev. Ves čas smo pred seboj imeli skupen cilj: vzposta- viti sistem, ki bo omogočal, da bodo vsi deležniki v DP ZORA svoje delo opravili učinkovito, enostavno in usklajeno, in s tem zagotovili maksimalno korist vsaki posameznici in presejalnemu programu v ce- loti. Trenutno je projekt v fazi internega preverjanja po- sameznih komponent in vzpostavljanja arhitektu- re in računalniške infrastrukture, ki bo omogočila implementacijo koncepta rešitve in bo hkrati zago- tovila tudi vse nefunkcionalne zahteve po varnosti in konsistentnosti podatkov skladno z zakonodajo, sledenje posameznim dogodkom, podporo upo- rabnikom in podobno. Na drugi strani je pred projektom tudi nekaj od- prtih vsebinskih vprašanj, predvsem v povezavi s strukturiranimi in sinoptičnimi izvidi, kar bodo po- samezne delovne skupine še definirale tekom iz- gradnje projekta. Način izdelave, kot je predviden v projektnem planu, nam namreč dovoljuje nekaj fleksibilnosti na področju definicij, ki so opisane v poglavju o projektnem pristopu tega zbornika. Skupinsko analiziranje, izgrajena dokumentacija in potrditev koncepta sta s strani naročnika in doba- vitelja vzpostavila visoko mero razumevanja priča- kovane rešitve. DP ZORA ima vzpostavljena realna pričakovanja glede rešitve in načina njenega upra- vljanja in uporabe, ki je daleč od klasične aplikacije. Marand ima dobre specifikacije, ki opisujejo priča- kovano rešitev, kar nam bo omogočilo, da bo konč- ni izdelek skladen s pričakovanji. In zato se vsi veselimo nadaljevanja projekta, izgra- dnje rešitve in izzivov, ki nas na tej poti še čakajo.