Vzdrževanje centralnih komponent CRPP

TEHNIČNE SPECIFIKACIJE

Kazalo

Kazalo................................................................................................................. 1

Definicije, akronimi in kratice............................................................................. 3

Sklicevanja ......................................................................................................... 6

1. Opis sistema................................................................................................. 7

1.1 INTEROPERABILNA HRBTENICA .......................................................................... 7

1.2 IH ADAPTER ............................................................................................... 8

1.3 THINK!EHR REŠITEV ZA UPRAVLJANJE STRUKTURIRANIH PODATKOV............................... 8

1.4 REGISTER PACIENTOV IN PROSTORSKIH ENOT (RPPE).............................................. 8

1.5 UPRAVLJALEC KLINIČNEGA ZNANJA UKZ............................................................... 8

1.6 TERMINOLOŠKI STREŽNIK (TS) - HEALTHTERM ...................................................... 8

1.7 PREDPOSTAVKE IN ODVISNOSTI ......................................................................... 9

2. Predmet javnega naročila............................................................................. 9

2.1 IZDELKI .................................................................................................... 9

2.2 OBDOBJE, NA KATEREGA SE NANAŠA JAVNO NAROČILO ............................................ 10

3. Osnovno vzdrževanje ................................................................................. 10

3.1 NALOGE IZVAJALCA OSNOVNEGA VZDRŽEVANJA..................................................... 10

3.2 ZAHTEVE ZA IZVAJALCA OSNOVNEGA VZDRŽEVANJA................................................ 12

4. Dopolnilno vzdrževanje .............................................................................. 12

4.1 NALOGE IZVAJALCA DOPOLNILNEGA VZDRŽEVANJA ................................................. 12

4.2 ZAHTEVE ZA IZVAJALCA DOPOLNILNEGA VZDRŽEVANJA ............................................ 12

4.3 OBSEG DOPOLNILNEGA VZDRŽEVANJA................................................................ 13 4.3.1 Obseg del za dopolnilno vzdrževanje v času trajanja pogodbe...............................13 4.3.2 Predvidena vsebina dopolnilnega vzdrževanja ter informativna ocena obsega del po

vsebinskih sklopih .........................................................................................13 4.3.2.1 Spletna stran za spremljanje statusa komponent sistema..................................................14 4.3.2.2 Zagotovitev analitičnega orodja oz. dostopa do baze podatkov CRPP .................................14 4.3.2.3 Razširitev strukturiranega PPoP – statusni podatki pacienta ...............................................14 4.3.2.4 Razširitev izpisa PPoP – statusni podatki pacienta............................................................15 4.3.2.5 Nacionalna kontaktna točka (NCP) za izmenjavo PPoP ......................................................15 4.3.2.6 Preverjanje pooblastil uporabnika zVEM ..........................................................................16 4.3.2.7 Podpora avtentikacije SI-CAS ........................................................................................16 4.3.2.8 Prenos pooblastil v primeru nadomeščanja zdravstvenih delavcev (zdravnikov) ...................16 4.3.2.9 Diferencirana pooblastila za vpogled v strukturirane PPoP dokumente glede na uporabniške

pravice oz. uporabniško vlogo.......................................................................................16

2/31

4.3.2.10 Diferenciran izpis povzetka (Patient summary) glede na uporabniške pravice oz. uporabniško vlogo ..........................................................................................................................16

4.3.2.11 Diferencirana pooblastila za vpogled v posamezne dele strukturiranih dokumentov glede na uporabniške pravice oz. uporabniško vlogo......................................................................17

4.3.2.12 Dostop do podatkov na osnovi atributov (Attribute Based Access Control) ...........................17 4.3.2.13 Omejitve poizvedb po dokumentih eNaročanja.................................................................17 4.3.2.14 Omejitve pravic vnosa, spreminjanja in brisanje podatkov v CRPP – preverjanje uporabniških

pooblastil ....................................................................................................................17 4.3.2.15 Pregled aktivnih prepovedi vpogleda v PPoP (seznam IZD, za katere velja prepoved) ...........17 4.3.2.16 Obveščanje (alarmiranje) na določen tip dokumenta.........................................................17 4.3.2.17 Obveščanje (alarmiranje) na določen podatek v strukturiranem zapisu ...............................18 4.3.2.18 Dopolnitve pravil vpogleda v zdravstveno dokumentacijo – vpogled napotovalca..................18 4.3.2.19 Mehanizem obveščanja IOZ o novih dokumentih, ki jih je prejel pacient.............................18 4.3.2.20 Mehanizem obveščanja o novih dokumentih po različnih kriterijih (metapodatki dokumenta,

vsebina, pacientovi podatki) ..........................................................................................18 4.3.2.21 Vpeljava novega strukturiranega dokumenta ...................................................................18 4.3.2.22 Radiološki izvidi – povezava s sistemom Teleradiologija ....................................................19 4.3.2.23 Strukturiran laboratorijski izvid ......................................................................................19 4.3.2.24 Vzpostavitev registra ....................................................................................................19 4.3.2.25 Vpeljava osebnega zdravstvenega zapisa (PHR) ...............................................................20 4.3.2.26 Izobraževanje - delavnica OpenEHR .............................................................................20 4.3.2.27 Izobraževanje - delavnica Terminološki strežnik.............................................................20

5. Skupne zahteve.......................................................................................... 21

5.1 ZAHTEVE GLEDE RAZPOLOŽLJIVOSTI.................................................................. 21

5.2 ZAHTEVE GLEDE ZMOGLJIVOSTI (ODZIVNOSTI);.................................................... 21

5.3 ZAHTEVE GLEDE RAZŠIRLJIVOSTI (SKALABILNOSTI)................................................ 22

5.4 ZAHTEVE GLEDE ODZIVNEGA ČASA PRI REŠEVANJU ZAHTEVKOV .................................. 22 5.4.1 Napake oz. motnje v delovanju sistema ............................................................22 5.4.2 Odgovori na tehnična vprašanja.......................................................................23 5.4.3 Posodabljanje tehnične dokumentacije..............................................................23 5.4.4 Odzivni čas za dopolnilno vzdrževanje...............................................................23

5.5 ZAHTEVE GLEDE TESTIRANJA NADGRADENJ .......................................................... 23

5.6 ZAGOTAVLJANJE TESTNEGA OKOLJA .................................................................. 23

5.7 VODENJE IN OBVLADOVANJE SPREMEMB V PROGRAMSKIH REŠITVAH ............................. 24

5.8 PRAVILA ZA ODLAGANJE PROGRAMSKE KODE ........................................................ 24

5.9 OBVEŠČANJE O POSEGIH, NADGRADNJAH, SPREMEMBAH IN TEŽAVAH............................ 24

5.10 POSREDOVANJE INFORMACIJ, SVETOVANJE IN ODGOVARJANJE NA VPRAŠANJA .................. 24

5.11 TEHNIČNA DOKUMENTACIJA............................................................................ 25

5.12 ELEKTRONSKO PODPISOVANJE DOKUMENTOV........................................................ 25

5.13 UPORABA ORODJA REDMINE .......................................................................... 25

5.14 ZNAČILNOSTI IT OKOLJA............................................................................... 25 5.14.1 Licence in spletni brskalniki.............................................................................25 5.14.2 Skladnost z zakonodajo in upravljanje s podatkovnimi viri....................................25

6. Specifične zahteve za dopolnilno vzdrževanje ............................................ 27

3/31

6.1 PROCES NAROČILA IN IZVEDBE NALOG V OKVIRU DOPOLNILNEGA VZDRŽEVANJA ............... 27 6.1.1 Specifikacija zahtev .......................................................................................27 6.1.2 Tehnična specifikacija ....................................................................................27 6.1.3 Priprava ponudbe z oceno vrednosti in obsega del...............................................28 6.1.4 Potrditev ponudbe in naročilo ..........................................................................28 6.1.5 Izvedba del ..................................................................................................28 6.1.6 Zaključek izvedbe in prevzem izdelkov..............................................................28 6.1.7 Obvladovanje sprememb ................................................................................29

Priloga – ocene obsega del za dopolnilno vzdrževanje po vsebinskih sklopih... 30

Definicije, akronimi in kratice Izraz Pomen

Arhetip Osnovna oblika zapisa kliničnega ali demografskega podatka v medicinski informatiki.

CKM Clinical Knowledge Management (CKM), upravljanje kliničnega in demografskega znanja za razvoj, upravljanje in objavo kliničnih in demografskih virov znanja (Sistem/orodje za upravljanje kliničnega znanja z OpenEHR)

CRP Centralni register prebivalstva

Centralne komponente CRPP

Interoperabilna hrbtenica, IH adapter, Think!EHR rešitev za upravljanje strukturiranih podatkov, Register pacientov in prostorskih enot (RPPE), Upravljalec kliničnega znanja UKZ, Terminološki strežnik (TS) - HealthTerm

CRPP Centralni register podatkov o pacientu.

Opomba: V preteklosti poimenovan tudi EZZ

Deležniki eZdravja Izvajalci zdravstvene dejavnosti, pacienti, naročnik, zunanji izvajalci, upravičenci do podatkov iz podatkovnih zbirk eZdravja

DŠ Davčna številka; eden od identifikacijskih podatkov pacienta

EMŠO Enotna matična številka občana; eden od identifikacijskih podatkov pacienta

EZZ Elektronski zdravstveni zapis (Electronic Health Record – EHR): vir elektronsko vzdrževanih podatkov in informacij o zdravstveni obravnavi posameznika in odgovarjajoče orodje za menedžment zdravstvenih informacij.

Aktualno poimenovanje: CRPP

GURS Geodetska uprava republike Slovenije

HL7 Health Level 7 International - mednarodno standardizacijsko telo za interoperabilnost zdravstvene informatike (www.hl7.org)

HL7 CTS2 HL7 Common Terminology Services, release 2 – standard, ki

4/31

Izraz Pomen

določa storitve in funkcije, ki jih navzven ponujajo terminološki strežniki.

