Datum objave: 12.10.2020   15:05

VPRAŠANJE
1. V točki 1.2 naročnik zahteva tudi "pisanje in distribucijo naročniku". Ker zahtevek za izvajanje diagnostičnih storitev nastaja v Teleradiološkemu portalu in ne v lokalnemu RISu, avtomatska distribucija ni mogoča. Ali zadošča, da si uporabnik lahko sam shrani avtorizirani izvid v obliki PDF?

2. V točki 1.2 naročnik zahteva tudi "omogoča dodajanje različnih datotek pri posredovanju odgovora na zahtevo...". Zdravnik ob ogledu slikovnega materiala napiše izvid in dodajanje druge dokumentacije ni smiselno; naročniku predlagamo, da omenjeno zahtevo opusti.

3. V točki 1.2 naročnik zahteva tudi "Slike/serije/študije so lahko namenjene točno določenemu uporabniku. V tem primeru do teh gradiv ne more dostopati nihče razen uporabnika, kateremu so gradiva dodeljena. " Ali lahko ponudimo rešitev, ki bi omejevala dostop do slikovnega gradiva na način, da ima uporabnik, ki mu je slikovno gradivo namenjeno, dostop tudi do predhodnih preiskav tega pacienta. Na ta način ima uporabnik pri pripravi izvida dodatno gradivo, ki mu olajša delo.

4. Naročnik v točki 1.2 zahteva tudi "možnost anonimizacije slikovnega materiala". Ker je sistem varen in omogoča omejitev dostopov do slikovnega gradiva na posameznega uporabnika, predlagamo, da naročnik to zahtevo opusti, predvsem, ker obstaja možnost, da bi posamezna ustanova poslala hkrati dva anonimizirana pacienta. Ker ne obstaja integracija za vračanje izvidov v lokalne sisteme, se s tem močno poveča verjetnost kritične napake zamenjave pacienta.

5. V zahtevi 1.2 naročnik zahteva "Upravljanje skupnih šifrantov". Naročnika prosimo za natančno definicijo, katere šifrante želi imeti v skupnem upravljanju.

6. Naročnik v točki 1.3.2 navaja, da je Teleradiologija integrirana z Varnostno shemo. Naročnika prosimo, da natančno opiše, kako je trenutna rešitev integrirana z varnostno shemo.

7. V točki 2, C2, v opisu in na sliki 3 opisuje strežniško strukturo. Razvidno je, da na strani DC Ljubljana načrtuje ločeno podatkovno gručo. Ali lahko ponudimo rešitev za stran DC Maribor na enak način, to je da je podatkovna gruča ločena od aplikativne, posebej, ker bi bila taka rešitev bistveno cenejša zaradi politike licenciranja Oracla, ki je podatkovna baza sistema, katerega nameravamo ponuditi.

8. Naročnik zahteva v točki 2 tudi, da sistem omogoča uporabo 30.000 končnih uporabnikov. Ker v Sloveniji nimamo 30.000 zdravnikov in radioloških inženirjev, je to verjetno napaka? Ail je naročnik mislil zahtevo, da mora sistem omogočati velikost za 30.000 preiskav?

9. V točki 2 naročnik zahteva tudi "menjava gradnikov ne sme povzročiti izpada delovanja storitev". Ali se to nanaša na postavitev nadgrajenega sistema? Ker trenutno stanje ni v HA postavitvi, predlagamo, da naročnik zahtevo umakne. V primeru, da se zahteva nanaša izključno na delovanje nadgrajenega sistema; ali lahko ponudimo rešitev, ki bi omogočala nadgradnjo na način, da ni časovnega izpada, zahteva pa ponovno prijavo uporabnikov v sistem?

10. V točki 5.2.1. naročnik zahteva stroge odzivne čase. Ali se smatra 1 sekunda odzivnega časa čas, ki preteče od trenutka, ko aplikacija dobi odgovor od (zunanjih) sistemov za avtentikacijo uporabnika?

11. Ali lahko smatramo zahtevani odzivni čas 5 sekund za prikaz slikovnega gradiva za preiskavo, ki vsebuje eno RTG sliko? Posebej, ker so preiskave vedno večje, vsebujejo lahko tudi 6000 slik in je tak odzivni čas v tem primeru nemogoče doseči.