IH adapter Aplikacijski vmesnik, ki se uporablja za komunikacijo z IH, ki pa ne temelji na IHE profilih, saj je njegova naloga skrivanje kompleksnosti IHE.

IHE (ang. Integrating the Healthcare Enterprise) Iniciativa, katere cilj je izboljšati način izmenjave informacij med zdravstvenimi informacijskimi sistemi.

Interoperabilna hrbtenica (IH)

Osnovna informacijska infrastruktura za varno izmenjavo zdravstvenih podatkov, imenovana tudi IHE hrbtenica.

IOZ Izbrani osebni zdravnik

Izvajalec Izbrani ponudnik – pogodbeni partner naročnika

IZD Izvajalec zdravstvene dejavnosti

KTDP Klasifikacija terapevtskih in diagnostičnih posegov

http://www.nijz.si/sites/www.nijz.si/files/uploaded/ks_ktdp_verzija_6.pdf

Izpis PPoP Dokument pdf obliki, ki se generira na podlagi strukturiranih zapisov PPoP

KZZ Kartica zdravstvenega zavarovanja, ki jo izdaja ZZZS

KZZ številka Številka zdravstvenega zavarovanja; ZZZS številka

Lokalni (zaledni) informacijski sistem

Informacijski sistem, ki ga za obdelavo zdravstvene dokumentacije uporabljajo zdravstveni delavci pri izvajalcih zdravstvene dejavnosti.

MZ Ministrstvo za zdravje; lastnik rešitev eZdravja

Nadomestni zdravnik Zdravnik, ki nadomešča pacientovega izbranega osebnega zdravnika

Nastavljivi element Nastavljivi element rešitve. Primeri: šifranti, registri, URL-ji, matrika VZD

NIJZ Nacionalni inštitut za javno zdravje; upravitelj rešitev eZdravja

NCP National Contact Point - nacionalna kontaktna točka za čezmejno izmenjavo zdravstvenih podatkov

OpenEHR Metodologija v zdravstveni informatiki, ki opisuje upravljanje in shranjevanje, iskanje in izmenjavo zdravstvenih podatkov v elektronskih zdravstvenih zapisih.

Pisno, v pisni obliki Zapisano v sledljivi obliki, elektronsko ali v obliki papirne listine.

Običajno se pisna komunikacija vodi v elektronski obliki. Poleg izmenjave dokumentov je ustrezen tudi zapis v obliki elektronske pošte ali smiselna uporaba spletnih aplikacij (npr. Redmine).

5/31

Izraz Pomen

PPoP Povzetek podatkov o pacientu

Patient Summary Povzetek podatkov o pacientu (ang.)

RPPE Register pacientov in prostorskih enot: del CRPP, ki vsebuje podatek pridobljene iz uradnih evidenc CRP (ime, priimek, datum rojstva, prebivališče, družinska razmerjia… ), GURS (register prostorskih enot), ZZZS (podatki o izbranem osebnem zdravniku pacienta)

Rešitev Rešitev,. ki je predmet javnega naročila. Splošno poimenovanje, velja za katerokoli rešitev, ki je del CRPP.

Terminološki strežnik HealthTerm

Programski paket oz. rešitev, ki upravlja s terminološkim sistemom. V centralno strukturo CRPP je vključen terminološki strežnik HealthTerm proizvajalca Carecom.