12. Naročnik zahteva v točki 8.1 predajo izvorne kode. Ali lahko ponudnik ponudi rešitev Teleradiološkega portala, ki je lasten razvoj in za katerega bo vedno predajal kodo v skladu z zahtevo, poleg tega pa ponudi produkt PACS svetovne multinacionalke, za katero pa predaja kode ni možna?


ODGOVOR
Spoštovani,
posredujemo odgovore:

1. V točki 1.2 naročnik zahteva tudi "pisanje in distribucijo naročniku". Ker zahtevek za izvajanje diagnostičnih storitev nastaja v Teleradiološkemu portalu in ne v lokalnemu RISu, avtomatska distribucija ni mogoča. Ali zadošča, da si uporabnik lahko sam shrani avtorizirani izvid v obliki PDF?
ODG: Gre za opis obstoječe funkcionalnosti. Vse predloge glede sprememb funkcionalnosti bo naročnik skupaj z izbranim vzdrževalcem obravnaval v okviru nove vzdrževalne pogodbe.

2. V točki 1.2 naročnik zahteva tudi "omogoča dodajanje različnih datotek pri posredovanju odgovora na zahtevo...". Zdravnik ob ogledu slikovnega materiala napiše izvid in dodajanje druge dokumentacije ni smiselno; naročniku predlagamo, da omenjeno zahtevo opusti.
ODG: Gre za opis obstoječe funkcionalnosti. Vse predloge glede sprememb funkcionalnosti bo naročnik skupaj z izbranim vzdrževalcem obravnaval v okviru nove vzdrževalne pogodbe.


3. V točki 1.2 naročnik zahteva tudi "Slike/serije/študije so lahko namenjene točno določenemu uporabniku. V tem primeru do teh gradiv ne more dostopati nihče razen uporabnika, kateremu so gradiva dodeljena. " Ali lahko ponudimo rešitev, ki bi omejevala dostop do slikovnega gradiva na način, da ima uporabnik, ki mu je slikovno gradivo namenjeno, dostop tudi do predhodnih preiskav tega pacienta. Na ta način ima uporabnik pri pripravi izvida dodatno gradivo, ki mu olajša delo.
ODG: Gre za opis obstoječe funkcionalnosti. Vse predloge glede sprememb funkcionalnosti bo naročnik skupaj z izbranim vzdrževalcem obravnaval v okviru nove vzdrževalne pogodbe.


4. Naročnik v točki 1.2 zahteva tudi "možnost anonimizacije slikovnega materiala". Ker je sistem varen in omogoča omejitev dostopov do slikovnega gradiva na posameznega uporabnika, predlagamo, da naročnik to zahtevo opusti, predvsem, ker obstaja možnost, da bi posamezna ustanova poslala hkrati dva anonimizirana pacienta. Ker ne obstaja integracija za vračanje izvidov v lokalne sisteme, se s tem močno poveča verjetnost kritične napake zamenjave pacienta.
ODG: Gre za opis obstoječe funkcionalnosti. Vse predloge glede sprememb funkcionalnosti bo naročnik skupaj z izbranim vzdrževalcem obravnaval v okviru nove vzdrževalne pogodbe.


5. V zahtevi 1.2 naročnik zahteva "Upravljanje skupnih šifrantov". Naročnika prosimo za natančno definicijo, katere šifrante želi imeti v skupnem upravljanju.
ODG: Gre za napačno formuliran opis oz. zahtevo. Naročnik od vzdrževalca zahteva upravljanje skupnih šifrantov, klasifikacij, seznamov in baz, ki se uporabljajo ali pa se bodo uporabljali v razvoju kot del informacijske rešitve. Zahteva je navedena tudi v postavkah osnovnega vzdrževanja.

6. Naročnik v točki 1.3.2 navaja, da je Teleradiologija integrirana z Varnostno shemo. Naročnika prosimo, da natančno opiše, kako je trenutna rešitev integrirana z varnostno shemo.
ODG: Teleradiologija in Varnostna shema sta integrirani na način, da lahko zaledni sistemi izvajalcev zdravstvene dejavnosti dostopajo do funkcionalnosti Teleradiologije na podlagi avtentikacije in avtorizacije, ki ju zagotavlja Varnostna shema. Funkcionalnost se trenutno ne uporablja zaradi restrukturiranja tega prijavnega modela.


7. V točki 2, C2, v opisu in na sliki 3 opisuje strežniško strukturo. Razvidno je, da na strani DC Ljubljana načrtuje ločeno podatkovno gručo. Ali lahko ponudimo rešitev za stran DC Maribor na enak način, to je da je podatkovna gruča ločena od aplikativne, posebej, ker bi bila taka rešitev bistveno cenejša zaradi politike licenciranja Oracla, ki je podatkovna baza sistema, katerega nameravamo ponuditi.
ODG: Naročnik dovoli postavitev ločene podatkovne gruče v DC Maribor. Gruča mora sestojiti vsaj iz dveh fizičnih strežnikov.

8. Naročnik zahteva v točki 2 tudi, da sistem omogoča uporabo 30.000 končnih uporabnikov. Ker v Sloveniji nimamo 30.000 zdravnikov in radioloških inženirjev, je to verjetno napaka? Ail je naročnik mislil zahtevo, da mora sistem omogočati velikost za 30.000 preiskav?

ODG: Naročnik je opravil pregled zahteve in jo popravlja na bolj primerno,
iz
»Programska oprema mora omogočati časovno neomejeno uporabo ter podpirati uporabo s strani 30.000 končnih uporabnikov v vsaj 30 ustanovah. Število vključenih ustanov in uporabnikov naj bo možno enostavno razširiti.«
v
»Programska oprema mora omogočati časovno neomejeno uporabo ter podpirati uporabo s strani 15.000 končnih uporabnikov v vsaj 30 ustanovah. Število vključenih ustanov in uporabnikov naj bo možno enostavno razširiti.«

9. V točki 2 naročnik zahteva tudi "menjava gradnikov ne sme povzročiti izpada delovanja storitev". Ali se to nanaša na postavitev nadgrajenega sistema? Ker trenutno stanje ni v HA postavitvi, predlagamo, da naročnik zahtevo umakne. V primeru, da se zahteva nanaša izključno na delovanje nadgrajenega sistema; ali lahko ponudimo rešitev, ki bi omogočala nadgradnjo na način, da ni časovnega izpada, zahteva pa ponovno prijavo uporabnikov v sistem?
ODG: Zahteva se nanaša na celoten proces nadgradnje na visoko-razpoložljivostni način. Končni uporabniki tekom nadgradnje ne smejo občutiti poslabšanje ali izpad delovanja storitev. V tem smislu je ponovna prijava uporabnikov v sistem, brez časovnega izpada, s strani naročnika sprejemljiva in dovoljena.

10. V točki 5.2.1. naročnik zahteva stroge odzivne čase. Ali se smatra 1 sekunda odzivnega časa čas, ki preteče od trenutka, ko aplikacija dobi odgovor od (zunanjih) sistemov za avtentikacijo uporabnika?
ODG: Odzivni čas 1 sekunda ne vključuje časa, ki se porabi v zunanjih sistemih.

11. Ali lahko smatramo zahtevani odzivni čas 5 sekund za prikaz slikovnega gradiva za preiskavo, ki vsebuje eno RTG sliko? Posebej, ker so preiskave vedno večje, vsebujejo lahko tudi 6000 slik in je tak odzivni čas v tem primeru nemogoče doseči.
ODG: Naročnik je opravil pregled zahteve in jo bo spremenil iz
»Odzivni čas prikaza radiološke slike, ki je že na teleradiološkem PACS-u, ne sme presegati 5 sekund.«
v
»Odzivni čas prikaza radiološke preiskvave, ki je že na teleradiološkem PACS-u, ob optimalnem delovanju sistemske infrastrukture (na hitrih diskih), se mora odpreti v času pod 5 sekund. Zahteva mora biti izpolnjena v 95% primerih zahtevkov.«


12. Naročnik zahteva v točki 8.1 predajo izvorne kode. Ali lahko ponudnik ponudi rešitev Teleradiološkega portala, ki je lasten razvoj in za katerega bo vedno predajal kodo v skladu z zahtevo, poleg tega pa ponudi produkt PACS svetovne multinacionalke, za katero pa predaja kode ni možna?
ODG: V primeru ko predaja izvorne kode ni možna zaradi pravnih oz. lastniških razlogov (t.i. »3rd party products«), naročnik dovoljuje predajo namestitvenih in izvršljivih datotek, do katerih ima naročnik pravico uporabe in so del ponujene oz. vzdrževane rešitve.