(https://www.healthterm.com/about-carecom/)

Terminologija Celota izrazov določene stroke, panoge; strokovno izrazje, izrazoslovje. Sinonim za terminološko zbirko.

UKZ Upravljalec kliničnega znanja (ang. Clinical Knowledge Manager)

Varnostna shema Evidenca uporabnikov eZdravja, kjer se v povezavi z drugimi evidencami (ZZZS, RIZDDZ) definirajo uporabniške pravice

VZD Vrsta zdravstvene dejavnosti

http://www.nijz.si/sl/podatki/sifrant-vrst-zdravstvene-dejavnosti-vzd

VZS Vrsta zdravstvene storitve

http://www.nijz.si/sl/podatki/sifrant-vrst-zdravstvenih-storitev-vzs

zNET Zdravstveni NET - zdravstveno komunikacijska infrastruktura, ki vključuje postavitev centralne infrastrukture in priključitev vseh končnih točk v omrežje z ustrezno vzpostavljenimi organizacijskimi in varnostnimi politikami

RIZDDZ Register izvajalcev zdravstvene dejavnosti in delavcev v zdravstvu; poimenovan tudi baza podatkov o izvajalcih (BPI)

Zunanji izvajalec / sodelujoči partner

Dobavitelji drugih centralnega komponent eZdravja in dobavitelji lokalnih (zalednih) sistemov, ki se povezujejo s CRPP.

Poleg zunanjih izvajalcev/partnerjev, sodelujočih v času objave razpisa, so všteti tudi morebitni drugi, ki se bodo s CRPP na novo povezali v času trajanja pogodbe.

Zunanji sistem Druga centralna komponenta eZdravja (npr. eNaročanje, eRecept);

Lokalni (zaledni) informacijski sistem, ki se uporablja pri izvajalcu zdravstvene dejavnosti in se povezuje s CRPP

zVEM Portal za paciente, ki med drugim omogoča dostop do

6/31

Izraz Pomen

pacientovih dokumentov v CRPP.

ZZZS Zavod za zdravstveno zavarovanje Slovenije

ZZZS številka Številka zdravstvenega zavarovanja; 9 - mestna šifra navedena na kartici zdravstvenega zavarovanja. Poimenovana tudi KZZ številka (skrajšano KZZ); eden od identifikacijskih podatkov pacienta

Tabela 1: Seznam definicij, pojmov, akronimov in kratic

Sklicevanja • Methodological guidelines and recommendations for efficient and rationale

governance of patient registries, PARENT: http://patientregistries.eu/

• www.openehr.org

• http://ukz.ezdrav.si/ckm/OKM.html

• https://nio.gov.si/nio/asset/centralni+avtentikacijski+sistem+sicas

7/31

1. OPIS SISTEMA

Centralni register podatkov o pacientih (CRPP) predstavlja jedro nacionalnega elektronskega zdravstveno-informacijskega sistema (EZIS). Osnovni gradniki CRPP so sledeči:

• nacionalni zdravstveni informacijski model,

• jedro CRPP in storitev polnjenja, ažuriranja in vpogleda,

• elektronski dokumenti in standardna sporočila.

Osrednji del CRPP in osnovni gradniki so podprti z na IHE temelječo interoperabilno hrbtenico in na OpenEHR temelječo platformo za strukturirane podatke.

Nad osnovno infrastrukturo je omogočeno izmenjevanje elektronskih dokumentov in standardnih sporočil in vzpostavitev morebitnih novih registrov.

Vse omenjene rešitve so programske rešitve, ki predstavljajo infrastrukturo za podporo različnim procesom zdravstvenega sistema na nacionalni ravni.

Informacijska infrastruktura CRPP omogoča upravljanje podatkovne zbirke CRPP, kamor v skladu z Zakonom o zbirkah podatkov s področja zdravstvenega varstva (ZZPPZ) spadajo Povzetek podatkov o pacientih in zdravstvena dokumentacija. Izvajalcem zdravstvene dejavnosti je CRPP dostopen znotraj varnega zdravstvenega omrežja zNET. Pacienti lahko do svojih podatkov v CRPP dostopajo preko portala zVEM.

Slika 1: Arhitektura CRPP

1.1 INTEROPERABILNA HRBTENICA IHE interoperabilna hrbtenica Tiani Spirit je programska rešitev zgrajena z uporabo platforme Java. Podpira ključne infrastrukturne IHE profile, ki podpirajo izmenjavo zdravstvenih podatkov oz. dokumentov med različnimi organizacijami na nacionalnem

8/31

nivoju.

1.2 IH ADAPTER IH adapter je programska rešitev, ki je zasnovana kot vmesnik za dostop do Interoperabilne hrbtenice. Vključuje sistemske posebnosti slovenskega zdravstvenega sistema in omogoča enostavnejšo integracijo z zalednimi (lokalnimi) sistemi pri izvajalcih zdravstvene dejavnosti. Zagotavlja standardizirane in dokumentirane metode za operacije na sistemu.

1.3 THINK!EHR REŠITEV ZA UPRAVLJANJE STRUKTURIRANIH

PODATKOV S strukturiranimi OpenEHR podatki upravlja rešitev Think!EHR Platform. Poleg podpore OpenEHR metodologiji, je rešitev pripravljena tudi za umestitev v IHE okolje saj ustreza IHE profilom (IHE XDS).

OpenEHR strežniška rešitev Think!EHR Platform je bila vzpostavljena za uporabo na nacionalnem nivoju. Omogoča shranjevanje podatkov v strukturirani obliki. Poleg tega je omogočeno izvajanje modeliranja kliničnih vsebin po OpenEHR metodologiji.

Osrednji del rešitve predstavlja OpenEHR strežnik, ki vključuje OpenEHR bazo.

1.4 REGISTER PACIENTOV IN PROSTORSKIH ENOT (RPPE) Sestavni del CRPP je t.i. Register pacientov in prostorskih enot (RPPE). RPPE je register pacientov oz. oseb s stalnim ali začasnim prebivališčem v Republiki Sloveniji, ki črpa podatke iz zunanjih virov in se dnevno posodablja. Vir osnovnih demografskih in statusnih podatkov je Centralni register prebivalstva (CRP). Podatki o prebivališčih pacientov se pridobivajo iz Registra prostorskih enot (GURS). Vir podatkov o izbranih osebnih zdravnikih pacientov je ZZZS.

RPPE predstavlja centralni imenik pacientov in je med drugim osnova Povzetka podatkov o pacientu. Vsebuje osnovne identifikacijske in statusne podatke, kot jih opredeljuje Zakon o zbirkah podatkov s področja zdravstvenega varstva (ZZPPZ) v členu 14b. (1).

1.5 UPRAVLJALEC KLINIČNEGA ZNANJA UKZ Nacionalni zdravstveni informacijski model je podprt z metodologijo OpenEHR in ustrezno tehnologijo, ki omogoča upravljanje z OpenEHR modeliranega kliničnega znanja. Za ta namen je vzpostavljena rešitev Clinical Knowledge Manager (CKM) podjetja Ocean Informatics, ki je v okviru projekta eZdravje imenovan z Upravljalec kliničnega znanja (UKZ).

1.6 TERMINOLOŠKI STREŽNIK (TS) - HEALTHTERM Terminološki strežnik HealthTerm se uporablja za upravljanje različnih podatkovnih slovarjev, šifrantov in terminologij na nacionalnem nivoju. Terminološki strežnik HealthTerm omogoča upravljanje z različnimi terminologijami in omogoča na HL7 CTS2 standardu temelječ aplikacijski vmesnik.

9/31

Slika 2: Register pacientov in prostorskih enot (RPPE)

1.7 PREDPOSTAVKE IN ODVISNOSTI Informacijske rešitve so že vzpostavljene in zanje obstaja dokumentacija, ki dodatno opisuje njihove funkcionalne in nefunkcionalne lastnosti.

Rešitev je postavljena v okolju eZdravja. Naročnik zagotavlja strojno, mrežno opremo ter opremo za virtualizacijo strežnikov. Ostali gradniki za delovanje rešitve so del vzdrževanja rešitve.

2. PREDMET JAVNEGA NAROČILA

Predmet javnega naročila je: • osnovno in dopolnilno vzdrževanje rešitve Tiani Spirit IHE Interoperabilna

hrbtenica, kar vključuje tudi IH Adapter – vmesnika do Tiani Spirit rešitve, • osnovno in dopolnilno vzdrževanje rešitve Think!EHR Platform, • osnovno in dopolnilno vzdrževanje Registra pacientov in prostorskih enot RPPE • osnovno vzdrževanje rešitve Terminološki strežnik HealthTerm, • osnovno vzdrževanje rešitve UKZ - Clinical Knowledge Manager.

Pri tem je potrebno izpostaviti sledeče:

• za vse zgoraj navedene rešitve je potrebno zagotavljati redne nadgradnje; • licence za Oracle podatkovno bazo na katerih rešitve tečejo, ter vzdrževanje le

teh, zagotavlja naročnik; • naročnik ima v lasti neomejene licence za uporabo zgoraj navedenih rešitev; • rešitve predstavljajo ključne infrastrukturne elemente za podporo obstoječim in

bodočim rešitvam eZdravja; • za nobeno od rešitev naročnik nima izvorne kode.

2.1 IZDELKI

Izdelki, ki bodo realizirani z javnim naročilom in so odgovornost ponudnika:

• Izdelki vodenja in kakovosti

o redna poročila o aktivnostih osnovnega in dopolnilnega vzdrževanja; o zapisniki sestankov;

10/31

o redna poročila o zmogljivosti, zanesljivosti ter varnosti sistema in uporabljene tehnologije.

• Vsebinski in tehnični izdelki

o implementacija nadgradenj v okviru osnovnega in dopolnilnega vzdrževanja. Vse komponente programske opreme morajo vsebovati izvorno in izvršno kodo vseh modulov, obdelav in storitev v kolikor gre za samostojne izvršljive komponente, ki niso neposredno odvisne od programskih produktov za katere naročnik nima izvorne kode;

o Vzdrževanje obstoječe tehnične dokumentacije ter dokumentiranje sprememb in dopolnitev v okviru osnovnega in dopolnilnega vzdrževanja. Splošne zahteve za dokumentacijo so navedene v poglavju 5.11;

o analitični izdelki: poročila, statistike, analize napak in incidentov, predlogi za izboljšave.

2.2 OBDOBJE, NA KATEREGA SE NANAŠA JAVNO NAROČILO Javno naročilo se nanaša na obdobje treh let. Z izbranim ponudnikom (izvajalcem) bo naročnik sklenil pogodbo z veljavnostjo treh let.

3. OSNOVNO VZDRŽEVANJE

3.1 NALOGE IZVAJALCA OSNOVNEGA VZDRŽEVANJA Osnovno vzdrževanje informacijske rešitve zajema:

- zagotavljanje razpoložljivosti in zahtevane odzivnosti ter kakovosti izvajanja storitev vzdrževanja aplikativne programske opreme;

- zagotavljanje pravilnega delovanja aplikativne programske opreme; - redno izvajanje in spremljanje postopkov in procedur za polnjenje podatkov iz

zunanjih virov, kar vključuje tudi polnjenje terminologij; - vzdrževanje vseh programskih in drugih komponent sistema, ki so potrebne za

delovanje aplikativne programske opreme; - najpozneje do 6. delovnega dne v mesecu za pretekli mesec redno mesečno

poročanje o zahtevkih, obravnavanih v preteklem mesecu. To vključuje: o zahtevke za drugi nivo podpore, ki jih prijavlja prvi nivo podpore eZdravja; o zahtevke, ki jih prijavlja naročnik; o zahtevke, ki jih prijavljajo zunanji izvajalci;

Poročilo je potrebno obvezno priložiti mesečnemu računu za osnovno vzdrževanje in je pogoj za plačilo računa;

- najpozneje do 6. delovnega dne v mesecu za pretekli mesec redno mesečno poročanje statističnih podatkov za spremljanje uvajanja in uporabe CRPP najmanj v naslednjem obsegu:

o seznam izvajalcev s številom dokumentov po tipu dokumenta, za pretekli mesec in total;

o število dokumentov po tipu dokumenta, z ločenimi vmesnimi vsotami za dokumente eNaročanja, nestrukturirane dokumente (izvidi in odpustna pisma), in strukturirane dokumente (PPoP in drugi strukturirani dokumenti), za pretekli mesec in skupno (od začetka uporabe do vključno zadnjega dne preteklega meseca);

o število pacientov, ki so prejeli dokument, po tipu dokumenta, za pretekli mesec in skupno;

o število izvajalcev, ki so posredovali dokumente v CRPP, po tipu dokumenta, z ločenimi vmesnimi vsotami za dokumente eNaročanja, nestrukturirane dokumente (npr. izvidi in odpustna pisma), in strukturirane dokumente (PPoP in drugi strukturirani dokumenti), za pretekli mesec in skupno;

11/31

- na zahtevo naročnika posredovati druge podatke v zvezi s stanjem in uporabo CRPP, npr.:

o podatke o aktivnostih na CRPP za analizo napak in incidentov; o statistiko poizvedb po dokumentih; o statistične podatke za izbrana časovna obdobja (npr. za koledarsko leto);

- izvajanje postopkov posodobitve vse programske opreme in komponent sistema, potrebnih za pravilno in varno delovanje aplikativne programske opreme. To vključuje tudi posodobitve operacijskih sistemov na platformah, na katerih je nameščena aplikativna programska oprema;

- izvajanje postopkov izdelave in zagotavljanja varnostne kopije podatkov ter vzpostavitev ponovnega stanja delovanja (v kolikor je za ponovno delovanje potrebna uporaba varnostne kopije);

- vzdrževanje nastavljivih elementov rešitev, kot so šifranti, registri, enolični krajevni viri (URL-ji), dodajanje novih šifer VZD v obstoječo matriko dostopov;

- analiza možnih izboljšav ali optimizacij rešitev ter izdelava predlogov za optimizacijo za naročnika;

- reševanje napak pri delovanju v okviru predvidenega odzivnega časa; - sodelovanje z zunanjimi izvajalci pri iskanju možnih vzrokov za težave pri

delovanju; - sodelovanje in usklajevanje z zunanjimi izvajalci pri nadgradnji obstoječih rešitev; - sodelovanje in usklajevanje z zunanjimi izvajalci pri vključevanju novih rešitev; - proaktivno sodelovanje in usklajevanje z naročnikom pri spremembah, novostih,

nadgradnjah, reševanju težav in načrtovanju nadaljnjega razvoja; - priprava ponudb za dopolnilno vzdrževanje; - pomoč uporabnikom (drugi in tretji nivo podpore); - odkrivanje in odpravljanje skritih napak in pomanjkljivosti v kodi aplikativne

programske opreme; - spremljanje tehnoloških novosti, povezanih z vzdrževano programsko opremo ter

podajanje predlogov in izvedba ukrepov za nemoteno delovanje oz. izboljšanje njenega delovanja;

- oblikovanje in podajanje predlogov za optimizacijo delovanja informacijske rešitve;

- objava novih verzij in novonastale dokumentacije, ki so posledica odprave napak in pomanjkljivosti, v odložišču, ki ga opredeli naročnik;

- reševanje problemov ter predlaganje ukrepov za nemoteno delovanje aplikativne programske opreme;

- preverjanje delovanja aplikacije na različnih okoljih; - ažurno vzdrževanje dokumentacije sistema; - preverjanje pravilnosti in optimalnosti delovanja sistema; - intervencije v primeru anomalij, ki jih zazna sam ali jih sporoči naročnik oz.

uporabniki; - učinkovito pomoč in svetovanje ključnim uporabnikom na strani naročnika in

zunanjih izvajalcev; - redno spremljanje delovanja rešitev in poročanje naročniku; - izdelava rednih in izrednih poročil o delovanju rešitve; - obveščanje naročnika ob zaznanih težavah; - sodelovanje s prvim nivojem podpore naročnika pri reševanju incidentov; - obveščanje prvega nivoja podpore ob vseh spremembah, ki lahko vplivajo na

izvajanje prvega nivoja podpore; - nudenje višjih nivojev podpore; - Nadzor sistema:

o spremljanje in zbiranje dogodkov iz sistema; o periodično pregledovanje delovanja podatkovne zbirke; o stalno spremljanje delovanja podatkovnih virov integriranih z

informacijsko rešitvijo in ukrepanje v primeru morebitnih motenj; o tehnično usklajevanje s posameznimi podatkovnimi viri za zagotovitev

operativnega delovanja;

12/31

o predlogi ukrepov za preventivno reševanje; - Upravljanje razpoložljivosti, zmogljivosti in kapacitete sistema:

o spremljanje stanja in trendov sistema; o identificiranje kazalnikov oz. pokazateljev, preko katerih spremljamo,

da obratovanje ni ogroženo; o priprava predlogov in izvajanje ukrepov za zagotovitev zahtevane

razpoložljivosti, zmogljivosti in kapacitete (optimizacija); o koordinacija izvedbe ukrepov (obveščanje pristojnih oseb, posredovanje

dogodka v izvajanje ustreznim izvajalcem).

3.2 ZAHTEVE ZA IZVAJALCA OSNOVNEGA VZDRŽEVANJA Izvajalec mora v okviru osnovnega vzdrževanja izpolnjevati zahteve, opisane v poglavju 5 .

4. DOPOLNILNO VZDRŽEVANJE

4.1 NALOGE IZVAJALCA DOPOLNILNEGA VZDRŽEVANJA Dopolnilno vzdrževanje aplikativne programske opreme je podobno kot osnovno vzdrževanje vezano neposredno na aplikacijo oz. kodo in zajema izgradnjo novih funkcionalnosti aplikacije ter dopolnjevanje obstoječih funkcionalnosti aplikacije.

Dopolnilno vzdrževanje zajema:

- sodelovanje pri analizi in pripravi specifikacij uporabniških zahtev za dodajanje novih in izboljšanje obstoječih funkcionalnosti programske opreme;

- dopolnitve komponent rešitev zaradi nadgradnje obstoječih ali vključevanja novih rešitev;

- dopolnitve komponent rešitev zaradi optimizacije delovanja; - dopolnitev dokumentacije rešitev po izvedenih dopolnitvah; - izboljšanje obstoječih funkcionalnosti programske opreme, izboljševanje lastnosti

delovanja, uporabnosti in dograjevanje novih funkcionalnosti ter modulov na podlagi predlogov naročnika, uporabnika ali izvajalca in s strani naročnika potrjenih specifikacij;

- prilagajanje programske opreme glede na spremembe sistemskega okolja in operacijskega sistema v okviru možnosti in zagotovil proizvajalcev oziroma principalov ter glede na potrebe ostalih povezanih informacijskih sistemov;

- prilagajanje in dograjevanje programske opreme glede na vsebinske spremembe; - testiranje prilagoditev in nadgradenj programske opreme; - odlaganje novih verzij, ki so posledica dopolnilnega vzdrževanja, v odložišče

naročnika; - dokumentiranje novih verzij in funkcionalnosti, ki so rezultat dopolnilnega

vzdrževanja; - ostala dela po naročilu naročnika.

Dopolnilno vzdrževanje se izvede po predhodnem pisnem naročilu naročnika, ki je lahko tudi elektronska pošta. Če izvajalec izvede funkcionalnost brez naročila naročnika, nosi stroške izvedbe sam.

4.2 ZAHTEVE ZA IZVAJALCA DOPOLNILNEGA VZDRŽEVANJA

Izvajalec mora v okviru dopolnilnega vzdrževanja izpolnjevati skupne zahteve, opisane v poglavju 5 , ter specifične zahteve za dopolnilno vzdrževanje, opisane v poglavju 6.

13/31

4.3 OBSEG DOPOLNILNEGA VZDRŽEVANJA

Naročnik v času objave razpisa zaradi spremenljivih okoliščin ne more podati natančnega plana razvojnih aktivnosti, ki bi vključeval nove vsebine ter časovne roke. Obseg dopolnilnega vzdrževanja je zato določen pavšalno glede na trenutne plane, razpoložljive vire in predvidevanja naročnika.

Naročnikova ocena obsega del je osnova za oceno vrednosti javnega naročila in je navedena pod točko 4.3.1. Naročnikova ocena obsega del prestavlja fond razpoložljivih sredstev, v okviru katerih bo naročnik naročal nadgradnje z naslova dopolnilnega vzdrževanja.

Pod točko 4.3.2 so navedene razširitve in nove funkcionalnosti, ki jih naročnik predvideva v času objave javnega razpisa, pri čemer pa ne zagotavlja, da bo navedene funkcionalnosti tudi dejansko naročil.

Naročnik predvideva, da bodo poleg vsebin navedenih pod točko 4.3.2 naročene tudi druge vsebine, ki trenutno še niso opredeljene.

4.3.1 Obseg del za dopolnilno vzdrževanje v času trajanja pogodbe

Skupni obseg del v okviru dopolnilnega vzdrževanja v triletnem obdobju, za katerega se bo sklepala pogodba o vzdrževanju, znaša 4800 delovnih ur (človek/ur) oz. 600 delovnih dni (človek/dni).

Ponudnik naj v svoji ponudbi navede ceno dopolnilnega vzdrževanja za fiksen obseg, definiran v tej točki, torej za 4800 ur.

Obseg del, ki ga bo ponudnik ločeno ocenil glede na vsebine navedene pod točko 4.3.2 naj ponudnik odda kot prilogo k ponudbi, pri čemer ocenjena vrednost le-tega ne vpliva na vrednost oz. ceno dopolnilnega vzdrževanja iz prejšnjega odstavka.

4.3.2 Predvidena vsebina dopolnilnega vzdrževanja ter informativna ocena obsega del po vsebinskih sklopih

Za naslednje funkcionalnosti oz. vsebinske sklope naročnik od ponudnika pričakuje:

- oceno potrebnega dela oz. ocena obsega del (delovni dnevi; v enotah človek/dan) in

- oceno časovnega roka realizacije (število koledarskih dni, potrebnih za izvedbo, merjeno od naročila do zaključka izvedbe).

Ponudnik naj oceno obsega del in časovnih rokov odda kot prilogo k ponudbi, pri čemer naj poda ocene za vsako funkcionalnost oz. za vsak vsebinski sklop posebej. Ponudnik naj uporabi obrazec v prilogi.

V kolikor ponudnik ne bo oddal ocen oz. ne bo priložil Priloge – ocen obsega del za dopolnilno vzdrževanje po vsebinskih sklopih, se bo njegova vloga štela kot nepopolna.

Ponudnikova ocena del ni zavezujoča. V kolikor bodo vsebine dejansko naročene, bo ponudnik izdelal ponovno oceno na osnovi takrat aktualne naročnikove specifikacije.

Naročnik bo pridobljene ocene upošteval pri planiranju razvojnih nalog znotraj razpoložljivih virov ter pri določanju prioritet.

14/31

4.3.2.1 Spletna stran za spremljanje statusa komponent sistema

Izvajalec zagotovi spletno stran, na kateri se bodo spremljali statusi vseh komponent (Happy Page).

Razvidna mora biti tako povezljivost kot dostopnost vseh storitev.

Spletna stran mora biti dostopna naročniku in zunanjim izvajalcem.

4.3.2.2 Zagotovitev analitičnega orodja oz. dostopa do baze podatkov CRPP

Izvajalec naročniku zagotovi analitični vmesnik oz. orodje, s katerim bo naročnik lahko spremljal stanje sistema ter pridobival statistične podatke po različnih kriterijih. Analitični vmesnik mora med drugim zagotavljati vpogled v transakcije in dokumente za potrebe pridobivanja poslovnih informacij in podporo odločanju (Business Inteligence).

4.3.2.3 Razširitev strukturiranega PPoP – statusni podatki pacienta

Povzetek podatkov je potrebno razširiti tako, da bo vseboval tudi trenutno nepodprte podatke, ki jih opredeljuje Zakon o zbirkah podatkov s področja zdravstvenega varstva :

(ZZPPZ) v členu 14b. (1):

Podatki o pacientovem zdravstvenem pooblaščencu:

Strukturirani podatki: ZZZS številka pacientovega zdravstvenega pooblaščenca (v kolikor ga je pacient določil); en pacient ima lahko več pooblaščencev;

Nestrukturiran dokument (kopija pooblastila,pdf);

Vnaprejšnja zavrnitev zdravstvene oskrbe po pojasnilu:

Nestrukturiran dokument (kopija izjave , pdf);

Izključitev oseb, ki so po zakonu upravičene do odločanja o zdravstveni oskrbi:

Nestrukturiran dokument (obrazec, pdf);

Prepoved oziroma dovolitev seznanitve z zdravstveno dokumentacijo:–

Nestrukturiran dokument (obrazec, pdf).

Dokument

Obrazec Pravna podlaga Podpisniki

Vnaprejšnja zavrnitev zdravstvene oskrbe po pojasnilu

Vnaprejšnja zavrnitev zdravstvene oskrbe

34. čl Zakona o pravicah pacientov (ZPacP)

1. Zdravnik – ki pojasnjuje 2. Varuh pacientovih pravic 3. Pacient (3 podpisniki)

Izključitev oseb, ki so po zakonu upravičene do odločanja o zdravstveni oskrbi

Obrazec o izjavi o izključitvi oseb, ki so po zakonu upravičene odločati o zdravstveni oskrbi pacienta,

- 33. čl Zakona o pravicah pacientov (ZPacP) 9. člen Pravilnika o načinu določitve pacientovega zdravstvenega pooblaščenca in o izjavi vnaprej izražene volje

Pacient

15/31

Dokument

Obrazec Pravna podlaga Podpisniki

Prepoved oziroma dovolitev seznanitve z zdravstveno dokumentacijo – VOP-1

https://www.ip-rs.si/obrazci/pravice-pacientov/ (VOP – 1)

41. in 42. čl Zakona o pravicah pacientov (ZPacP) 10. člen Pravilnika o načinu določitve pacientovega zdravstvenega pooblaščenca in o izjavi vnaprej izražene volje

Pacient

Zdravstveni pooblaščenec - Pooblastilo

Obrazec pooblastila za določitev pacientovega zdravstvenega pooblaščenca (PZP

32. člen Zakona o pravicah pacientov (ZPacP)

Pacient (overjen podpis) in Zdravstveni pooblaščenec

Zdravstveni pooblaščenec – preklic oz. izbris pooblastila

Ni standardiziran 32. člen Zakona o pravicah pacientov (ZPacP)

Pooblastitelj (pacient) ali pooblaščenec

Tabela 2: Pooblastila in izjave volje pacienta

4.3.2.4 Razširitev izpisa PPoP – statusni podatki pacienta

Izpis povzetka podatkov o pacientu je potrebno razširiti tako, da bodo poleg zdravstvenih podatkov opisani tudi naslednji podatki:

- ZZZS številka, ime in priimek pacientovega zakonitega skrbnika (v kolikor je le-ta določen);

- podatek o tem, ali je pacient podal prepoved vpogleda v PPoP ter aktualni seznam IZD, za katere velja prepoved;

- podatek o tem, ali je pacient podal izjavo vnaprej izražene volje - vnaprejšnjo zavrnitev zdravstvene oskrbe po pojasnilu;

- podatek o tem, ali je pacient podal prepoved oziroma dovolitev seznanitve z zdravstveno dokumentacijo;

- Podatek o tem, ali je pacient podal izjavo o izključitvi oseb, ki so po zakonu upravičene do odločanja o zdravstveni oskrbi;

- ZZZS številka, ime in priimek pacientovega zdravstvenega pooblaščenca , v kolikor ga je pacient določil.

Alternativno se za lahko za zgoraj navedene podatke ločen dokument oz. nov tip dokumenta (povzetek statusnih podatkov).

4.3.2.5 Nacionalna kontaktna točka (NCP) za izmenjavo PPoP

Predvidena je vzpostavitev Nacionalne kontaktne točke, s katero bo potrebno integrirati CRPP za namen izmenjave PPoP oz. Patient Summary.

Osnovna izhodišča so opredeljena v smernicah EU:

http://ec.europa.eu/health//sites/health/files/ehealth/docs/guidelines_patient_summary_en.pdf.

Predvidene naloge za izvajalca:

- Prilagoditev nacionalnega PPoP v skladu z mednarodnimi standardi oz. generiranje mednarodno standardiziranega PPoP na osnovi nacionalnega PPoP. To vključuje izdelavo prevajalnih algoritmov in uvedbo morebitnih novih dokumentov;

16/31

- Vpeljava ločenega repozitorija za dokumente, ki bodo predmet čezmejne izmenjave;

- Vzpostavitev testnega okolja in sodelovanje pri testiranju.

4.3.2.6 Preverjanje pooblastil uporabnika zVEM

Ob poizvedbi uporabnika zVEM (pacienta, državljana) po dokumentih na CRPP je potrebno na podlagi podatkov v RPPE preveriti pooblastila oz. zakonitost vpogleda v podatke pacienta, ki ni poizvedujoči uporabnik. V kolikor uporabnik ne poizveduje zase oz. za svojo EMŠO ali ZZZS številko, je potrebno preveriti, ali je poizvedujoči v ustreznem razmerju do osebe, za katero poizveduje (torej ali je starš oz. zakoniti skrbnik).

Opomba: Tovrstno preverjanje se sicer izvaja na portalu zVEM. Dodatna poizvedba na CRPP je predvidena kot dodaten varnostni mehanizem.

4.3.2.7 Podpora avtentikacije SI-CAS

Predvideno je, da bodo uporabniki rešitev eZdravja uporabljali standardizirane avtentikacijske mehanizme na nacionalni oz. nadnacionalni ravni. Avtentikacija pacientov (državljanov), ki uporabljajo portal zVEM, bo preusmerjena na centralni sistem SI-CAS

(https://nio.gov.si/nio/asset/centralni+avtentikacijski+sistem+sicas).

Izvajalec bo moral podpreti avtentikacijo pacienta - državljana na podlagi žetona SAML v skladu s SI-CAS (SI-CAS SAML).

Poleg sprejema in validacije SI-CAS SAML bo potrebno ob vsaki poizvedbi portala zVEM na CRPP pridobivati ZZZS številko na osnovi EMŠO oz. DŠ. ZZZS številka namreč predvidoma ne bo vključena med standardne avtentikacijske atribute SI-CAS in jo bo potrebno zagotavljati na CRPP/RPPE.

Varnostna shema bo še naprej zagotavljala avtorizacijo uporabnikov rešitev eZdravja, zato bo poleg SI-CAS SAML potrebno vzporedno podpirati tudi obstoječi SAML Varnostne sheme za zdravstvene delavce oz. profesionalne uporabnike eZdravja.

4.3.2.8 Prenos pooblastil v primeru nadomeščanja zdravstvenih delavcev (zdravnikov)

V Varnostni shemi bo implementiran mehanizem nadomeščanja oz. začasni prenos pooblastil na nadomestnega zdravnika. To bo vključevalo tudi nabor VZD.

Na CRPP bo potrebno obravnavati razširjen SAML žeton in prilagoditi mehanizme preverjanja pripadnosti IOZ ter mehanizme dostopa do dokumentov.

4.3.2.9 Diferencirana pooblastila za vpogled v strukturirane PPoP dokumente glede na uporabniške pravice oz. uporabniško vlogo

Trenutno je vpogled v strukturiran PPoP omogočen vsem zdravstvenim delavcem tako, da so dostopni vsi vsebinski sklopi. Diferencirana pooblastila pomenijo, da uporabnik glede na svoje pravice oz. vlogo vidi zgolj nekatere vsebinske sklope/tipe dokumentov (npr. alergije in cepljenja), nekaterih pa ne (npr. bolezni in stanja).

4.3.2.10 Diferenciran izpis povzetka (Patient summary) glede na uporabniške pravice oz. uporabniško vlogo

Izpis (pdf) za nekatere uporabniške vloge oz. profile zdravstvenih delavcev prilagoditi tako, da so prikazani samo izbrani sklopi (npr. samo cepljenja in alergije).

17/31

4.3.2.11 Diferencirana pooblastila za vpogled v posamezne dele strukturiranih dokumentov glede na uporabniške pravice oz. uporabniško vlogo

Uporabnik vidi zgolj del posameznega vsebinskega sklopa/dokumenta.

Primer: uporabnik, ki dostopa do povzetka o zdravilih (CRPP_medication_history) vidi samo najosnovnejše podatke o izdanih zdravilih (koda, ime in odmerek), ne pa tudi podrobnejših podatkov (frekvenca odmerjanja, čas jemanja).

4.3.2.12 Dostop do podatkov na osnovi atributov (Attribute Based Access Control)

Trenutna pravila dostopov do CRPP temeljijo na uporabniških vlogah.

Dostop na osnovi atributov pomeni, da se za uporabnika definirajo pravice za posamezne objekte, npr. določene tipe dokumentov, posamezne podatke oz. dele strukturiranih dokumentov, IZD, VZD, paciente z določenimi atributi ipd.

Definicija atributov in dostopov (read/write) se izvaja v bazi uporabnikov (Varnostni shemi). CRPP od Varnostne sheme prejme SAML žeton s kompleksno in granulirano strukturo atributov in pravic. CRPP je potrebno nadgraditi v skladu z novim (attribute based) načinom dodeljevanja pravic.

Uvedba dostopa na osnovi atributov bi omogočila natančnejše opredeljevanje pravic na zbirki CRPP za zdravstvene delavce, paciente in druge deležnike eZdravja.

4.3.2.13 Omejitve poizvedb po dokumentih eNaročanja

Trenutno ob poizvedbi za določeno ZZZS številko sistem vrne vse napotnice, ki jih ima pacient. Potrebno je vpeljati omejitve tako, da bo uporabnik (IZD) pridobival tiste dokumente, ki so zanj relevantni. Primeri:

- po izvedbi naročila (status napotnice = vpisana, v uporabi, izkoriščena) mora biti napotnica vidna samo znotraj organizacije, na katero je pacient napoten.

- pred izvedbo naročila (status napotnice = izdana) je potrebno omogočiti filtriranje poizvedbe glede na VZS (vrsto zdravstvene storitve).

4.3.2.14 Omejitve pravic vnosa, spreminjanja in brisanje podatkov v CRPP – preverjanje uporabniških pooblastil

Vzpostavitev omejitev brisanja/ spreminjanja, npr:

- PPoP: Brisanje (Revoke Document) lahko izvede zgolj avtor zapisa ali pacientov IOZ.

4.3.2.15 Pregled aktivnih prepovedi vpogleda v PPoP (seznam IZD, za katere velja prepoved)

Izdelava nove metode, ki za posameznega vrne aktualni seznam IZD, za katere velja prepoved, ter seznam (Document ID) veljavnih predhodno podanih prepovedi.

Namen je poenostavitev postopka za preklic prepovedi tako, da bi z enim samim preklicem lahko preklicali vse predhodno podane prepovedi.

4.3.2.16 Obveščanje (alarmiranje) na določen tip dokumenta

V kolikor ima pacient določene podatke (npr. zapis o alergiji), centralni sistem zalednemu sistemu pošlje obvestilo – opozorilo.

18/31

4.3.2.17 Obveščanje (alarmiranje) na določen podatek v strukturiranem zapisu

V kolikor ima pacient zapisane določene kritične podatke, centralni sistem zalednemu (lokalnemu) sistemu pošlje opozorilo.

Kritični podatki se označijo oz. definirajo vnaprej.

Primeri:

- Življenje ogrožajoče alergije;

- določene bolezni in stanja (na podlagi predhodno opredeljenega nabora kritičnih bolezni);

Ko se v zalednem sistemu zavede ZZZS številka (npr. preko čitalca KZZ), le-ta sproži poizvedbo na CRPP. V ta namen se implementira posebna metoda poizvedbe ali se razširi ena od obstoječih metod. V kolikor ima pacient zabeležen kritični podatek in zaledni sistem pošlje poizvedbo na CRPP za tega pacienta, CRPP zalednemu sistemu pošlje opozorilo.

4.3.2.18 Dopolnitve pravil vpogleda v zdravstveno dokumentacijo – vpogled napotovalca

Razširitev pooblastil za vpogled v dokumentacijo na napotovalca – izdajatelja napotnice

Namen: izdajatelj napotnice, ki ni pacientov IOZ, bi lahko v 45 dni po zaključku obravnave pregledoval pacientove dokumente.

4.3.2.19 Mehanizem obveščanja IOZ o novih dokumentih, ki jih je prejel pacient

Vzpostavitev mehanizma, ki bi pacientovega IOZ obvestil o nedavno prejetih dokumentih (npr. dokumenti prejeti v zadnjem mesecu).

IOZ bi ob prijavi sprožil zahtevo po izpisu za določeno časovno obdobje (npr. zadnji teden, zadnji mesec). Sistem bi na podlagi podatkov v RPPE izpisal dokumente zdravnikovih pacientov.

4.3.2.20 Mehanizem obveščanja o novih dokumentih po različnih kriterijih (metapodatki dokumenta, vsebina, pacientovi podatki)

Na zahtevo poizvedujočega uporabnika (zunanjega sistema) CRPP vrne seznam dokumentov po različnih kriterijih, npr. datum rojstva pacienta, datum dokumenta, šifra IZD, tip dokumenta ipd.

Primeri:

- vsi rojeni v določenem tednu mesecu na podlagi odpustnih pisem pri odpustu novorojenčkov iz porodnišnic;

- izpis pacientov določene starostne skupine, ki so prejeli določene diagnoze.

4.3.2.21 Vpeljava novega strukturiranega dokumenta

Vpeljava novega strukturiranega dokumenta na podlagi podatkovnega modela, ki ga pripravi naročnik.

Primeri: histopatološki izvid, eTriaža (dokument, ki nastane ob procesu triaže).

Opomba: Naročnik naj poda splošno oceno za en nov tip strukturiranega dokumenta.

19/31

4.3.2.22 Radiološki izvidi – povezava s sistemom Teleradiologija

Sistem Teleradiologija bi v CRPP pošiljal strukturirane podatke o radioloških slikah. V CRPP bi se za vsak izvid hranili:

- strukturirani (meta) podatki ter

- podatki o lokaciji slike (kazalnik).

Slike oz. slikovni izvidi se v CRPP ne bodo shranjevali.

Namen je, da bi preko CRPP do izvidov dostopali tudi drugi zdravniki in ne zgolj tisti, ki so vključeni v Teleradiologijo.

V CRPP bi bilo potrebno uvesti nov tip dokumenta in podpreti integracijo s sistemom Teleradiologija.

4.3.2.23 Strukturiran laboratorijski izvid

Izdelava strukturiranega laboratorijskega izvida v skladu z mednarodnimi standardi oz. prilagoditev obstoječe Open EHR predloge. To vključuje implementacijo na centralnem sistemu, pripravo šifranta LOINC in morebitnih ostalih šifrantov.

4.3.2.24 Vzpostavitev registra

Vpeljava oz. integracija novega registra, ki se bo povezoval s CRPP.

V okviru integracije registra s CRPP mora izvajalec omogočiti:

- izdelavo registra vključenih pacientov (seznam pacientov, ki so vključeni v register, na osnovi obstoječega RPPE);

- vključitev novih tipov strukturiranih dokumentov v infrastrukturo CRPP (to ne vključuje modeliranja oz. definicije podatkovnih struktur);

- obravnavo specifičnih pooblastil (vlog) skrbnikov registra, drugih zdravstvenih delavcev in upravičencev do podatkov iz registra;

- pridobivanje razpoložljivih podatkov o pacientih na osnovi selekcijskih podatkov, kot npr.:

o pacienti določene starostne skupine;

o pacienti, ki imajo v PPoP zapisane določene diagnoze;

o pacienti, ki imajo stalno prebivališče v določeni regiji;

- specifične poizvedbe po pacientih, ki so vključeni v register, na podlagi selekcijskih kriterijev oz. razpoložljivih podatkov, npr.:

o poizvedbo o pacientih, ki so v določenem obdobju prejemali dokumente oz. jih niso prejemali;

- specifične poizvedbe po dokumentih zadevnih pacientov;

- generiranje pdf dokumenta po zgledu PPoP (»Register Patient Summary«). Dokument povzema podatke, ki se vodijo o določenem pacientu. To bo med drugim omogočalo pacientu, da bo preko portala zVEM pridobival podatke, ki se o njem vodijo v registru.

- izdelavo tehnične dokumentacije, ki bo zagotavljala vse potrebne informacije za vzpostavitev oz. integracijo registra.

Storitev vzpostavitve oz. integracije ne vključuje definiranja vsebin in izdelave aplikativnega razvoja uporabniškega vmesnika. Aplikativni razvoj bo predvidoma naloga skrbnika registra oz. zunanjega izvajalca in vključuje:

- izdelavo podatkovnih struktur temelječih na OpenEHR arhetipih in predlogah;

- izdelavo vnosnih oken;

20/31

- izdelavo grafičnih prikazov;

- izdelavo orodij za statistične analize.;

- izdelavo metodoloških navodil in uporabniške dokumentacije.

Primeri registrov:

- register za namene preventivnih programov (Svit);

- register poškodb pri delu;

- register bolnikov z določeno boleznijo;

Opomba: Ponudnik naj poda okvirno oceno za vzpostavitev enega registra.

4.3.2.25 Vpeljava osebnega zdravstvenega zapisa (PHR)

Osebni zdravstveni zapis (Personal Health Record, PHR) pacientu omogoči samostojno vnašanje lastnih podatkov oz. objavo le-teh v CRPP.

Primeri: meritve krvnega sladkorja, meritve krvnega tlaka ipd.

Vnos PHR bo predvidoma potekal preko portala zVEM.

Vsebino oz. strukturo podatkov definira naročnik.

Na CRPP je potrebno implementirati:

- Nov tip dokumenta;

- Nastavljiva pooblastila oz. pogoje vpogleda v PHR. Privzeto veljajo enaka pravila kot za vpogled v PPoP. Pacient ima možnost omejiti pravice zgolj na IOZ ali za določeno organizacijo (vnos šifre organizacije).

Opomba: Ponudnik naj poda oceno del za vpeljavo enega tipa strukturiranega zapisa PHR.

4.3.2.26 Izobraževanje - delavnica OpenEHR

Priprava in izvedba izobraževanje (delavnice) za OpenEHR za naročnika in morebitne zunanje izvajalce.

Opomba: Ponudnik naj skupaj z oceno obsega del navede predvideno trajanje in lokacijo izobraževanja.

4.3.2.27 Izobraževanje - delavnica Terminološki strežnik

Priprava in izvedba izobraževanje (delavnice) za Terminološki strežnik za naročnika in morebitne zunanje izvajalce.

Opomba: Naročnik naj skupaj z oceno obsega del navede predvideno trajanje in lokacijo izobraževanja.

21/31

5. SKUPNE ZAHTEVE

V kolikor pri posamezni zahtevi ni izrecno navedeno drugače, veljajo zahteve v tem poglavju za vse rešitve, ki so predmet javnega naročila:

• Tiani Spirit IHE Interoperabilna hrbtenica • IH Adapter – vmesnik do Tiani Spirit rešitve, • Think!EHR Platform, • Register RPPE • Terminološki strežnik HealthTerm, • UKZ - Clinical Knowledge Manager.

5.1 ZAHTEVE GLEDE RAZPOLOŽLJIVOSTI Vse rešitve razen rešitve • UKZ - Clinical Knowledge Manager morajo delovati v režimu 24/7 in biti uporabnikom razpoložljive vsaj 99,8% (kar predstavlja 17,52 ur nenapovedanega izpada na letni ravni). Izpad v obdobju enega meseca ne sme presegati 2 (dveh) ur. Izpad v obdobju enega tedna ne sme presegati 30 minut. Rešitev UKZ - Clinical Knowledge Manager mora delovati v režimu 24/7 in biti uporabnikom razpoložljiva vsaj 99% (kar predstavlja 3,65 dni nenapovedanega izpada na letni ravni). Izpad v obdobju enega meseca ne sme presegati 7,2 ur. Izpad v obdobju enega tedna ne sme presegati 1,68 ur.

5.2 ZAHTEVE GLEDE ZMOGLJIVOSTI (ODZIVNOSTI); Razpoložljivost vseh rešitev razen rešitve • UKZ - Clinical Knowledge Manager vpliva na proces zdravljenja pacientov in delo izvajalcev zdravstvenih storitev, zato morajo ob zadostnih sistemskih virih in normalnem delovanju omrežnih in sistemskih storitev delovati v realnem času in zagotavljati, da je ob normalnem delovanju omrežnih in sistemskih storitev odzivni čas pod 1 sekundo. Razpoložljivost rešitve UKZ - Clinical Knowledge Manager ne vpliva na proces zdravljenja pacientov in delo izvajalcev zdravstvenih storitev. Vpliva na delo osebe, ki izvajajo procese upravljanja kliničnega znanja. Odzivni čas ob zadostnih sistemskih virih in ob normalnem delovanju omrežnih in sistemskih storitev ne sme presegati 2 sekund.

5.3 ZAHTEVE GLEDE RAZŠIRLJIVOSTI (SKALABILNOSTI) Ob predpostavki, da so zagotovljene zadostne kapacitete na sistemski infrastrukturi, mora rešitev delovati brez omejitev z razpoložljivostjo opredeljeno pod točko 5.1 in odzivnostjo opredeljeno pod točko 5.2, in sicer ne glede na povečane obremenitve zaradi nadaljnjega povečanja obsega uporabe. Povečan obseg uporabe med drugim vključuje:

- povečanje števila dokumentov; - povečanje števila nastavljivih elementov; - povečanje števila transakcij; - povečanje števila uporabnikov.

5.4 ZAHTEVE GLEDE ODZIVNEGA ČASA PRI REŠEVANJU

ZAHTEVKOV

5.4.1 Napake oz. motnje v delovanju sistema

Napaka je definirana kot nedelovanje informacijske rešitve oziroma delovanje, ki ni v skladu z delovanjem, predstavljenim pri prevzemu rešitve in opisanim v dokumentaciji informacijske rešitve oziroma tistih, ki so z izvajalcem naknadno sporazumno dogovorjene oziroma z navodili za uporabo informacijske rešitve. Incidenti se delijo glede na resnost in vpliv na poslovanje, od česar je odvisna tudi hitrost oziroma nujnost odprave:

• Kritična napaka, ki ima zelo visok vpliv: popolna odpoved delovanja storitev ali poglavitnega dela storitev, ki preprečuje uporabo ključnih poslovnih aplikacij vsem uporabnikom;

• Napaka z visokim vplivom: Delna odpoved delovanja storitev ali poglavitnega dela storitev, ki resno vpliva na uporabo ključnih poslovnih aplikacij skupini uporabnikov;

• Napaka s pomembnim vplivom: oteženo delovanje storitev, ki ne vpliva kritično na uporabo ključnih poslovnih aplikacij pri skupini ali posameznem uporabniku;

• Napaka, ki ima nizek vpliv: katerikoli incident, ki ne vpliva na uporabo ključnih poslovnih aplikacij.

Ponudnik bo pri opravljanju storitev osnovnega vzdrževanja zagotovil reševanje zahtevkov v primeru napak oz. motenj pri delovanju glede na njihovo prioriteto v skladu z odzivnimi časi v spodnji tabeli.

Prioriteta zahtevka

Odzivni čas Čas, v katerem mora izvajalec odpraviti vzroke za napako oz. motnjo

kritična 1 ura 2 uri

visoka 2 uri 4 ure

pomembna 4 ure 8 ur

nizka 1 delovni dan 2 delovna dneva

Tabela 2: Odzivni časi v primeru zahtevkov zaradi napak oz. motenj

23/31

5.4.2 Odgovori na tehnična vprašanja

Izvajalec je dolžan na vprašanja naročnika in zunanjih izvajalcev pri integraciji novih

rešitev ali nadgradnji obstoječih podati odgovor na vprašanje najkasneje v enem

delovnem dnevu.

5.4.3 Posodabljanje tehnične dokumentacije

Izvajalec je dolžan tehnično dokumentacijo posodabljati sproti tako, da je usklajena

dejanskim stanjem sistema oz. z vsemi spremembami, nadgradnjami in posodobitvami. V kolikor sprememba (nadgradnja, posodobitev) vpliva na zunanje izvajalce, je izvajalec

dolžan tehnično dokumentacijo posodobiti najpozneje do takrat, ko je sprememba

implementirana v testnem okolju. Skrajni rok za posodobitev tehnične dokumentacije je takrat, ko je zadevna sprememba

vključena v produkcijsko okolje.

5.4.4 Odzivni čas za dopolnilno vzdrževanje

V primeru povpraševanj naročnika za dopolnilno vzdrževanje je ponudnik dolžan pripraviti podrobno ponudbo, vključno s tehnično specifikacijo in oceno obsega del, najkasneje v petih delovnih dneh. Naročnik in izvajalec se lahko dogovorita za daljši odzivni čas, v kolikor gre za kompleksnejše ali zahtevnejše naloge. Dogovorjeni odzivni čas oziroma terminski načrt potrdi naročnik v pisni obliki.

Odzivni čas se šteje od takrat, ko je naročnik izvajalcu pisno podal funkcionalne zahteve, do izdelave ponudbe. Proces izvedbe dopolnilnega vzdrževanja je opisan v poglavju 6.1.

5.5 ZAHTEVE GLEDE TESTIRANJA NADGRADENJ Ponudnik mora programsko opremo pred izvedbo nadgradnje obvezno testirati v razvojnem in testnem okolju.

V primeru večjih (MAJOR) nadgradenj in nadgradenj z naslova dopolnilnega vzdrževanja mora ponudnik naročnika pred izvedbo nadgradnje pisno obvestiti o izvedenih testnih scenarijih in rezultatih testov.

5.6 ZAGOTAVLJANJE TESTNEGA OKOLJA Izvajalec mora zagotoviti testno in razvojno okolje. Testno okolje mora vsebovati enake gradnike kot okolje redne uporabe (produkcija).

Uporabniki testnega okolja so poleg naročnika in izvajalca tudi zunanji izvajalci ki zagotavljajo sisteme, ki se povezujejo z eZdravje, kot npr. ponudniki drugih rešitev eZdravja ter ponudniki lokalnih (zalednih) informacijskih sistemov.

Izvajalec mora med drugim zagotoviti in vzdrževati bazo testnih uporabnikov RPPE za vse zunanje izvajalce. Baza testnih uporabnikov RPPE se uporablja za namen testiranja pripadnosti pacientov izbranemu osebnemu zdravniku ter za namen testiranja pooblastil v zvezi z družinskimi in skrbniškimi razmerji. Glede na potrebe sodelujočih partnerjev mora ponudnik kreirati testne uporabnike. Na testnih uporabnikih mora izvajalec urejati podatke o pripadnosti izbranemu osebnemu zdravniku ter družinska in skrbniška razmerja.

24/31

Izvajalec mora naročniku omogočiti dostop do aktualne baze testnih uporabnikov RPPE.

5.7 VODENJE IN OBVLADOVANJE SPREMEMB V PROGRAMSKIH

REŠITVAH Vodijo se verzije rešitev v skladu z določili Semantic Versioning 2.0.0 (http://semver.org/). Pri vodenju različic velja:

- številke različice se vodi MAJOR.MINOR.PATCH, prirastek:

- MAJOR/GLAVNA različica ko bo nezdružljive spremembe API,

- MINOR/MANJŠA različica ko dodate funkcionalnost v nazaj združljiv način, in

- PATCH /POPRAVEK različica ko bo nazaj združljive popravke.

- Dodatne oznake za predhodno izpustitev in gradijo metapodatki so na voljo kot razširitve formata MAJOR.MINOR.PATCH.

- Glavna različica potencialno poruši delovanja predhodnih funkcionalnosti. Vpeljuje se vpeljuje dvakrat letno. Izjeme tega pravila se sproti uskladi z vsemi vpletenimi.

- Manjše različice, ki ne rušijo funkcionalnosti za nazaj, se lahko vpeljuje pogosteje.

- Popravke se vpeljuje po potrebi.

5.8 PRAVILA ZA ODLAGANJE PROGRAMSKE KODE Odložišče programske kode je Apache Subversion v eZdravje okolju, ki zahteva potrjevanje sprememb in vodenje različic s strani izvajalca pogodbenega odnosa.

Izvajalec se mora pri razvoju rešitev držati pravil lepega programiranja in obvezno v izvorni kodi opisati metode, funkcije, objekte in spremenljivke z nazornim opisom.

Izvajalec mora pred uvedbo nove različice rešitve narediti in prikazati test nove različice rešitve, ki je tehnično dokumentiran.

5.9 OBVEŠČANJE O POSEGIH, NADGRADNJAH, SPREMEMBAH IN

TEŽAVAH Izvajalec je dolžan naročnika obveščati o koristnih in nujnih nadgradnjah, ki preprečujejo zastaranje oziroma zagotavljajo varno in vzdržno delovanje rešitev.

Izvajalec mora naročnika brez odlašanja obveščati tudi o vseh predvidenih in nastalih težavah pri uporabi in izvajanju pogodbenega odnosa.

5.10 POSREDOVANJE INFORMACIJ, SVETOVANJE IN

ODGOVARJANJE NA VPRAŠANJA Izvajalec je dolžan naročniku in zunanjim izvajalcem sporočati informacije, spremembe in odgovore na vprašanja o rešitvah ter jih obveščati o posegih, ki vplivajo na delovanje sistema.

Izvajalec je dolžan naročniku in zunanjim izvajalcem sporočati informacije, spremembe in odgovore na vprašanja o rešitvah.

Izvajalec mora pred vsakim posegom, ki vpliva na delovanje oz. bi lahko povzročil izpad ali motnje delovanja rešitev, obvezno obvestiti prvi nivo podpore eZdravja.

25/31

5.11 TEHNIČNA DOKUMENTACIJA Pri nadgradnjah mora izvajalec dopolnjevati končne različice dokumentacije in ne zgolj spremembe. To velja tako za uporabniško kot tudi za tehnično dokumentacijo ter grafične predstavitve.

Tehnična dokumentacija mora vsebovati grafične predstavitve, kjer je to smiselno (procesne diagrame, sheme UML, BPMN2 ipd.)

V kolikor se naročnik in izvajalec ne dogovorita drugače, izvajalec tehnično dokumentacijo objavlja v elektronski obliki na dogovorjenem spletišču.

Izvajalec mora omogočati dostop do vse razpoložljive dokumentacije naročniku in zunanjim izvajalcem. Izvajalec mora naročniku in zunanjim izvajalcem na njihovo zahtevo urejati dostope (uporabniške račune za dostop do dokumentacije)

Izvajalec mora naročniku dodeliti administrativne pravice za urejanje dostopov do dokumentacije zunanjim izvajalcem.

5.12 ELEKTRONSKO PODPISOVANJE DOKUMENTOV V kolikor se naročnik in izvajalec ne dogovorita drugače, se dokumenti pogodbenega odnosa podpisujejo elektronsko.

5.13 UPORABA ORODJA REDMINE Za vodenje pogodbenega odnosa in spremljanje izvedbe mora izvajalec uporabljati aplikacijo Redmine (https://redmine.ezdrav.si/).

V Redmine se vodijo:

- nove funkcionalnosti,

- napake,

- vprašanja in naloge za podporo,

- testiranje,

- ostale naloge,

- zapisniki sestankov,

- mesečna in ostala poročila (o testiranju, o incidentih, o opravljenih delih...) oziroma povezave do fizičnih oblik poročil.

5.14 ZNAČILNOSTI IT OKOLJA

5.14.1 Licence in spletni brskalniki

Licence za IHE interoperabilno hrbtenico, OpenEHR platformo, Terminološki strežnik in za Upravljavca kliničnega znanja so bile kupljene in nimajo časovnih omejitev – so trajne.

5.14.2 Skladnost z zakonodajo in upravljanje s podatkovnimi viri

Rešitve morajo biti skladne z vsemi zakoni, podzakonskimi akti in pravilniki, ki so veljavni v Republiki Sloveniji. Rešitve morajo zadostiti uporabniškim in funkcionalnim zahtevam, ki izhajajo neposredno iz zakonodaje, tudi če te zahteve niso eksplicitno opredeljene v tem dokumentu.

26/31

Če bodo v času izvajanja oz. v času veljavnosti pogodbe sprejeti novi zakoni, podzakonski akti in pravilniki, je treba upoštevati tudi te.

Poseben poudarek je na določilih zakonov:

• Zakon o Elektronskem Podpisovanju in Elektronskem Podpisu, ZEPEP, Uradni list RS, št. 98/04 - uradno prečiščeno besedilo, 61/06 - ZEPT in 46/14 (http://www.uradni-list.si/1/objava.jsp?urlurid=20044284 )

• Zakon o Varstvu Osebnih Podatkov (vključujoč smernice informacijske pooblaščenke s tega področja), Uradni list RS, št. 94/2007 (http://www.uradni-list.si/1/objava.jsp?urlurid=20074690 )

• Splošna uredba o varstvu osebnih podatkov -Uredba (EU) 2016/679 z dne 27. aprila 2016 (http://eur-lex.europa.eu/legal-content/SL/TXT/PDF/?uri=CELEX:32016R0679&from=SL)

• Zakon o varstvu dokumentarnega in arhivskega gradiva ter arhivih, ZVDAGA, Uradni list RS, št. 30/06 () in 51/14 (http://www.uradni-list.si/1/objava.jsp?urlurid=20142170 )

• Zakon o zbirkah podatkov s področja zdravstvenega varstva, ZZPZ, Uradni list RS, št. 65/00 in 47/15 (http://www.pisrs.si/Pis.web/pregledPredpisa?id=ZAKO1419)

• Pravilnik o prepovedi vpogleda v povzetek podatkov o pacientu v Centralnem registru podatkov o pacientih, Uradni list RS, št. 84/15 (http://www.pisrs.si/Pis.web/pregledPredpisa?id=PRAV12543)

• Zakon o pacientovih pravicah – ZPacP, Uradni list RS, št. 15/2008 (http://www.uradni-list.si/1/objava.jsp?urlid=200815&stevilka=455 )

• Uredba o poslovanju z uporabniki v javnem zdravstvu, Uradni list RS, št. 98/2008 (http://www.uradni-list.si/1/objava.jsp?urlurid=20084178 )

27/31

6. SPECIFIČNE ZAHTEVE ZA DOPOLNILNO VZDRŽEVANJE

6.1 PROCES NAROČILA IN IZVEDBE NALOG V OKVIRU

DOPOLNILNEGA VZDRŽEVANJA Naloge z naslova dopolnilnega vzdrževanja se bodo izvajale v skladu s procesom opisanim v nadaljevanju.

6.1.1 Specifikacija zahtev

Naročnik posreduje izvajalcu opis funkcionalnih zahtev v pisni obliki (funkcionalna specifikacija). Funkcionalne zahteve opisujejo želeno spremembo delovanja oziroma delovanje sistema po nadgradnji na nivoju procesov in ne zajemajo podrobnosti tehnične izvedbe.

V kolikor prilagoditev uvaja nove scenarije uporabe oziroma vpliva na obstoječe, naročnik v okviru specifikacije zahtev opiše tudi značilne scenarije uporabe.

Glede na obseg in kompleksnost vsebine je funkcijska specifikacija lahko zapisana v različnih oblikah. Kompleksne in obsežne zahteve bo naročnik praviloma opisal v obliki dokumenta. Manj obsežne vsebine bo naročnik opisal v obliki zahtevka za novo funkcionalnost v orodju Redmine.

6.1.2 Tehnična specifikacija

Izvajalec na osnovi funkcionalnih zahtev poda predlog rešitve v obliki tehnične specifikacije.

Tehnična specifikacija mora vsebovati najmanj:

- spremembe obstoječih gradnikov sistema: npr. nov parameter, nova / spremenjena metoda ipd.;

- spremembe poslovne logike: npr. spremenjena obdelava vhodnih podatkov; spremenjen odziv sisteme glede na uporabniška pooblastila; pravila validacije podatkov ipd.;

- spremembe vmesnikov;

- vpliv sprememb na zunanje sisteme oz. prilagoditve zunanjih sistemov, v kolikor so le-te potrebne: npr.:

• spremembe obstoječih pogojev, funkcij in metod;

• zahteve glede zagotavljanja vhodnih parametrov;

• pričakovane spremembe odziva zunanjih sistemov;

• pričakovani vplivi na uporabniške postopke v zunanjih sistemih;

- morebitne spremembe konfiguracije CRPP in zunanjih sistemov;

- morebitne zahteve glede nadgradnje sistemske infrastrukture;

- morebitni specifični vplivi na porabo sistemskih virov, npr. vpliv na odzivnost;

- morebitne druge vplive na deležnike eZdravja.

Glede obseg in kompleksnost vsebine je tehnična specifikacija lahko zapisana v različnih

28/31

oblikah. Kompleksne in obsežne zahteve bo izvajalec praviloma opisal v obliki dokumenta. Manj obsežne zahteve bo izvajalec opisal v zahtevku za novo funkcionalnost v orodju Redmine.

6.1.3 Priprava ponudbe z oceno vrednosti in obsega del

Izvajalec pripravi ponudbo z oceno obsega del.

Ponudba se sklicuje na tehnično specifikacijo iz prejšnje točke.

Ponudba mora vsebovati najmanj:

- navedbo nalog, ki jih bo ponudnik opravil, z ocenjenim obsegom teh nalog oz. časom, ki ga bo strokovno osebje ponudnika porabilo za izvedbo. Enota mere za obseg nalog je obseg dela na časovno enote: človek/ura, človek/dan in se vrednoti v skladu z urnimi postavkami opredeljenimi v pogodbi;

- druge stroške (poleg stroškov dela), ki bodo nastali ob izvedbi in vplivajo na vrednost ponudbe: npr. materialni stroški, potni stroški;

- opis izdelkov: npr. novi/spremenjeni gradniki, tehnična dokumentacija, uporabniška dokumentacija, testni scenariji, analitični izdelki;

- časovni plan izvedbe;

- morebitna tveganja, povezana z izvedbo.

6.1.4 Potrditev ponudbe in naročilo

Naročnik pisno potrdi ponudbo, pripadajočo dokumentacijo ter terminski načrt ter poda naročilo.

Če izvajalec izvede dela brez naročila oz. potrditve naročnika, nosi stroške izvedbe sam.

6.1.5 Izvedba del

Izvajalec mora naročnika nemudoma pisno obvestiti o morebitnih neskladnostih, odstopanjih in drugih okoliščinah, ki bi lahko vplivale na izvedbo.

Spremembe je potrebno obravnavati v skladu s točko 6.1.7

6.1.6 Zaključek izvedbe in prevzem izdelkov

Izvajalec naročnika obvesti, da je zaključil izvedbo in je pripravljen na prevzem.

Izvajalec naročniku predloži dokazila o predhodno opravljenih testih, iz katerih je razvidno, da je v testnem okolju preveril delovanje zahtevanih funkcionalnosti (npr. revizijska sled v testnem okolju, vpogled v aktivnosti testnih uporabnikov preko portala zVEM).

Naročnik in izvajalec se dogovorita za termin prevzema izdelkov ter za pogoje, ki so potrebni za izvedbo prevzema, kot npr. zagotovilo testnega okolja, v katerem bo naročnik preverjal izdelke.

Naročnik pripravi prevzemni zapisnik.

Zapisnik podpišeta naročnik in izvajalec.

Po podpisanem prevzemnem zapisniku izvajalec izstavi račun za opravljeno delo.

V kolikor so ob prevzemu ugotovljene manjše pomanjkljivosti, se izvajalec in naročnik lahko dogovorita za rok, v katerem bodo izvajalec pomanjkljivosti odpravil. V

29/31

prevzemnem zapisniku se v tem primeru izrecno navedejo izjeme oz. pomanjkljivosti ter rok, v katerem bodo le-te odpravljene. Naročnik zadrži del plačila do odprave pomanjkljivosti.

6.1.7 Obvladovanje sprememb

Sprememba je posledica nepredvidenih dogodkov oz. bistveno spremenjenih okoliščin in pomeni:

- Spremembo časovnega plana izvedbe oz. odstopanje od prvotno potrjenega plana)

- Spremembo vsebine: npr. dodatna, okrnjena, razširjena ali spremenjena funkcionalnost ali tehnična vsebina;

- Spremembo tehnične specifikacije;

- Spremembo obsega: povečan ali zmanjšan obseg dela glede na potrjeno ponudbo iz točke 6.1.4;

- Spremembo drugih stroškov povezanih z izvedbo.

Pobuda za spremembo lahko pride s strani izvajalca ali ponudnika. Pobudnik mora spremembo pisno utemeljiti.

Spremembo, ki nastopi po potrditvi izvedbenega načrta oz. po potrditvi ponudbe (točka 6.1.4), morata naročnik in izvajalec pisno potrditi.

Spremembo je potrebno dokumentirati. To zajema tudi spremembo vse pripadajoče dokumentacije: npr. funkcijska in tehnična specifikacija, uporabniška dokumentacija.

Priloga – ocene obsega del za dopolnilno vzdrževanje po vsebinskih sklopih

Vsebinski sklop/

funkcionalnost

Ocena obsega del

(človek/dan)

Ocena roka izvedbe

(št. koledarskih dni)

Opombe ponudnika

4.3.2.1

4.3.2.2

4.3.2.3

4.3.2.4

4.3.2.5

4.3.2.6

4.3.2.7

4.3.2.8

4.3.2.9

4.3.2.10

4.3.2.11

4.3.2.12

4.3.2.13

4.3.2.14

4.3.2.15

4.3.2.16

4.3.2.17

31/31

Vsebinski sklop/

funkcionalnost

Ocena obsega del

(človek/dan)

Ocena roka izvedbe

(št. koledarskih dni)

Opombe ponudnika

4.3.2.18

4.3.2.19

4.3.2.20

4.3.2.21

4.3.2.22

4.3.2.23

4.3.2.24

4.3.2.25

4.3.2.26

4.3.2.27

Spodaj podpisani pooblaščeni predstavnik ponudnika izjavljam, da vse ponujene storitve v celoti ustrezajo zgoraj navedenim opisom.

V/na ___________, dne __________

Ime in priimek:

Žig in podpis: