ЈАВНА НАБАВКА: Услугa успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција

Предметна јавна набавка се спроводи у отвореном поступку у складу са Законом о јавним набавкама („Службени гласник РС“ број 124/12, 14/15 и 68/15) и подзаконским актима којима се уређују јавне набавке.

3. Предмет јавне набавке:

Услуга.

Поступак јавне набавке се спроводи ради закључења уговора.

4. Контакт:

Сектор за јавне набавке Републичког фонда за здравствено осигурање, Особа за контакт: Xxxxxx Xxxxxxxxx.

Електронска пошта: xxxxxx.xxxxxxxxx@xxxx.xx.

Радно време Републичког фонда за здравствено осигурање је од 07:30 до 15:30 часова, од понедељка до петка.

5. Преузимање конкурсне документације

Конкурсна документација се може преузети са Портала Управе за јавне набавке и интернет странице Наручиоца xxx.xxxx.xx .

6. Подаци о месту и року за подношење понуда

Рок за достављање понуда је до 01.06.2020. године до 11,30 часова.

Понуде се достављају на адресу Републичког фонда за здравствено осигурање, ул. Xxxxxx Xxxxxxxxxx бр. 2, Београд - ПИСАРНИЦА, сваког радног дана у радно време Републичког фонда за здравствено осигурање, од 7:30 до 15:30.

7. Обавештење о месту, дану и сату отварања понуда

Јавно отварање xxxxxx xxxxxxx се 01.06.2020. године у 12,00 часова, у просторијама Републичког фонда за здравствено осигурање у Београду, ул. Xxxxxx Xxxxxxxxxx бр. 2, сала број 3.

II ОПИС ПРЕДМЕТА НАБАВКЕ, НАЗИВ И ОЗНАКА ИЗ ОПШТЕГ РЕЧНИКА НАБАВКЕ

1. Предмет јавне набавке бр. 000-0-000/20-11 је услуга успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО.

2. Предмет јавне набавке није обликован по партијама.

Шифра из Општег речника набавке: 72262000- Услуге израде софтвера, 48620000- Оперативни системи, 72210000- Услуге програмирања софтверских пакет програма, 72266000- Услуге консултовања у вези са софтвером.

III ТЕХНИЧКА СПЕЦИФИКАЦИЈА

Предмет јавне набавке је услуга успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО.

Увод

Републички фонд за здравствено осигурање послује на територији Републике Србије кроз филијале и испоставе, врши послове и пружа услуге које су законом дефинисане. Процес дигиталне трансформације започет је пре више година и тренутно у ИТ екосистему РФЗО постоји више од 30 пословних апликација које су међусобно интегрисане. Како је планиран раст у апликативном домену како би се процес дигитализације и беспапирног пословања подигао на виши степен са цињем потпуне аутоматизације, неопходно је пратити најбољу светску праксу. Један од најбитних корака је успостављање сервисно оријентисане архитектуре у циљу лакше интеграције, централизованог места управљања ингерацијама, повећања безбедности и смањења трошкова будућих интеграција и одржавања.

Сервисно-оријентисана архитектура (СОА) представља резултат еволуције софтверске индустрије у процесу максималне флексибилности, агилности и експанзије. То је стил којим се промовише примена лабавоповезаних сервиса у циљу осигурања максималне пословне флексибилности на интероперабилан и технолошки независан начин. Оно што омогућава интеграцију различитих сервиса и апликација је Enterprise Service Bus (ESB).

Упоредном анализом постојећег стања и захтева које поставља Закон о информационој безбедности (Сл. гласник РС, бр. 6/2016, 94/2017 и 77/2019) закључено је да је потребно набавити и имплементирати решења која допуњују и аутоматизују постојеће процесе везане за размену података и обезбеђење интегритета софтвера и оперативних система (чл. 7. Закона о Информационој безбедности и чл. 19 Уредбе о ближем уређењу мера заштите информационо-комуникационих система од посебног значаја "Службени гласник РС", број 94/2016).

Поред наведеног, као оператер ИТ система од посебног значаја, РФЗО ће имплементирати и решења која директно унапређују безбедност критичних пословних процеса и система.

Планирани сервиси који ће се имплементирати на сервисној магистрали ће између осталог и вршити обезбеђивање интегритета података на критичним системима.

Најчешћи узроци компромитовања података су хакерски напади споља и изнутра и недовољни ресурси посвећени превенцији и недостатак или неадекватне или некориштене безбедносне мере и контроле у погледу руковања и чувања података.

Превенција компромитовања података, увођење строгих мера контроле и заштите података, увођење мера заштите свих компоненти информационог система и ограничење приступа штићеним подацима унутар компаније су иницијалне и основне мере које дају основу за успешно усклађивање и, врло битно, спровођење у пракси (предвиђене су драконске казне за кршење регулативе и губитке података) регулатива о информационој безбедности и заштити података о личности.

Имплементација сервисне магистрале (ЕСБ) мења архитектурални принцип размене података, уводи строге мере контроле и инспекције начина размене података. Будући да је ИТ екосистем сачињен од разнородних апликација које међусобно комуницирају и размењују податке. Додатно постоји потреба размене информација са другим установама, тренутно постоји делимична интеграција системом “point to point”, што представља безбедносни ризик, јер постоји много тачака интеграције и није униформисана интеграција.

На овај начин потенцијални нападачи имају више потенцијалних тачака за напад и за малициозно преузмање података или компромитовање самих система.

Увођење магистрале, доноси “loosely coupled” начин интеграције тј. по једну тачку и централни систем за интеграцију, приступ магистрали је строго контролисан, тј неопходна је аутентикација.

Активности које аутентификовани системи могу да раде су контролисани ауторизацијом тако да сваки упит и захтев за размену података иде преко магистрале и могу га иницирати и извршити само аутентификовани и ауторизовани системи / корисници.

Будући да ЕСБ архитектура контролише начин на који се крећу подаци, олакшава промену компоненти система или додавање додатних компоненти у апликацију.

Будући да ЕСБ има увид у све система, такође нуди погодно место за спровођење безбедносних захтева, евидентира промене и догађаје и надгледан извршења трансакција.

Имплементација ЕСБ обезбеђује сигурно управљање идентитетима тако да је неопходно извршити аутентикацију и ауторизацију у процесу сваке трансакције и на тај начин се недвосмислено потврђује идентитет и смањује се шанса за компромитовање података и система.

Оваквим приступом се значајно подиже ниво безбедности свих апликација и ИТ екосистема уопштено.

Оваквим приступом олакашавамо и интеграцију и размену података са спољним институцијама на начин да су им видљиви јединствени униформисани сервиси за интеграцију и размену података, који омогућавају безбедан и аутоматизован начин комуникације.

Оваква аутоматизација сигурне размене података смањује потребу за употребом курира и смањује међуљудске контакте, што је у тренутној ситуацији неопходно како би се избегао непотребан физички контакт.

Набавка укључује:

• Софтвер за интеграцију апликација и наменски интеграциони „security gateway appliance“ (2 комада) (фаза 1)

• Услуге анализе и редизајна пословних процеса (фаза 2)

• Услуге пословне анализе за потребе имплементације СОА (фаза 3)

• Услугу модификације постојећих „web“ сервиса за потребе излагања на ЕСБ (фаза 4)

• Услугу развоја нових „web” сервиса за потребе излагања на ЕСБ (фаза 5)

• Услугу развоја и излагања „web“ сервиса за потребе интеграције са спољним сарадницима (фаза 6)

• Услуге гаранције

Спецификације софтвера и наменског уређаја

Извршилац мора да испоручи савремену интеграциону софтверску платфому која ће задовољити дугорочне потребе у домену интеграција система.

Платформа мора да има два дела:

• Софтвер за интеграцију апликација који мора бити испоручен као софтвер у складу са захтевима из поглавља 1.

• Интеграциони „security gateway“ који мора бити испоручен као appliance у складу са захтевима из поглавља 2.

Комплетан систем мора бити комерцијални, „open source“ није прихватљив из разлога комплексности, важности система, расположивих ресурса и информационе безбедности.

Комплетан систем, оба модула морају бити од истог произвођача.

1. Софтвер за интеграцију апликација

Из разлога флексиблности, универзалности и могућности примене у хетерогеним оркужењима, платформа треба да буде независна од једног технолошког домена и да буде подржана на више платформи.

Систем треба да подржава Linux Redhat Enterprise Server и Suse Linux Enterprise Server, Windows Server. Систем мора да подржава рад и да буде инсталиран на VMware виртуализованом окружењу.

Систем мора да подржава рад у Docker контејнеру. Систем мора да подржава могућност рада где би било више дистрибуираних ’run-time’ који раде у Doker контејнерима, а да при томе је могућ рад из једног развојног окружења.

Систем мора да буде подржан за рад на Redhat OpenShift Container Platform и сертификован од стране Redhat.

Систем треба да буде stand-alone апликација и из разлога перформанси не треба да захтева базу података за нормалан рад. (систем не треба да записује све поруке у базу ради боље пропусности система, осим ако сам developer не жели да упише неке податке у базу, када је потребно користити неку од стандардних SQL екстерних база).

Систем треба да буде stand alone апликација која за свој рад не тражи додатне софтверске компоненте и софтверску инфраструктуру, поготово не 3rd party.

Извршилац мора да испоручи све што је потребно за нормалан рад Система. Систем треба да има следеће основне функције:

а. Интеграциона логика:

Систем мора да има механизам за процесирање порука према „pipes and filters“ архитектуралном стилу. Улаз у ток за обраду порука може да буде било који од подржаних протокола или интеграционих механизама, такође и излаз. Ток треба да се састоји и ‘гради’ од градивних елемената од којих сваки треба да има одређену функцију у процесирању поруке, укључујучи и могућност уградње програмског кода који ће се извршавати на систему у том датом току и дати могућност произвољне обраде поруке. Због флексибилности и независности платофрме, потребно је да буду подржани Јаva и .NET језици.

Систем мора имати низ предефинисаних функција које су расположиве као градивни елементи тока обраде поруке и доступни за лаку ‘уградњу’ у ток поруке кроз развојно окружење. Описати расположиве функције.

Систем мора да има и предефинисану подршку ра различите протоколе и интеграционе методе са системима који ће бити интгрисани са платформом. Подршка мора да буде у виду готових адаптера или сличних механизама који треба да омогуће интеграцију са протоколима без програмирања или уз минимално програмирање, користећи готове платформске функције.

Систем мора да подржава следеће протоколе, самим функцијама система, без помоћи ‘3rd party’ алата:

HTTP/HTTPS, SOAP, REST, Email (POP3, IMAP, SMTP), FTP/SFTP, JMS, Socket, Интеграција са релационим базама путем JDBC и ODBC, МQТТ, IBM МQ, директна интеграција са фајловима на локалном или удаљеном систему (FTP/SFTP), Corba.

Систем мора да има готов ‘Off the Shelf’ адаптер за интеграцију са SAP. Овај адаптер не треба да има посебну лиценцу нити лиценцне лимитације по питању интеграције са SAP, већ мора бити укључен у лиценцу основног система. Адаптер треба да омогући конекцију на SAP уз аутентификацију, откривање сервиса и генерисање објеката и интерфјеса без програмирања, који су након тога доступни за даљу манипулацију у токовима обраде порука на систему. Адаптер за SAP треба да подржи AEP и АLЕ за inbound процесирање, као и BAPи, АЕP; АLЕ, QISS за outbound процесирање.

Систем мора да има message quе механизам (МQ), модул или компоненту за подршку поузданој асинхроној размени порука.

б. Рутирање порука:

Систем треба да има могућност рутирања порука, тј. креирања токова обраде поруке који могу имати више дестинација, базирано на садржају поруке или евалуацији неког параметра поруке.

Систем мора да подржи динамичко рутирање базирано на садржају поруке. Систем мора да има могућности сервисне оркестрације.

ц. Трансформација порука:

Систем треба да им могућност трансформације порука у смислу промене протокола интеграције, транспортног протокола, формата података или самог садржаја поруке. Систем мора да пружи ове функције у ‘low code’ или ‘zero code’ приступу, кроз предефинсане функције и уз минимално програмирање.

Систем мора да има и могућност графичког мапирања порука.

Систем мора да подржава DFDL стандард и графичко мапирање мора бити доступно и за DFDL обраду non-XМL порука.

Систем мора да омогући динамичку трансформацију и транслацију порука, укључујући садржај и контекст поруке.

Систем мора да подржава трансформације протокола комуникације. Нпр. да улазна порука долази путем wеb сервиса, а да се порука проследи даље као текстуална порука путем FTP или кроз МQ.

д. Интероперабилност између различитих технолошких целина:

Ова функционалност је веома важна због хетерогеног окружења са којим ће се суочити овај систем Посебно Јаva-.NET интероперабилност мора бити подржана функцијама система, без потребе за ‘3rd party’ додацима или алатима.

Систем мора да има готов модул или адаптер за интеграцију са messaging и event processing системима. Лиценца система мора да омогући употребу МQ и Enterprise едиције event processing система базираног на Аpache Кафка. (капацитет виртуалних core који би се одвојио на ове компоненте би се рачунао у укупном броју лиценци које систем користи, тј. ове компоненте би се лиценцирале из укупне количине набављених лиценци).

е. Трансформација путем слободног програмског кода

Систем мора имати могућност да се у ток обраде поруке директно ургади произвољни програмски код. Xxxx x .NЕТ морају бити подржани. Елементи за прихват кода морају бити градивни елементи тока обраде поруке, да буду саставни део тока, користе све функције система за ток обраде поруке (да лако могу да прилагоде улазну и излазну поруку остатку логике обраде поруке) и да буду и окружење за извршавање кода. (тј. код мора да се извршава на систему као саставни део тока обраде порука у рунтиме где се извршава и остатак тока интеграције). Развој кода за Јава језик мора да буде директно у IDЕ система, док за развој .NЕТ кода мора да постоји интеграција са екстерним Microsoft Visual Studio.

ф. Логовање и audit trail

Систем мора имати могућност логовање различитог сета информација у локалне фајлове. Посебно биће обезбеђена SQL база података и систем мора у ту базу да смешта централизовано изабране лог информације или информације за каснији аудит.

Систем мора имати графичко интегрисано развојно окружење (IDЕ) у коме ће се, уз графичку подршку развијати токови за обраду порука и реализовати све поменуте функције система.

Систем мора да има на располагању палету градивних елеманата који су на располагању за изградњу тока обраде порука у графичком ‘drag and drop’ моду и са акцентом на параметризацију и писање кода само где је неопходно.

IDЕ мора да подржи и деплоyмент и мора бити једноставан процес. Систем мора да подржи да се директно ‘drag and drop’ методом уради деплоyмент готовог тока обраде порука на локални или удаљени систем (нпр. са тесног на продукционо окружење). IDЕ мора да подржи и мониторинг токова интеграције који су у рунтиме. Деплоyмент артефакт мора бити компактан и могућ за ефикасну интеграцију у CI-CD пипелине.

Систем мора да подржи и debugging, укључујучи и визуелни debugging (step by step).

IDЕ не може да има лиценцно ограничење по кориснику, нити било какву посебну лиценцу за IDЕ.

Систем мора да има добру подршку за REST API. Систем мора имати механизам за графички импорт Swagger фајла и аутоматског креирања основе REST API.

Систем мора имати графички wizzard за креирање REST API, те могућност експорта Swagger фајла за креирани REST.

Систем мора да има могућност импорта Swagger фајла екстерног REST API и ефикасне подршке позивању екстерног REST API.

Систем мора да подржава XML базиране Web Services. Систем мора да подржава SOAP 1.1, SOAP 1.2 и SOAP with Attachments (SwА) и МТОМ. Систем мора да подржава WS-Addressing, WS-Security, WS-RМ стандарде.Систем мора да подржава WS-I Basic Profile.

Развој wеб сервиса мора да буде подржан тако постоје градивни елементи који се лако могу уградити у ток обраде поруке, на почетак или крај или у сам ток на произвољном месту, а да омогућавају ефикасно позивање екстерног wеb сервиса, истурање wеb сервиса у датој тачки, те екстракцију тела поруке или додавање SOAP енвелопе порукама. Градивни елементи морају бити потпуно интеграбилни у ток обраде поруке, са свим осталим расположивим елементима и на тај начин омогуће широк спектар функција обраде порука које се размењују путем wеb сервиса, или уградњу wеb сервиса у сложене токове.

Из разлога перформанси систем не треба да буде искључиво базиран а XML и не треба обавезно да конвертује поруке које нису изворно XML у XМL да би их обрадио.

Систем треба да подржава обраду фајл базираних порука, без конверзије у XМL и без персистенције у базу података.

Систем треба да подржава конверзију између XМL формата у не XМL и обратно.

Систем мора да омогући детаљан audit trail у екстерну базу података, са уписом основног сета података

– објекат, акција над објектом, време и корисник који је покренуо акцију. Систем мора да омогући интеграцију са екстерним Active Directory.

Систем мора да подржава TLS/SSL енкрипцију. На нивоу транспорта за HTTP протокол. Систем мора да подржава SAML.

Систем мора да подржава WS-Security стандард.

Систем мора да подржава publish-subscribe механизам-тј. креирање и подршку за publish-subscribe сервисе.

Систем мора да подржава следеће специфичне функције за рад са фајловима:

• Учитавање фајлова са локалног диска, или са удаљене локације путем FTP или SFTP протокола.

• Трансформација фајла без обавезне конверзије у XМL. Трансформација може да укључи промену самог фајла, али и конверзију у неки други формат.

• Промена формата поруке ако је поребно генерисати поруку из фајла.

• Примена custom логике кроз имплементацију програмског кода.

• Упис у фајл, тј, креирање филе базиране поруке из поруке која је већ фајл базирана или не, без обавезне конверзије у XМL. Мора да постоји могућност акције на локалном диску или удаљеном путем FTP. Мора да постоји могућност креирања новог фајла и писање на крај постојећег.

За потребе тестирања система, систем мора имати функције праћења порука и debugging-а у оквиру IDE. Ради лакшег рада развојних инжењера, ова функција мора бити графичка, као део укупног IDE.

Систем мора да омогући ефикасан деплоy директно из IDE. Систе мора да омогући креирање пакета за deploy, као и директан деплоy пакета на локални сервер или удаљене сервере, из истог окружења.

Систем мора да омогући да се на једном серверу дефинишу и други удаљени сервери, да би било изводљиво да се уради deploy на удаљени сервер, нпр са тестног на продукциони сервер.

Систем мора да омогући и re-deploy пакета који су већ у runtime.

Deploy процес не треба да повлачи рестарт система, или било какво заустављање рада рунтиме, те одмах по процесу деплоyа, нови или промењени токови обраде морају бити на располагању у runtime, за све нове поруке које долазе у систем.

Систем мора да има административну конзолу или GUI за администрацију основних параметрара система. Систем мора да истури и административне функције кроз API.

Потребно је понудити лиценце за 8 виртуалних језгара за рад у VMware виртуалним машинама за продукцију, те 2 виртуална језгра за потребе не-продукционог окружења. Лиценце треба да садрже и годину дана гаранције произвођача, рачунајући од испоруке софтвера.

Лиценце морају да укључују и право употребе MQ софтвера, „event processing“ система базираног на Apache Kafka уз ентерприсе подршку, API Management, као и софтверског интеграционог „gateway“ (софтверска варијанта која може да ради као VMware виртуална машина или као Doker контејнер), а све до укупног купљеног капацитета. Капацитет виртуалних језгара који би се одвојио на ове компоненте би се рачунао у укупном броју лиценци које систем користи, тј. ове компоненте би се лиценцирале из укупне количине лиценци. РФЗО овим постиже пуну флексибилност употребе било које интеграционе функције, у оквиру исте лиценце и набављене количине.

2. Интеграциони security gateway

Gateway мора да буде хардверски уређај и мора да буде погодан за имплементацију у ДМЗ зону. Потребно је испоручити 2 уређаја.

Тражени уређај је јединствена, модуларна Gateway платформа, и представља наменски изграђен мрежни уређај за обезбеђивање заштите протокола које користе XМL/ЈSON формат података (SOAP / REST / Web Service), за потребе обезбеђивања екстерних интеграција.

Уређај пружа графички начин конфигурисања тока процесирања за сваки од Wеb сервиса који штити. Ток процесирања треба да подржи архитектурални стил познат као Pipes and Filters.

Конфигурисање тока процесирања треба да подржи тзв. „drag and drop“ начин убацивања процесних компоненти (филтера). Основне процесне компоненте које уређај треба да изврши над поруком (како приликом прихватања улазне поруке, тако и приликом враћања одговора) су енкрипција и декрипција, провера садржаја, заштита од свих врста напада на нивоу поруке, дигитално потписивање и провера потписа, аутентификација и ауторизација пошиљаоца, журнализовање, контрола протока. Сви ови филтери треба да буду обезбеђени у уређају, а конфигурација самих филтера у конкретном сценарију (нпр. локација репозиторијума аутентификационих и ауторизационих података) треба да буде једноставна и интуитивна.

Физички уређај мора да буде tamper-proof (тј. да се аутоматски искључује у случају отварања), произведен од стране произвођача као интегрисани систем са специјализованим хардвером, прилагођеним одговарајућим firmware-om и уграђеним ОС (оперативним системом).

Уређај мора да има строго контролисан начин приступа свим подацима који се на њему налазе, не сме да поседује непотребне портове.

Уређај мора да спречи инсталацију интерпретера било ког програмског језика.

Физички уређај мора да буде Rack-mountable (уградљив у рек орман) мрежни уређај дизајниран да се уклопи у стандардни индустријски рек орман. Повезивање на мрежу је преко Ethernet-а.

Физички уређај мора да има минимално следеће карактеристике:

• Form Factor: 2U

• Процесори: 2x 12-core 2.60 GHz Интел или боље

• Хард диск: 2x 1200 GB HDD (RAID 1)

• Меморија: 192 GB (Twelve 2666 MHz DDR4 DIMMs).

Уређај мора да штити против напада као што су XML Denial of Service (XDoS), преливање бафера, односно рањивости од намерно или ненамерно креираних малициозних XML докумената.

Уређај мора да подржава транспортне протоколе HTTP, HTTPS, FTP, sFTP, SMTP. Уређај мора да омогући превођење транспортних протокола.

Уређај мора да служи као јединствена тачка контакта и форсирања полиса за WЕB/SОА/Mobile саобраћај.

Уређај треба да има могућност да делује као јединствена тачка спровођења правила, односно као централни подсистем који ће контролисати све дефинисане политике – (аутентификацију, ауторизацију, валидацију, итд.).

Уређај мора да подржава барем ове методе шифровања или криптовања: XKMS, RSA, 3DES, DES, AES, ŠA, X.509, PKCS, CRLs, OCSP, XML, дигитални потпис, SSL.

Уређај мора да подржава енкрипције / потписивање како на нивоу поља тако и на нивоу докумената.

Уређај мора да подржава различите механизме за контролу приступа, укључујући OAuth 2.0, XACML, Security Assertion Markup Lamguage (SAML), SSL, TLS, LDAP, RADIUS, и једноставне клијент / URL табеле.

Уређај мора да подржава SSL верзије 2 и 3.

Уређај мора да подржава TLS верзије 1.0, 1.1 и 1.2. Уређај мора да подржава све WS-* стандарде.

Уређај мора да подржава WS-Policy Framework и WS-Policy Attachment. Уређај треба аутоматски да убацује WS-Policy мета податке у WSDL, како би клијенти аутоматски могли да генеришу захтеве који одговарају задатим полисама.

Уређај мора да подржава SAML верзије 1.0, 1.1 и 2.0.

За проверу идентитета корисника, уређај треба да обезбеди могућност да корисници буду проверени валидацијом сертификата, вађењем идентитета из различитих безбедносних токена који се налазе у заглављу поруке / протокола, и провером на спољним (нпр. LDAP) или унутрашњим (високо безбедним) репозиторијумима идентитета.

СПИСАК И КРАТАК ОПИС АПЛИКАЦИЈА КОЈЕ ЈЕ ПОТРЕБНО НАДОГРАДИТИ ФУНКЦИОНАЛНОСТИМА ВЕБ СЕРВИСА ИЛИ ЧИЈЕ ПОСТОЈЕЋЕ ВЕБ СЕРВИСЕ ТРЕБА ПРИЛАГОДИТИ ЕСБ

1. Систем за евиденцију уговорених здравствених радника и стоматолога

Кратак опис система

Систем за евиденцију уговорених здравствених радника представља централну евиденцију уговорених здравствених радника по свакој здравственој установи са којом РФЗО има уговор. На основу евиденције уговорених радника обрачунавају се потребна средстава за зараде уговорених радника. Систем даје статистику о броју и структури уговорених радника. Систем за евиденцију стоматолога уговорених у здравственим установама из плана мреже омогућава планирање средстава за плате у установама са којима РФЗО има уговор, као и статистику о броју и структури уговорених стоматолога.

Опис пословног процеса - Систем за евиденцију уговорених здравствених радника

У филијалама се уносе подаци из образаца пријава/промена/одјава добијених од здравствених установа и добијају прегледи за установе са подручја филијале. Поред личних података и основних података о запослењу, води се и евиденција о одсуствима - неактивностима дужим од 30 дана (боловања, специјализације, неплаћено,..) и заменама ангажованим за одсутне уговорене раднике (када се евидентира престанак одсуства, радник на замени се аутоматски одјављује уколико је евидентиран). За лекаре у примарној здравственој заштити, води се и евиденција о пунктовима (здравствене станице, амбуланте) на којима су ангажовани.

Опис пословног процеса - Систем за евиденцију стоматолога

Здравствене установе са којима РФЗО има уговор о финансирању зарада, матичној филијали шаљу попуњене обрасце пријава/промена/одјава за своје раднике које уговарају. У филијалама се уносе подаци из образаца пријава/промена/одјава добијених од здравствених установа и добијају прегледи за установе са подручја филијале. Поред личних података и основних података о запослењу, води се и евиденција о одсуствима-неактивностима дужим од 30 дана (боловања, специјализације, неплаћено,..) и заменама ангажованим за одсутне уговорене стоматологе (када се евидентира престанак одсуства, радник на замени се аутоматски одјављује уколико је евидентиран). Контрола уноса новог радника у односу на кадровски план гледа број радника за установу, службу и занимање.

Корисници апликације

Дирекција РФЗО, филијале РФЗО - сви запослени у РФЗО на пословима уговарања и контроле здравствене заштите.

Техничке карактеристике система

DBMS server, aplikativni server: Windows 2008 R2, Apache Tomcat 6.1, Java 1.6, MS SQL server.

Опис система за управљање базом података DBMS који се користи је MS SQL server 2005.

Комуникација са другим DBMS

Код пријаве новог радника врши се провера полисе радника у бази матичне евиденције и остваривања права (MS SQL 2016).

Делови система

Систем за евиденцију уговорених здравствених радника обухвата:

- Wеб апликација за унос података, преглед и штампу извештаја;

- Подсистем за аутоматску времеснку проверу полиса;

- Помоћне базе за израду нестандардних извештаја, ажурирање кадровских планова за уговорене раднике и уговорене стоматологе, као и ажурирање шифарника пунктова.

Систем за евиденцију стоматолога обухвата:

- Wеб апликација за унос података, преглед и штампу извештаја;

- Подсистем за аутоматску времеснку проверу полиса;

2. Апликација за подршку вођења листе за вантелесну оплодњу

Кратак опис система

Овај систем омогућава праћење издавања образаца за поступак БМПО, добијање информација о току поступка, опредељивање осигураница за установу у којој ће обавити поступак и добијање стандардних извештаја.

Опис пословног процеса

РФЗО финансира до три покушаја БМПО (биомедицински потпомогнуто оплођење). Осигуранице заинтересоване за поступак БМПО јављају се са упутом изабраног гинеколога својој филијали РФЗО. Лекарска комисија филијале процењује формално правну исправност документације и издаје упут за лекарску комисију установе (образац ОЛК-11) која одобрава или не одобрава укључивање у поступак. При добијању ОЛК-11 обрасца, осигураница се изјашњава да ли је заинтересована за замрзавање и чување вишка добијених ембриона (уколико их буде било) и потписује образац о установи жеље (у којој од установа на располагању би желела да се обави процедура БМПО).

Установа са портала РФЗО преузима податке о лицима упућеним на њихову комисију и учитава их у локалну апликацију. Након доношења одлуке, установа путем слања пакета података формираних из локалне апликације обавештава Фонд о донетим одлукама и статусу осигураника који су у поступку. Након преузимања пакета и учитавања у централну базу Фонда, подаци су видљиви у централној евиденцији. Осигуранице које су добиле позитивну одлуку комисије ЗУ, чекају позив комисије фонда ради добијања упута на процедуру БМПО (образац ОЛК-12).

Одговорно лице у Дирекцији РФЗО врши опредељивање на основу жеље осигуранице и расположивих капацитета. Из помоћне акцес апликације формира се табеларни преглед опредељених осигураница и проследјује одговорном лицу у Дирекцији. Подаци из ове табеле се разврставају по установама и проследјују истим. Установе враћају ове табеле са уписаним датумима пријема на процедуру (заказивање). Примљени подаци се обједињују и шаљу лекарским комисијама филијала.

Комисије филијала, на основу ових података позивају по редоследу датума осигуранице и издају им упуте на процедуру БМПО (ОЛК-12).

Установа са портала РФЗО преузима податке и о лицима упућеним на процедуру БМПО (у истом пакету су и подаци о упућивању на комисију и подаци о упућивању на процедуру), и учитава их у локалну апликацију. Осигуранице се примају по редоследу заказивања и уводе у процедуру. Установа у локалној апликацији ажурира и податке о току поступка (датум консултације, стимулације, исход процедуре, број замрзнутих ембриона и где се чувају..). У пакетима које ЗУ шаље Фонду су и подаци о раду комисије установе и подаци о току и исходу процедура. Након учитавања пакета у РФЗО, у централној апликацији су видљиви и подаци о току и исходима процедура.

Корисници апликације

Дирекција РФЗО, лекарске комисије РФЗО (МеОп – матична евиденција и оствариваје права), здравствене установе (локална апликација).

Техничке карактеристике система

Платформе помоћу којих се систем извршава: MS Windows, Java, Delphi, MS SQL server, internet portal RFZO, MeOp->апликација за остваривање права -> рад лекарских комисија у фиијалама.

Опис система за управљање базом података DBMS који се користи је MS SQL server 2005 .

Комуникација са другим DBMS

Постоји веза са системом за матичну евиденцију и остваривање права (MS SQL 2016).

Делови система

Систем је састављен од 4 апликације и то:

- Desktop апликације за здравствене установе. Инсталира се у установи са којом Фонд има уговор о пружању услуга БМПО. Улазни подаци се учитавају са интернет портала Фонда где свака установа приступа преко своје шифре тако да може да преузме само своје податке. Установа ажурира податке о раду комисије (ако има комисију ЗУ за БМПО) и податке о току поступка, периодично формира пакете са подацима за слање РФЗО и шаље их електронском поштом надлежној филијали Фонда. Апликација је рађена у Delphi-ju а база је MS Access. Предвиђено је да се ради на једном рачунару;

- Централна евиденција. Web апликација на локалном серверу РФЗО која омогућава учитавање података добијених од установа, претрагу података, опредељивање осигураница за установу у којој ће обавити поступак, добијање стандардних извештаја, администрирање корисничких налога. Web апликација је урађена у Javi, а база је MS SQL server;

- Помоћна апликација за: учитавање података добијених из Евиденције рада лекарских комисија Филијала, генерисање пакета за објављивање на инфо порталу Фонда (одакле их преузимају установе), формирање текстуалних датотека са подацима о опредељивању осигураница (за пребацивање у филијале да би се омогућило издавање ОЛК12 образаца), подешавање бројача пакета. Апликација је рађена у Delphi-ju;

- Помоћна апликација за упис .тxт фајлова генерисаних апликацијом из претходне тачке у филијалске базе налази се на локалном серверу РФЗО;

- Помоћна апликација за учитавање података из MeOp - рад лекарских комисија, контролу и пребацивање у централну базу. Сxxxxx x упит за извештаје о ново опредељеним осигураницама, као и упите за нестандардне извештаје;

- Упит за издвајање (експорт) података из централне базе MeOp - налази се на локалном сервер РФЗО. Овим упитом се издвајају подаци о осигураним лицима и пребацују у транспортну MS Access базу за контролу и учитавање у централну.

3. Портал финансија намењен здравственим установама

Кратак опис система

Овај систем омогућава управљање подацима достављених од стране свих здравствених установа примарног, секундарног и терцијарног нивоа, у циљу ефикаснијег управљања и контроле трошкова лечења осигураних лица. Такође, овај систем омогућава управљање подацима у вези са директним плаћањем РФЗО према добављачима, у име и за рачун здравствених установа.

Опис пословног процеса

У циљу испуњавања Инструкције за ефикасније управљање и контролу трошкова лечења осигураних лица, здравствене установе примарног, секундарног и терцијарног нивоа су у обавези да достављају следеће скупове података:

1. Стање залиха лекова на дневном нивоу

2. Стање залиха лекова на дневном нивоу

3. Стање залиха материјала на дневном нивоу

4. Стање залиха материјала на дневном нивоу

5. Стања залиха / нови улази лекова од 01.03.2019. године

6. Стања залиха / нови улази материјала од 01.03.2019. године

7. Утрошак лекова на годишњем нивоу

8. Утрошак материјала на годишњем нивоу

9. Утрошак лекова од 01.03.2019. године на месечном нивоу

10. Утрошак материјала од 01.03.2019. године на месечном нивоу

11. Обавезе ЗУ према добављачима (фактуре)

12. Књижна одобрења

13. Књижна одобрења (струја и гас)

14. Укупне обавезе према добављачима на задати дан

15. Укупне обавезе према добављачима на задати дан

16. Стање обавеза према добављачима на дан, усаглашено између ЗУ и добављача, на задати дан

17. Стање обавеза према добављачима на дан, усаглашено између ЗУ и добављача, на задати дан

18. Обавезе ЗУ према добављачима за струју и гас

19. Уговори ЗУ и добављача

Наведене скупове података могуће је достављати посредством веб сервиса, као и учитавањем предефинисаних фајлова (txt, csv, xml). Групе података у вези са директним плаћањем (11,12,13,18 и 19) обухватају додатне функционалности:

o Мануелно учитавање скенираних докумената у вези са уговором и свим везаним фактурама; о Замена постојећих докумената новим, на захтев РФЗО;

о Потврђивање фактура (електронска ликвидација) од стране здравствене установе; о Решавање рекламација упућених од стране РФЗО.

Систем омогућава праћење статуса обраде и плаћања појединачне фактуре. Систем омогућава увид у све податке достављене од стране здравствене установе.

Систем омогућава експорт свих скупова података у еxцел формат, као и података о извршеном плаћању фактура у име и за рачун здравствених установа, у циљу прокњижавања истих на страин здравствене установе.

Корисници апликације

Све здравствене установе примарног, секундарног и терцијарног нивоа, филијале и дирекција Републичког фонда, добављачи (фармацеутске компаније).

Техничке карактеристике система

Linux, Apache, PHP7+, MariaDB 10.4.6, JavaScript, HTML 5, CSS, Perl 5.16.3.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Постоји веза са системима Пут лека, Електронска фактура, МЕОП и NextBiz финансијски систем.

Делови система

Систем је састављен од следећих целина:

- Унос и управљање скенираном документацијом;

- Унос и управљање подацима достављених посредством веб сервиса;

- Управљање поадацима у вези са ефикаснијим управљањем и трошковима лечења осигураних лица;

- Управљање подацима у вези са директним плаћањем.

4. Портал финансија намењен филијалама и Дирекцији РФЗО

Кратак опис система

Опис пословног процеса

1. Стање залиха лекова на дневном нивоу

2. Стање залиха лекова на дневном нивоу

3. Стање залиха материјала на дневном нивоу

4. Стање залиха материјала на дневном нивоу

5. Стања залиха / нови улази лекова од 01.03.2019. године

6. Стања залиха / нови улази материјала од 01.03.2019. године

7. Утрошак лекова на годишњем нивоу

8. Утрошак материјала на годишњем нивоу

9. Xxxxxxx xxxxxx од 01.03.2019. године на месечном нивоу

10. Утрошак материјала од 01.03.2019. године на месечном нивоу

11. Обавезе ЗУ према добављачима (фактуре)

12. Књижна одобрења

13. Књижна одобрења (струја и гас)

14. Укупне обавезе према добављачима на задати дан

15. Укупне обавезе према добављачима на задати дан

16. Стање обавеза према добављачима на дан, усаглашено између ЗУ и добављача, на задати дан

17. Стање обавеза према добављачима на дан, усаглашено између ЗУ и добављача, на задати дан

18. Обавезе ЗУ према добављачима за струју и гас

19. Уговори ЗУ и добављача

Филијале РФЗО имају увид у наведене податке свих здравствених установа на њиховој територији. Након увида и контроле достављених података у вези са директним плаћањем, филијала РФЗО врши потврђивање података о фактури и уговору према Дирекцији РФЗО, односно упућује рекламацију здравственој установи. Такође, филијала РФЗО прати статус обраде фактуре с обзиром да Дирекција РФЗО може упутити рекламацију према филијали у случају откривања неправилности.

Дирекција РФЗО има увид у податке свих здравствених установа, укључујући и статусе потврђивања фактуре од стране здравстене установе и филијале. Дирекција РФЗО има могућност напредне аналитике свих скупова података (стања залиха, утрошака, нових улаза у централну апотеку здравствене установе, уговора и фактура). Дирекција РФЗО осим напредне аналитике врши додатну анализу и контролу фактура за потребе директног плаћања према добављачима у име и за рачун здравствених установа. Потврђивањем фактура које су претходно потврђене од стране здравствене установе, одобрене од стране филијале, које су прошле аутоматску контролу са подацима достављеним од стране добављача и које су усаглашене са подацима у Централном регистру фактура Управе за трезор, Дирекција врши трансфер података у финансијски систем из кога се врши плаћање. Део Портала намењеног Дирекцији односи се на администрирање система: управљање шифарницима, корисницима и њиховим правима, трансферу података према екстерним системима и управљање подацима упућених од стране екстерних система.

Корисници апликације

Филијале и Дирекција Републичког фонда.

Техничке карактеристике система

Linux, Apache, PHP7+, MariaDB 10.4.6, JavaScript, HTML 5, CSS, Perl 5.16.3.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Постоји веза са системима Пут лека, Електронска фактура, МЕОП и NextBiz финансијски систем.

Делови система

Систем је састављен од следећих целина:

- Управљање поадацима у вези са ефикаснијим управљањем и трошковима лечења осигураних лица;

- Управљање подацима у вези са директним плаћањем;

- Администрирање система;

- Управљање комуникацијом са екстерним системима.

5. Апликација за евиденцију упућивања осигураника на лечење у иностранство Кратак опис система

Овај систем омогућава евиденцију предмета везних за упућивање осигураника на лечење у иностранство.

Опис пословног процеса

Здравствене установе предлажу упућивање на лечење у иностранство. За сваки добијени предлог формира се предмет. Комисија фонда на својим заседањима одлучује о поднетим предметима. У комисији су лекари специјалисти из разних области медицине, а заседања се организују по областима.

Уз одлуку о упућивању у одређену установу, доноси се и одлука о врсти превоза и висини аконтације. О једном предмету комисија може одлучивати на више заседања. После повратка са лечења осигураник подноси документа којима правда аконтацију (авионске карте, хотелске рачуне, и сл.). Инострана установа подноси фонду рачун за извршене услуге.

Корисници апликације

Дирекција РФЗО - одељење за инострано осигурање.

Техничке карактеристике система

Платформе помоћу којих се систем извршава: MS Windows, MS Acces.

Опис система за управљање базом података DBMS који се користи је MS SQL server 2005.

Комуникација са другим DBMS

Не постоји веза са другим DBMS.

Делови система

Систем се састоји од следећих целина:

- Access апликација за унос података, преглед и штампу извештаја. Налази се на рачунару у организационој јединици задуженој за упућивање на лечење у инотранство код референта задуженог за унос података;

- Подаци о предметима могу да се воде по свим релевантним обележјима: подаци о осигуранику, установа која даје предлог, упутна дијагноза, установа у коју се упућује (и, евентуално, лекар код кога се шаље), заседања комисије (чланови комисије, датум заседања комисије и одлука), подаци о кретању предмета (начин решења, одобравање аконтације, коначни обрачун), подаци о правданим трошковима (фактуре и сл.);

- Омогућено је и праћење рада комисије (чланови комисије, заседања, разматрани предмети) и штампа записника.

6. Централизоване јавне набавке Кратак опис система

За потребе Сектора за јавне набавке, развијен је софтверски подсистем намењен праћењу и извештавању централизованих јавних набавки. Овај систем има своју употребну вредност и на страни екстерних корисника, у овом случају свих здравствених установа. На овај начин, обезбеђено је оптимално управљање и планирање уговорених количина лекова и уградних материјала, са потребом месечног извештавања о испорученим и утрошеним количинама, као и количинама на залихама. Такође, посебан модул овог система обухвата финансијско извештавање.

Опис пословног процеса

РФЗО спроводи централизоване поступке јавних набавки. Након реализације поступка, креирају се електронски шифарници поступака који се учитавају у апликацију и на тај начин постају доступни здравственим установама, али и РФЗО у циљу даље администрације и извештавања. Поступци су раздвојени на лекове и уградне и потрошне материјале. РФЗО креира нове кориснике, омогућава унос

података, администрира уносе месечне иницијалне и месечне уносе здравствених установа, управља мануелним уносима здравствених установа, као и XML уносима које здравствене установе достављају кроз посебан сервис. РФЗО креира финансијске извештаје на основу уноса здравствених установа, врши контролу уноса података и за потребе пословних процеса управљања и одлучивања у јавним набавкама користи низ расположивих аналитичких извештаја о уговореним количинама и извештаја о потрошњи (месечни извештаји). Здравствене установе уносе податке о уговореним количинама за сваки поступак, затим податке о евентуалним додатним уговорима и месечне извештаје о потрошњи. Податке је могуће уносити мануелно и учитавањем XML фајла. Између здравствених установа и РФЗО омогућена је електронска комуникација кроз апликацију.

Корисници апликације

Дирекција РФЗО – Сектор за јавне набавке, све здравствене установе.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS, клијентски сертификати за аутентификацију корисника.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Не постоји веза са другим DBMS.

Делови система

Систем се састоји из четири целине:

- Веб апликација за здравствене установе у којој су доступне инпут форме за унос и администрирање података;

- Веб апликација за учитавање и обраду XML фајлова достављених од стране здравствених установа;

- Веб апликација за Сектор за јавне набавке Дирекције РФЗО у којој се врше активности као што је описано у поглављу “Опис пословног процеса”;

- Веб апликација у Сектору за развоја и информационе технологије помоћу које се врши учитавање шифарника из поступака централизованих јавних набавки.

7. DMS Лекови Кратак опис система

Електронски систем за предају, обраду и контролу захтева за стављање лека на Листу лекова РФЗО, као и за промену цене лека. Апликација је намењена свим носиоцима дозвола, члановима стручних комисија (Републичке стручне комисије, Централна комисија за лекове, Комисија за фармакоекономију), као и запосленима у оквиру Сектора за лекове РФЗО. Осим подношења и допуне документације, апликација омогућава увид у последњи статус обраде захтева, као и у историју обраде захтева.

Опис пословног процеса

Носиоци дозвола електронским путем подносе захтев за стављање лека на листу лекова или захтев за промену цене лека. Осим попуњавања предефинисаних инпут форми, на располагању им је могућност да приложе документацију у ПДФ формату. Након ове активности, носилац дозволе подноси захтев и на писарници Дирекције РФЗО, где се захтев заводи, при чему се у апликацију уноси заводни број. Сектор за лекове Дирекције РФЗО добија обавештење кроз апликацију о новом захтеву, прихвата га, након чега носилац дозволе добија електронску информацију (емаил) о томе да је захтев узет у обраду или је сторниран. Све до краја процеса обраде захтева носилац има могућност да прати статусе (фазе) обраде захтева. Уколико Сектор за лекове утврди да документација није потпуна, кроз апликацију се упућује електронски захтев према носиоцу дозволе за допуну документације. Након допуне документације Сектор за лекове приступа даљој обради. Кроз апликацију се врши прослеђивање захтева према републичким стручним комисијама, Централној комисији за лекове и Комисији за фармакоекономију који такође имају приступ апликацији и чијим члановима такође стижу емаил нотификације. Након прибављања свих потребних сагласности врши се комплетирање пословног процеса и обавештавање носиоца дозволе кроз апликацију. Апликација омогућава електронску комуникацију учесника у пословним процесима кроз апликацију. Апликација коју користи Сектор за лекове сматра се централном компонентом кроз коју је могуће: упутити захтев за допуну документације, потврдити формалну комплетност захтева, упутити нови предлог цене према носиоцу дозволе, упутити захтев према РСК, Комисији за фармакоекономију, централној комисији за лекове и подкомисијама, затим креирати решења (позитивна или негативна), закључке о одбацивању захтева за стављање лека на листу лекова и обустављање поступка, затим праћење завршне процедуре, експорт података у биз извештаја, комуницирање са корисницима и формално сторнирање захтева.

Корисници апликације

Дирекција РФЗО – Сектор за лекове, носиоци дозвола, Републичке стручне комисије, Централна комисија за лекове, Комисија за фармакоекономију.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS, клијентски сертификати за аутентификацију корисника.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Не постоји веза са другим DBMS.

Делови система

Систем се састоји из пет целина:

- Веб апликација за носиоце дозвола у којој су доступне инпут форме за унос и администрирање података;

- Веб апликација за Сектор за лекове Дирекције РФЗО у којој се врше активности као што је описано у поглављу “Опис пословног процеса”. Кроз ову апликацију се осим поменутог врши креирање решења у word формату;

- Веб апликације намењене члановима Републичке стручне комисије, Централне комисије за лекове и Комисије за фармакоекономију.

8. INOST апликација

Кратак опис система

Централизована апликација за евиденцију ино осигураника који немају основа за регистрацију у МЕОП апликацији (углавном се ради о страним држављанима који привремено бораве на територији Републике Србије.

Опис пословног процеса Први могући сценарио:

- Инострани осигураник долази на шалтер фонда и радник РФЗО-а кроз INOST апликацију му издаје ИНО-1 образац којим ино осигураник стиче право на лечење у ЗУ

- Ино осигуранику се пружа здравствена заштита и здравствена установа фактурише настале трошкове РФЗО-у

- Филијала контролише електронске фактуре

- По завршетку тромесечја подаци из електронских фактура се учитавају у INOST апликацију

- Радници у филијалама у INOST апликацији врше обрачун трошкова и генеришу одговарајуће обрасце који се шаљу у Дирекцији фонда да би ови након контроле, исте проследили иностраним кућама за накнаду

Поред овог сценарија постоји и један део осигураника из МЕОП евиденције на које се односи обрачун стварних трошкова.

У том случају подаци о активним полисама из МЕОП евиденције на које се примењује обрачун стварних трошкова се на крају квартала копирају из МЕОП-а у INOST апликацију.

Након тога цео процес рада је исти као у првом случају осим прве ставке, тј. није неопходно уносити изнова податке о осигуранику (регистрација у INOST-u) јер су исти већ преузети из МЕОП-а.

Корисници апликације

Апликација INOST се користи у свим филијалама и испоставама РФЗО-а за регистрацију и евиденцију иностраних осигураника.

Само у филијалама се користи модул INOST апликације који се односи на обрачун стварних трошкова.

У Дирекцији РФЗО-а INOST се користи за обједињено извештавање и контролу података исказаних од стране запослених у филијалама односно испоставама РФЗО-а.

Техничке карактеристике система

За апликативни део INOST апликације коришћене су технологије: HTML5, JavaScript, CSS (Bootstrap v3). Серверски део апликације је урађен у PHP програмском језику и MySQL базом података.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Приликом евиденције новог ино осигураника и приликом уноса ЈМБГ у предвиђено поље, INOST апликација проверава да ли је осигураник већ регистрован у МЕОП-у са тим матичним бројем, тј. да ли има активну полису у МЕОП-у и обавештава корисника.

Делови система

Систем се састоји из две целине:

- Основни модула за евиденцију иностраних осигураника и издавања ИНО-1 образаца;

- Модул за обрачун насталих трошкова услед лечења иностраних осигураника у здравственим установама.

9. Портал финансија намењен добављачима Кратак опис система

Овај систем омогућава управљање подацима достављених од стране добављача (фармацеутских компанија), у циљу стварања предуслова за директно плаћање добављачима од стране РФЗО у име и за рачун здравствених установа.

Опис пословног процеса

У циљу стварања предуслова за директно плаћање добављачима од стране РФЗО у име и за рачун здравствених установа, добављачи су у обавези да достављају следеће скупове података:

1. Обавезе ЗУ према добављачима (фактуре)

2. Књижна одобрења

3. Књижна одобрења (струја и гас)

4. Обавезе ЗУ према добављачима за струју и гас

5. Уговори ЗУ и добављача

Наведене скупове података могуће је достављати посредством веб сервиса, као и учитавањем предефинисаних фајлова (txt, csv, xml).

Систем омогућава праћење статуса обраде и плаћања појединачне фактуре.

Систем омогућава увид у све податке достављене од стране здравствене установе, а који се односе на добављача.

Систем омогућава експорт свих скупова података у excel format, као и података о извршеном плаћању фактура у име и за рачун здравствених установа.

Корисници апликације

Добављачи (фармацеутске компаније), филијале и Дирекција Републичког фонда.

Техничке карактеристике система

Linux, Apache, PHP7+, MariaDB 10.4.6, JavaScript, HTML 5, CSS, Perl 5.16.3.

Опис система за управљање базом података

DBMS koji se koristi je MySQL 5.7.

Комуникација са другим DBMS

Постоји веза са системима Пут лека, Електронска фактура, МЕОП и NextBiz финансијски систем.

Делови система

Систем је састављен од следећих целина:

- Унос и управљање скенираном документацијом;

- Унос и управљање подацима достављених посредством веб сервиса;

- Управљање подацима у вези са директним плаћањем.

10. Евиденција лекова за које су закључени посебни уговори Xxxxxx опис система

У складу са осетљивошћу података које је потребно пратити на дневном и полумесечном нивоу, развијена је посебна апликација способна да омогући корисницима (апотеке и здравствене установе) да уносе све релевантне податке у вези са лековима за које су закључени посебни уговори. Ова апликација је постала саставни део постојеће веб апликације Централизоване јавне набавке, у виду посебног модула, с обзиром на то да ова апликација обухвата велики број корисника, који су у моменту пуштања апликације у продукцију већ имали инсталиране електронске сертификате.

Опис пословног процеса

Апотеке и здравствене установе имају обавезу да према РФЗО два пута месечно достављају податке о реализацији лекова за које су закључени посебни уговори. Корисник бира период, који претходно

„откључа“ РФЗО и у посебној инпут форми ручно уноси податке. Корисницима је на располагању и унос података путем учитавање XML фајла. Након истека периода на који се евиденција односи, корисник формално закључује извештај према РФЗО, након чега више није могуће уносити податке за тај период, осим ако се према РФЗО не упути формални захтев са образложењем потребе измене података. РФЗО врши обраду пристиглих података и креирање низа извештаја у циљу даљег одлучивања.

Корисници апликације

Дирекција РФЗО – Сектор за јавне набавке, Сектор за лекове, као и све здравствене установе односно апотеке.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS, клијентски сертификати за аутентификацију корисника.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Апликација комуницира са системом централизованих јавних набавки.

Делови система

Систем се састоји из две целине:

- Апликација намењена апотекама и здравственим установама;

- Апликација намењена РФЗО.

11. Евиденција рада комисија за одобравање употребе лекова у лечењу осигураних лица РФЗО Кратак опис система

За потребе рада Сектора за лекове и фармакоекономију развијен је посебан подсистем „Комисије за лекове“ који се односи на евидентирање података који су у надлежности Комисија за лекове. Ова апликација садржи посебан подсистем за сваку лекарску комисију и осим уноса података ова апликација омогућава брзу припрему и штампање бројних извештаја за потребе рада лекарских комисија.

Опис пословног процеса

Подаци о предметима се воде по осигураницима (дијагноза, одлука комисије, одобрени број циклуса,...) и заседањима комисије. Централна табела је „Одлука“ и њена структура није иста за све комисије. У оквиру основног сета података је иста за све комисије, а разликује се у неким додатним пољима.

Стручно административно лице сектора за лекове на самој седници комисије уноси све релевантне податке. Прво евидентира заседање комисије (број, датум, време, пристуни, одсутни). Како комисија разматра предмет, уносе се и подаци о пацијенту, терапији и одлуци комисије (увођење, наставак, прекид, промена лека или дозе,...). Уколико у евиденцији постоји осигураник са датим ЛБО, основни подаци се преносе у нови унос, а ако ЛБО није нађен, уносе се сви подаци везани за одлуку комисије. Екран за преглед свих унетих одлука у заглављу табеле има филтере за издвајање слогова по свим приказаним обележјима.

Основни извештаји су: записник са седнице комисије, извештај за установе и извештај за филијале. Костур сваког од ових извештаја је MSWord документ сачуван у .xml формату у који програм убацује изабране податке.

Корисници апликације

Дирекција РФЗО – сектор за лекове (стручно административна лица која присуствују заседањима комисија)

Техничке карактеристике система

MS Windows, PHP7+, JavaScript, MySql. Апликација и база се налазе на одвојеним серверима.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Апликација не комуницира са другим системима.

Делови система

Систем се састоји од десет апликација – за сваку комисију посебно:

1. Комисија за лекове Humira, Remicade, Remsima, Inflectra и Simpori, <<komisija>>;

2. Комсија за лек Bevacizumab, <<bevacizumab>>;

3. Комисија за лекове Iressa, Tarceva и Gotrif, <<Iressa>>;

4. Комисија за лекове nilotinib, Bortezomib, romiplostim, eltrombopag, brentuksimab, ruksolitinib i lenalidomid, <<Nilotinib>>;

5. Комисија за лек sorafenib, <<sorafenib>>;

6. Комисија за лекове Sunitinib, pazopanib, cabazitaksel, enzalutamid i abirateron, <<sutent>>;

7. Комисија за лекове vemurafenib и pembrolizumab. << sutent>>;

8. Комисија за hepatitis – lekovi Pegasys, Pegintron, Solvadi, Harvoni, Exviera, Viekirax и Zepatier

<<hepatitis>>;

9. Комисија за MS – lekovi Avonex, Betaferon, Copaxone и Rebif <<MS>>;

10. Комисија за реуматологију – лекови Adalimumab, infliksimab 100 mg, tocilizumab, etanercept 25 mg, etanercept 50 mg, rituksimab, golimumab 50 mg, Inflectra и infliksimab, биолошки сличан лек 100 mg

<<reumatologija>>.

12. Јавни портал за преузимање шифарника

Кратак опис система

Портал је намењен здравственим установама и филијалама РФЗО и садржи материјал неопходан за рад информационих система у здравству (шифарници за фактурисање лекова на лекарски рецепт, фактурисање помагала, софтверски пакети за електронско фактурисање за све нивое здравствене заштите, пакети са подацима о пацијенткињама за вантелесну оплодњу и сви шифарници који се користе у раду са РФЗО од стране спољних сарадника).

Опис пословног процеса

Сектор за развој и информационе технологије свакодневно креира низ нових шифарника и пратећих упутстава који се објављују на порталу. Сектор такође врши администрирање права корисника, с обзиром да немају све здравствене установе право да приступе свим шифарницима и информацијама. Корисници портала приступају порталу и преузимају потребне шифарнике, инструкције и документацију у вези веб сервиса РФЗО.

Корисници апликације

Дирекција РФЗО – сви сектори, све здравствене установе примарног, секундарног и терцијарног нивоа и апотеке.

Техничке карактеристике система Linux, Apache, PHP5+, MySql.

Opis sistema za upravljanje bazom podataka DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Апликација не комуницира са другим системима.

Делови система

Систем се састоји из следећих целина:

- Рецепти и помагала – информације о фактурисању помагала и xxxxxx. Шифарници за рецепте и помагала. Информације о поништеним књижицама и веб сервис за проверу осигурања;

- Здравствене установе – информације о електронском фактурисању у примарној, секундарној и терцијарној здравственој заштит. Информације о поништеним књижицама и веб сервис за проверу осигурања;

- Вантелесна оплодња – Информације и потребни сетови података за све здравствене установе које пружају услуге вантелесне оплодње.

13. Програм дијализе Кратак опис система

Републички фонд за здравствено осигурање је у свим здравственим установама у којима се обавља дијализирање пацијената о трошку обавезног здравственог осигурања увео коришћење веб апликације

„Програм дијализе“. Апликација омогућава дневно праћење података о дијализираним пацијентима, као и креирање свеобухватне базе података из које ће се генерисати различити извештаји за потребе РФЗО, али и сваке здравствене установи која пружа услугу дијализе.

Опис пословног процеса

Здравствене установе имају на располагању веб апликацију у два нивоа. Први ниво се односи на администраторски панел у коме се креирају корисници апликације, управља њиховим привилегијама и управља апаратима за дијализу који се користе у конкретној установи. Други ниво се односи на корисничку апликацију где се пријављују нови пацијенти и управља постојећим пацијентима. По пријему новог пацијента, који започиње дијализу, здравствена установа отвара његов картон и започиње серију контаката. Подаци се уносе на дневном нивоу, како за пацијента, тако и за дијализне апарате. Апликација је централизована и у складу са тим успостављене су бројне логичке контроле, као на пример ограничење да један исти пацијент не може бити активан у више од једне здравствене установе. РФЗО креира низ извештаја из ове апликације који се користе као подршка процесу фактурисања и плаћања са стране РФЗО.

Корисници апликације

Дирекција РФЗО – Сектор за уговарање и Сектор за медицинске послове, здравствене установе које пружају услуге дијализе.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS, клијентски сертификати за аутентификацију корисника.

Opis sistema za upravljanje bazom podataka DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Апликација не комуницира са другим системима.

Делови система

Систем се састоји из следећих целина:

- Веб апликација за здравствене установе која обухвата посебан администраторски панел као што је описано у тексту изнад;

- Веб апликација за РФЗО која такође обухвата администраторски панел у коме се управља корисницима, дијализним материјалом и дијализним апаратима.

14. DSG (дијагностички сродне групе) портал

Кратак опис система

У складу са захтевима DSG пројекта, обезбеђена је веб апликација под називом „DSG portal“ намењена информисању свих здравствених установа у вези са релевантним информацијама на DSG пројекту.

Опис пословног процеса

Представници Сектора за уговарање Дирекције РФЗО, као и представници Пројектне јединице испред Министарства здравља, достављају према Сектору за развој и информационе технологије информације у документа који морају да се поставе у кратком временском року на портал. С обзиром да поједине секције портала нису намењене јавности, посредством админ панела врши се управљање видљивошћу. Такође, у оквиру админ панела креирају се кориснички налози и права над порталом.

Корисници апликације

Дирекција РФЗО – сектор за уговарање и сектор за медицинске послове, Пројектна јединица Министарства здравља, све здравствене установе и јавност у делу портала где су дати општи подаци.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Апликација не комуницира са другим системима.

Делови система

Систем се састоји из следећих целина:

- Веб апликација са јавно доступним информацијама;

- Веб апликација са поверљивим подацима којима приступају само корисници са вишом привилегијом;

- Веб апликација намењена администрирању портала.

15. Сервис за проверу валидности здравствене картице

Кратак опис система

У циљу да се подигне квалитет услуге коју Републички фонд пружа својим корисницима (осигураним лицима и здравственим установама) развијен је посебан сервис у оквиру сајта Републичког фонда, који на основу унетих параметара ЛБО и Број здравствене исправе враћа повратну информацију о статусу осигурања за конкретно лице. На овај начин, осигурана лица не морају одлазити на шалтер Републичког фонда у циљу информисања о статусу овере здравствене исправе. Такође, на основу овог сервиса здравствене установе и други релевантни субјекти могу на брз и једноставан начин да дођу до основних информација о статусу здравственог осигурања конкретног осигураног лица. Овај сервис свакодневно користи неколико десетина хиљада корисника.

Опис пословног процеса

Осигурана лица често имају потребу да провере валидност здравствене картице, а што се превасходно односи на проверу матичне филијале и датума до када је здравствена картица оверена. Осигурана лица приступају посебној апликацији на сајту РФЗО и уносом личног броја осигураника (ЛБО) и броја здравствене картице позивају посебан сервис који као информацију враћа иницијале осеигуаног лица, матичну филијалу и статус овере здравствене картице.

Корисници апликације Јавност.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Апликација не комуницира са другим системима.

Делови система

Веб апликација у оквиру сајта РФЗО.

16. Сервис за проверу статуса производње здравствене картице

Кратак опис система

У циљу оптимизације процеса уручивања здравствених картица, развијена је веб апликација доступна на сајту Републичког фонда под називом „Проверите да ли је ваша здравствена картица произведена“. Корисницима је омогућено да на основу ЛБО броја провере да ли је здравствена картица произведена, а све у циљу унапређења квалитета услуге информисања осигураних лица.днетих захтева за накнаду зараде.

Опис пословног процеса

Осигурана лица подносе захтев за здравственом картицом на шалтеру Републичког фонда или путем портала еУправе. Поднети захтеви се обрађују од стране референата РФЗО, припремају за слање у Завод за израду новчаница и кованог новца и коначно, након производње, уручују осигураним лицима.

У циљу да се олакша процес информисања осигураних лица о статусу обраде захтева за здравственом картицом и производњом исте, осигурана лица у оквиру сајта РФЗО приступају посебној апликацији где на основу унетог ЛБО броја добијају статус обраду захтева. Када се као статус врати информација да је здравствена картица произведена, осигурано лице може да се упути у матичну филијалу, односно испоставу РФЗО у циљу преузимања здравствене картице.

Корисници апликације Јавност.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Апликација не комуницира са другим системима.

Делови система

Веб апликација у оквиру сајта РФЗО.

17. Апликација за проверу статуса обраде поднетих захтева за накнаду зараде

Кратак опис система

У циљу бољег информисања осигураних лица о статусу обраде поднетих захтева за накнаду зараде, развијена је посебна апликација на сајту Републичког фонда. Осигурана лица применом овог сервиса могу оптимално пратити обраду захтева, без потребе одласка на шалтер Републичког фонда.

Опис пословног процеса

Осигурана лица подносе захтев за накнаду зараде, а што се иницијално евидентира у основном пословном систему РФЗО. Та информација у моменту уписивања у основни пословни систем постаје доступна и предметној веб апликацији која је доступна на сајту РФЗО и која у старту за конкретан захтев приказује статус „Поднет захтев“. Након обраде захтева од стране референата РФЗО и утврђивања његове комплетности долази до измене у статусу обраде захтева – захтев може бити враћен подносиоцу на допуну или се захтев упућује према финансијама у циљу плаћања. Након што финансије изврше плаћање у посебном софтверском систему, та информација се упућује и према предметном систему након чега се мења статус обраде захтева за накнаду зараде. Дакле, апликација за проверу статуса обраде поднетих захтева за накнаду зараде комуницира са основним пословним системом РФЗО, као и са финансијским системом.

Корисници апликације Јавност.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Апликација комуницира са основним пословним системом РФЗО, као и са финансијским системом. Веза са основним пословним системом се огледа у креирању XML фајла из основног пословног и његовим учитавањем у посебну веб апликацију путем које се врши парсирање XML фајла. Веза са финансијским системом се огледа у директној вези тог система и локалне MySQL базе из које се једном дневно подаци пребацују у MySQL базу на сајту, мануелним путем.

Делови система

Систем се састоји од следећих целина:

- Веб апликација у оквиру сајта РФЗО која омогућава јавности да уносом захтеваних параметара направи увид у статус обраде захтева за накнаду зараде;

- Веб апликација за пријем и обраду XML фајла који се генерише у основном пословном систему;

- Локална MySQL база у којој се обрађују подаци из финансијског система;

- MySQL база у оквиру сајта РФЗО.

18. Букинг рехабилитационих центара

Кратак опис система

У складу са одредбама Правилника о медицинској рехабилитацији у стационарним здравственим установама специјализованим за рехабилитацију (РХ центар), део Правилника који се односи на Централни букинг подразумева и постојање софтверског система као подршке процесима праћења заузећа уговорених смештајних капацитета и упућивања осигураних лица на рехабилитацију.

Опис пословног процеса

Корисници ове апликације су РХ центри, као и РФЗО. Апликација намењена РХ центрима се састоји из две целине:

Део система намењен администраторима садржи следеће опције који садржи функционалности управљања организационом структуром РХ центра, као и администрирања корисника. Опција “Организациона структура” обухвата опције “Дефинисање организационих јединица” и “Додељивање соба и кревета”. Дефинисање организационих јединица обухвата опцију управљања организационим јединицама. Додељивање соба и кревета обухвата управљање собама и креветима у оквиру појединачних организационих јединица. Администрација корисника омогућава управљање корисницима и њиховима правима над појединачним организационим јединицама.

У складу са додељеним организационим јединицама конкретном корисничком налогу, након успешног пријављивања у систем, потребно је извршити избор организационе јединице. Након избора организационе јединице, корисник има увид у списак пацијената која се налазе у конкретној организационој јединици. Корисник на располагању има могућност да дода новог пацијента у систем, тако што ће направити увид у списак пацијената који су букирани од стране РФЗО или тако што ће попунити пријемни лист уколико се пацијент из неког разлога не налази у списку букираних.

Осим имена и презимена осигураног лица, на располагању су и следећи подаци: број историје, датум пријема, соба, кревет, трајање рехабилитације (у данима), очекивани завршетак рехабилитације и напомена. Очекивани завршетак рехабилитације представља вредност израчунату аутоматски у односу на датум почетка рехабилитације и трајање рехабилитације дефинисано Правилником. Поље напомена даје најважније информације о статусу рехабилитације осигураног лица у смислу да ли је реч о осигураном лицу које је пријављено од стране Установе или је реч о осигураном лицу пријављеном од стране лекарске комисије РФЗО. Такође, поље напомена може садржати и друге информације о томе да ли је за конкретно осигурано лице поднет захтев за продужење рехабилитације, који је статус тог захтева, да ли је очекивани датум завршетка рехабилитације истекао и сл.

Дакле, РХ центру су на располагању две опције: самостално попуњавања пријемне листе – ова опција је на располагању Установи само у циљу иницијалног попуњавања реалне искоришћености постеља. На овај начин, у првој фази увођења Апликације, лекарске комисије Републичког фонда ће имати увид у тренутну реалну искоришћеност постеља Установе.

Преглед електронског списка осигураних лица (Xxxxx xxxxxx Xxxxxxxx – Лекарске комисије РФЗО), упућених од стране лекарске комисије Републичког фонда, која чекају на пријем у Установу. Кликом на конкретно осигурано лице, подаци о лицу ће се преписати у прву табелу, након чега је потребно изабрати жељену комбинацију собе и кревета.

Напомена: У зависности од тога да ли постоји пратилац осигураног лица, Апликација ће понудити евидентирање кревета за осигурано лице и пратиоца, ако за тим постоји потреба. Оба податка су обавезна и без евидентирања постеље пратиоца неће бити могуће снимање пријема.

Опција “Постеље” даје увид у све собе и кревете конкретне организационе јединице. Сиви кревети представљају празне постеље, док плави кревети дају увид у заузету постељу, при чему је у приказу доступно име и презиме осигураног лица које лежи у кревету. Уколико је реч о пратиоцу, Апликација ће уместо имена и презимена исписати “Пратилац”.

Кликом на име и презиме осигураног лица са списка осигураних лица отвориће се нови мени са додатним опцијама. Опција “Измени податке” омогућава кориснику да промени податке евидентиране приликом отварања пријемне листе осигураног лица. Опција “Премести пацијента” омогућава кориснику да изврши премештање пацијента у оквиру исте организационе јединице или у другу организациону јединицу. Уколико се осигурано лице премешта у оквиру исте организационе јединице, потребно је изабрати нову комбинацију собе и кревета. Уколико се осигурано лице премешта у другу организациону јединицу, потребно је прво изабрати жељену организациону јединицу у падајућем менију, а након тога изабрати комбинацију соба и кревета и кликнути на дугме “Премести пацијента”.

Опција “Пријемна листа” даје увид у податке евидентиране приликом отварања пријемне листе за осигурано лице.

Опција “Отпусти пацијента” омогућава кориснику да отпусти осигурано лице из система, на крају његове хоспитализације. Кориснику је на располагању опција “Датум отпуста”, која представља обавезно поље.

Након отпуштања осигураног лица из система, до тада заузета постеља постаће слободна за пријем наредног лица. Такође, овај податак ће постати доступан лекарским комисијама Републичког фонда.

Опција “Напомена” омогућава унос произвољних напомена за конкретно осигурано лице, као и хронолошки увид у сваку од њих.

Опција “Поништи пријем”, у потпуности поништава пријем конкретног осигураног лица и намењена је искључиво брисању погрешно евидентираних осигураних лица у систем. Након клика на дугме “Поништи пријем пацијента” систем ће приказати поруку “Да ли сте сигурни да желите да поништите пријем?”. Након поништеног пријема, осигурано лице се враћа у статус “На чекању (Букирано – Лекарске комисије РФЗО)”, након чега је могуће поново пријавити осигурано лице у апликацију.

Опција “Продужење рехабилитације” омогућава електронско евидентирање захтева за продужењем рехабилитације осигураног лица. Након клика на дугме “Упути захтев за продужењем” Апликација ће приказати поруку “Да ли сте сигурни да желите да упутите захтев за продужењем рехабилитације?”. Уколико је одговор потврдан, у оквиру напомене конкретног осигураног лица, доступне у списку осигураних лица, стајаће обавештење о статусу поднетог захтева. Статус може садржати обавештења о томе да ли је и када поднет захтев за продужењем рехабилитације, као и о томе која је одлука лекарске

комисије Републичког фонда. Поновним кликом на опцију “Продужење рехабилитације” Установа ће имати на располагању опцију “Поништи захтев за продужењем” која ће бити доступна све до момента доношења одлуке лекарске комисије Републичког фонда. Поништавањем захтева, враћа се првобитно стање.

Опција “Прекидање рехабилитације” омогућава електронско евидентирање прекидања рехабилитације. Кликом на ову опцију Апликација захтевати унос разлога неискоришћене одобрене продужене рехабилитације. Кликом на дугме “Евидентирај прекидање продужене рехабилитације” Апликација ће сврстати осигурано лице у списак отпуштених осигураних лица, постеља ће бити ослобођена и према лекарским комисијама Републичког фонда ће бити упућена адекватна информација о прекидању рехабилитације конкретног осигураног лица.

У случају да осигурано лице има пратиоца, у списку осигураних лица, поред имена и презимена конкретног лица, постојаће иконица у облику човека која говори да за конкретно лице постоји евидентиран и пратилац.

Апликација даје увид и о отпуштеном осигураном лицу. Кликом на конкретно осигурано лице које је отпуштено из Система, отвориће се екран који на располагању нуди две опције, увид у евидентиране напомене, као и могућност поништавања отпуста. Кликом на опцију “Поништи отпуст”, осигурано лице ће бити враћено на списак активних осигураних лица и Апликација ће приказати последње стање које је било активно пре отпуштања осигураног лица из Апликације.

Апликација намењена РФЗО омогућава креирање низа извештаја у складу са подацима које достављају РХ центри.

Корисници апликације

Дирекција РФЗО, лекарске комисије филијала РФЗО, РХ центри.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим системима

Апликација комуницира са апликацијом “Централни букинг за лекарске комисије РФЗО”.

Делови система

Систем се састоји од три веб апликације:

- Веб апликација за РХ центре намењена администраторима, као што је описано у тексту изнад;

- Веб апликација за РХ центре намењена административним и здравственим радницима који управљају пријемом и отпустом пацијента;

- Веб апликација за РФЗО путем које се врши извештавање.

19. Централни букинг за лекарске комисије РФЗО

Кратак опис система

Ова апликација је намењена лекарским комисијама Републичког фонда и обухвата алате за управљање упућивањем осигураних лица у здравствене установе специјализоване за рехабилитацију.

Опис пословног процеса

Лекарска комисија РФЗО има на располагању следеће опције у предметној апликацији:

- Ново букирање

- Преглед РХ центра

- Претрага букирања

Опција “Ново букирање” је намењена идентификовању осигураног лица за кога се врши букирање смештаја у РХ центар. Претрагу осигураног лица је могуће извршити на неколико начина, и то уносом неког од следећих параметара:

- ЈМБГ

- ЛБО

- Број здравствене исправе

Осим увида у релевантне податке из МЕОП базе, Комисија има на располагању следеће опције за унос нових података:

а) Дијагноза – на основу овог атрибута, алгоритам апликације сужава избор РХ центара у које је могуће упутити осигурано лице. Такође, на основу овог атрибута, поља Индикационо подручје, Рок у коме се мора отпочети продужена рехабилитација, Дужина трајања рехабилитације, Могућност продужења рехабилитације и Рок у коме се осигурано лице мора упутити на лекарску комисију, се попуњавају аутоматски.

b) Потреба за пратиоцем у РХ центру. ц) Потреба за пратиоцем на путу.

д) Врста превоза.

е) Назив здравствене установе по чијем извештају се врши упућивање (ако је реч о упућивању по извештају здравствене установе).

ф) Датум од када је ОЛ спремно да иде на продужену рехабилитацију. Након уноса потребних података, врши се претрага расположивих термина.

Резултат претраге термина обухвата списак РХ центара у које је могуће упутити осигурано лице. У односу на критеријуме брзине пријема, удаљености РХ центра од матичне филијале осигураног лица, расположивости постеља и искоришћености уговорнеих постеља, Апликација ће дати предлог рангирања Установа. Осим списка РХ центара, Комисија има и увид у укупну вредност пондера на основу кога се рангирање врши. Такође, Апликација нуди и датум почетка рехабилитације који је на основу података доступних из дела Апликације намењеног Установама идентификован као најранији. Овај датум је могуће променити кликом на поље датума и избором новог датума. Уколико Комисија изабере РХ центар рангирану као прву на списку предложених Установе, све што је потребно учинити јесте избор опције “Одобри продужену рехабилитацију”. Уколико Комисија изабере РХ центар који није рангиран као први, испод списка РХ центара ће се појавити ново поље “Образложење избора” у које је потребно унети образложење избора РХ центра.

Процес букирања, односно електронског одобравања продужене рехабилитације у изабраном РХ центру се завршава избором опције “Одобри продужену рехабилитацију”.

Опција “Преглед РХ центра” даје увид у тренутну искоришћеност постеља конкретне установе. Ова информација је доступна како табеларно, тако и визуелно у виду празних и попуњених постеља у оквиру организационе структуре коју је дефинисала сама установа, односно РХ центар.

Опција “Претрага букирања” је намењена за идентификовање осигураног лица за кога се врши претрага букирања. Претрагу осигураног лица је могуће извршити на неколико начина, и то уносом неког од следећих параметара:

- ЈМБГ

- ЛБО

- Број здравствене исправе

Резултат претаге представља картон букирања осигураног лица. Овде ће бити приказана укупна историја свих букирања. Осим основних података о осигураном лицу, Комисија има увид у следеће податке:

- Да ли је осигурано лице примљено у Установу;

- Да ли је Установа поднела захтев за продужењем рехабилитације;

- Да ли је рехабилитација прекинута;

- Да ли је осигурано лице отпуштено из Установе.

У последњој колони резултата претраге, Комисија има на располагању иконицу у виду знака “Инфо”. Кликом на ову иконицу отвориће се посебан екран са додатним информацијама појединачног букирања. Комисија има увид у све податке релевантне за букирање. Осим увида у податке везане за букирање, Комисија има увид у тренутни статус букирања, а тиме и у следеће потенцијалне опције:

а) Уколико је Комисија реализовала букирање у Установу, а у међувремену Установа није реализовала електронски пријем осигураног лица, Комисија има могућност да Поништи букинг или да измени опште податке о букирању.

б) Уколико је Комисија реализовала букирање у Установу, а Установа реализовала електронски пријем осигураног лица, тада ће Комисија имати увид у ту информацију, без могућности поништавања букинга и измене основних података о букирању.

ц) Уколико је Комисија реализовала букирање у Установу, а Установа након електронског пријема евидентира прекидање рехабилитације, Апликација ће дати детаљније обавештење о времену и разлогу прекидања рехабилитације.

д) Уколико је Установа поднела електронски захтев за продужење рехабилитације, Комисија ће имати на располагању опцију обраде захтева за продужење рехабилитације.

Апликација ће пружити помоћ Комисији у обради захтева, у смислу приказа релевантних информација везаних за конкретан захтев. Комисија има на располагању две опције: Одобравање захтева и Одбијање захтева. У првом случају, осим датума када је Комисија донела одлуку, потребно је унети и број дана за колико се одобрава продужење рехабилитације.

Након избора опције “Одобри продужење рехабилитације” или “Одбиј продужење рехабилитације” Апликација ће снимити одлуку и приказати посебан екран уз додатно обавештење о донетој одлуци: Приказ позитивне одлуке за продужење рехабилитације или Приказ негативне одлуке за продужење рехабилитације.

Комисија има могућност измене своје одлуке. Кликом на дугме опцију “Измени одлуку” отвориће се посебан екран при чему је поступак остао исти.

Корисници апликације

Дирекција РФЗО, Лекарске комисије РФЗО.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, MS SQL 2016, JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7 и MS SQL 2016.

Комуникација са другим системима

Апликација комуницира са апликацијом “Букинг РХ центара” и Матичном евиденцијом и остваривањем права.

Делови система

Систем се састоји од две апликације:

- Веб апликација за лекарске комисије намењена лекарским комисијама РФЗО, као што је описано у тексту изнад;

- Веб апликација за намењена администраторима у Дирекцији РФЗО.

20. Управљање здравственим картицама

Кратак опис система

С обзиром на чињеницу да је пословни процес здравствених картица континуиран, Републички фонд је развио апликацију која је омогућила запосленима у Републичком фонду да на брз и једноставан начин направе увид у следеће информације:

- Да ли је Завод за израду новчаница и кованог новца (ЗИН) доставио електронске повратнице, а што је предуслов за уручење здравствених картица, чиме је укинут процес мануелног претраживања доступних папирних докумената и њихово сравњивање са ознакам кутија достављених од стране ЗИН;

- Да ли је за конкретно осигурано лице (на основу ЛБО или ЈМБГ параметра) здравствена картица произведена и у којој кутији се налази. С обзиром да ЗИН доставља здравствене картице у кутијама које садрже 250 здравствених картица, ова функционалност је значајно оптимизовала процес физичке претраге здравствених картица у процесу уручивања исте према осигураном лицу;

- Ко су осигурана лица у конкретном производном послу, односно списак осигураних лица на основу ознаке кутије коју доставља ЗИН;

- Поред наведеног, ова апликација омогућава запосленима у Републичком фонду да на брз и једноставан начин означе оне здравствене картице које су спремне за преузимање од стране осигураних лица, а што је посредством другог електронског сервиса доступно на веб сајту Републичког фонда.

Опис пословног процеса

Након пријема и обраде захтева за здравственом картицом, информација се посредством веб сервиса преноси из система за матичну евиденцију и остваривање права у предметни систем. Информација о статусу обраде захтева за здравственом картицом се посредством веб сервиса уписује у MySQL базу на сајту РФЗО где је посебан сервис обрађује и приказује на захтев корисника, а што је описано у тачки М13: Сервис за проверу статуса производње здравствене картице. Након што ЗИН обавести РФЗО о томе да су здравствене картице произведене, РФЗО преузима електронске повратнице и учитава их у посебан софтверски систем за здравствене картице и то у Орацле базу података. Након завршетка учитавања електронских повратница, администратор РФЗО мануелно покреће скрипте које раде

трансфер дела података из поменуте Oracle базе, као и из базе матичне евиденције и остваривања права MS SQL 2016, након чега се врши консолидација релевантних података у MySQL бази предметне апликације. Након што су подаци о здравственим картицама и њиховим (новим) статусима уписани у базу предметне апликације, референти РФЗО имају на располагању могућност филтрирања података о здравственим картицама, као и и могућност креирања посебних сетова података намењених апликацији ЈП „Пошта Србије“, са којом је извршена интеграција, у циљу припреме пошиљки на кућну адресу. Апликација нуди неколико битних функционалности за рад референата на шалтеру, међу којима предњачи она за идентификовање кутије у којој се налази конкретна здравствена картица.

Корисници апликације

Дирекција РФЗО, све филијале РФЗО.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, Oracle DB (као извор дела података), MS SQL 2016 (као извор дела података), JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7 i MS SQL 2016.

Комуникација са другим системима

Апликација комуницира са матичном евиденцијом и остваривањем права, системом КЗО, као и наменском апликацијом ЈП “Пошта Србије.

Делови система

Систем се састоји од две целине:

- Веб апликација за филијале РФЗО;

- Локалне скрипте за трансфер података, као што је описано у тексту изнад.

21. Веб сервис за контакт центра Републичког фонда

Кратак опис система

За потребе контакт центра Републичког фонда успостављен је веб сервис са којим је интегрисан говорни аутомат контакт центра, а у циљу успостављања динамичких порука како би се смањило оптерећење оператера у контакт центру. Овај веб сервис прихвата ЛБО број на основу кога враћа информације у вези са статусом обраде захтева за здравственом картицом, као и статус овере здравствене картице. С обзиром да контакт центар поседује клијентску апликацију, било је неопходно обезбедити посебан веб сервис који ће оператерима, по потреби, обезбедити детаљнији увид у податке из матичне евиденције.

Опис пословног процеса

Избором опције за проверу статуса производње здравствене картице, као и опције за проверу овере здравствене картице, говорни аутомат инструише корисника да унесе ЛБО број након чега се врши позивање одговарајућег веб сервиса и на основу резултата одговора веб сервиса емитовање говорне поруке. Уколико је корисник говорног аутомата одлучио да успостави везу са оператером, оператер има могућност да позове нови веб сервис на основу ЛБО броја корисника и тиме направи увид у податке из матичне евиденције уколико је то потребно у циљу сачињавања одговора.

Корисници апликације

Оператери у контакт центру, као и јавност посредством говорног аутомата.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7

Комуникација са другим системима

Веб сервис са једне стране комуницира са говорним аутоматом контакт центра, као и веб апликацијом намењеном оператерима у конткат центру.

Делови система

Као што је описано у тексту изнад.

22. Веб сервиси намењени здравственим установама

Кратак опис система

У циљу успостављања предуслова за испуњавање обавеза здравствених установа дефинисаних Инструкцијом о ефикасном управљању и контроли трошкова лечења осигураних лица, као и директним плаћањем РФЗО према добављачима у име и за рачун здравствених установа, развијен је скуп веб сервиса који здравственим установама омогућава потпуну интеграцију са системима РФЗО, чиме се елиминише потреба мануелног рада здравствених рада, као и грешке приликом достављања података. Здравствене установе су у обавези да достављају следеће скупове података, ажурно и тачно:

1. Податке о стању залиха лекова у здравственим установама

2. Податке о стању залиха потрошних, санитетских и медицинских материјала

3. Податке о новим улазима лекова у централну апотеку здравствене установе

4. Податке о новим улазима потрошних материјала у централну апотеку здравствене установе

5. Податке о утрошку лекова и потрошних материјала

6. Податке о изводу отворених ставки

7. Податке о дуговању и обавезама здравствених установа

8. Податке о медицинској документацији

9. Податке о организационим јединицама здравствене установе

10. Податке о уговорима између добављача и здравствених установа

Опис пословног процеса

1. Стање залиха лекова на дан 31.12.2018. године

2. Стање залиха лекова на дан 28.02.2019. године

3. Стање залиха материјала на дан 31.12.2018. године

4. Стање залиха материјала на дан 28.02.2019. године

5. Стања залиха / нови улази лекова од 01.03.2019. године

6. Стања залиха / нови улази материјала од 01.03.2019. године

7. Утрошак лекова у 2018. години

8. Утрошак материјала у 2018. години

9. Утрошак лекова од 01.03.2019. године

10. Утрошак материјала од 01.03.2019. године

11. Обавезе ЗУ према добављачима (фактуре)

12. Књижна одобрења

13. Књижна одобрења (струја и гас)

14. Укупне обавезе према добављачима на дан 31.12.2018. године

15. Укупне обавезе према добављачима на дан 28.02.2019. године

16. Стање обавеза према добављачима на дан, усаглашено између ЗУ и добављача, на дан 31.12.2018

17. Стање обавеза према добављачима на дан, усаглашено између ЗУ и добављача, на дан 28.02.2019

18. Обавезе ЗУ према добављачима за струју и гас

19. Уговори ЗУ и добављача

Корисници апликације

Све здравствене установе примарног, секундарног и терцијарног ниова, филијале РФЗО и Дирекција РФЗО.

Техничке карактеристике система

Linux, Apache, Java EE Web Services, MS SQL 2016, PHP7+, MariaDB 10.4.6, JavaScript, HTML 5, CSS.

Опис система за управљање базом података

DBMS који се користи је MS SQL 2016, kao i MySQL 5.7.

Комуникација са другим DBMS

Постоји веза са системима Пут лека, Електронска фактура, МЕОП и NextBiz финансијски систем. Делови система

Скуп веб сервиса као што је описано у тексту изнад.

23. Евиденција баркодова

Кратак опис система

Ова апликација је намењена евидентирању података које добављачи достављају у посебним обрасцима са подацима о баркодовима које желе да региструју. Применом ове апликације креирају се шифарници за баркодове.

Опис пословног процеса

Добављачи се информишу са сајта РФЗО и преузимају Обрасце за попуњавање.

Добављачи усаглашавају Обрасце са здравственим установама које имају увид у податке на сајту РФЗО и номенклатуре неопходне за попуњавање Образаца.

Обасци се достављају на адресу xxxxxx.xxxxxxxx@xxxx.xx. Уколико су обрасци исправно попуњени, подаци се ручно уносе у наменске табеле апликације Sifre, Dobavljač, Implant I Barkod_implant.

По завршеној обради пуштају се контроле уноса и валидација података. Креирају се шифарници и објављују се на порталу РФЗО.

Корисници апликације Дирекција РФЗО.

Техничке карактеристике система MS Access, OS Windows.

Опис система за управљање базом података DBMS који се користи је MS Access.

Комуникација са другим системима

Апликација не комуницира са другим системима.

Делови система

MS Access апликација, као што је описано у тексту изнад.

24. Инфо портал РФЗО

Кратак опис система

Инфо портал представља интерни wеб сајт који садржи све материјале од значаја за запослене у РФЗО (именик запослених, интерни документи, извештаји и законска акта). У оквиру овог сајта налазе се и прихваћене стандардизоване процедуре рада у РФЗО према усвојеним ИСО стандардима (ИСО 9001:2008 и ИСО 27001:2005).

Опис пословног процеса

Након успостављања или измене релевантних података у вези са пословањем РФЗО, запослени у РФЗО обавештавају посебно одељење о потреби ажурирања инфо портала. Подаци о којима се свакодневно води рачуна са аспекта ажурности су следећи: актуелне информације, Информатор о раду, Закони, Правилници, Уредбе, Одлуке, Статут, Финансијски план, Финансијски извештаји, Остваривање права – водичи, Корисни линкови, Професионална усавршавања запослених, Контакт подаци, Бесплатни веб прописи, Стамбена питања, Техничка упутства, Упутства филијалама, Упутства здравственим установама, Одлука о уплати висине трошкова издавања здравствене картице, Контакти у филијалама и испоставама, Кратак опис стандарда по тачкама, Радна документа за локалне координаторе, ИСО 9001:2008, Радна тела, Мастер листа, Политика квалитета, Пословник о квалитету, Системска документа, Радна документа, Извештаји о мерењу задовољства, Колективни уговор, Правилници, Одлуке, Наредбе, Обрасци, Дописи, Инструкције и упутства, Обавештења, Стратегије, Ризици, Презентације, Годишњи извештаји, Планови рада здравствених установа, Добровољно осигурање, Јавне набавке (закључени оквирни споразуми и уговори).

Корисници апликације

Дирекција РФЗО, све филијале РФЗО

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS

Опис система за управљање базом података DBMS koji se koristi je MySQL 5.7

Комуникација са другим системима

Апликација не комуницира са другим системима.

Делови система

Систем се састоји од две целине:

- Веб апликација намењена корисницима;

- Веб апликација намењена администратору система.

25. Сајт РФЗО

Кратак опис система

У циљу лакшег и потпунијег информисања грађана у вези са остваривањем права из обавезног здравственог осигурања, као и упознавања са активностима РФЗО, успостављен је сајт www.рфзо.рс. Повећан је број информација које се објављују на сајту, а самим тим и уведена већа транспарентност у раду РФЗО. На сајту се објављују све информације од јавног значаја које могу бити од користи не само за осигурана лица, већ за све запослене у систему здравствене заштите. Сајт се састоји од главног сајта, као и подсајтова за јавне набавке и добровољно здравствено осигурање. Сајт садржи неколико интегрисаних сервиса намењених јавности.

Опис пословног процеса

У циљу ажурног информисања јавности и испуњавања законских обавеза РФЗО свакодневно ажурира податке на сајту, као и базе података јавно доступних сервиса који су описани у другим тачкама овог документа. Ажурирању сајта претходни припрема информација (садржаја) од стране сектора у Дирекцији РФЗО, затим верификација новог садржаја од стране надлежне службе и коначно достављање новог садржаја према Сектору за развој и информационе технологије у циљу техничке реализације. Сајт је рађен посредством Joomla оквира, услед чега се свакодневно води рачуна о ажурирању Joomla. Обим одржавања сајта се може описати кроз број страница и број сервиса који се налазе у оквиру сајта. За сада постоји укупно 5 сервиса и око 600 страница.

Корисници апликације Дирекција РФЗО, јавност.

Техничке карактеристике система

Linux, Joomla, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS

Опис система за управљање базом података DBMS који се користи је MySQL 5.7

Комуникација са другим системима

Апликација не комуницира са другим системима. Сајт РФЗО садржи сервисе за проверу валидности здравствене картице, проверу изабраног лекара, проверу статуса производње здравствене картице, проверу статуса обраде захтева за накнаду зараде и сервис за претрагу лекова.

Делови система Као у тексту изнад.

26. Дефицитарност лекова

Кратак опис система

Реч је о веб апликацији путем које све здравствене установе евидентирају дефицитарне лекове. Посебан модул се тиче извештавања.

Опис пословног процеса

У складу са инструкцијом РФЗО све здравствене установе, укључујући и апотеке, пријављују дефицитарне лекове на дневном нивоу, према атрибутима и критеријумима које претходно дефинисао РФЗО. Подаци се уносе у апликацију при чему се формално слање према РФЗО потврђује посебном опцијом када се и закључава конкретан унос. Здравственим установама је омогућено да осим попуњавања предефинисаних образаца врше и одређену аналитику. Дирекција РФЗО применом предметне апликације креира низ извештаја у циљу оптимизације предвиђања и одлучивања, као и извештавања према Министарству здравља. Здравствене установе могу уносити податке мануелним путем или учитавањем XML фајла у складу са техничким упутством које је обезбедио РФЗО.

Корисници апликације

Дирекција РФЗО, све здравствене установе, укључујући и апотеке.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим системима

Апликација не комуницира са другим системима

Делови система

Систем се састоји од следећих целина:

- Веб апликација намењена здравственим установама, укључујући и апотеке, путем које се врши попуњавање предефинисаних образаца о дефицитарности;

- Веб апликација намењена администраторима у Дирекцији РФЗО путем које се врши администрирање Система, односно корисника и одговарајућих шифарника;

- Веб апликација намењена Сектору за лекове и Сектору за јавне набавке у Дирекцији РФЗО у циљу креирања потребних извештаја.

27. Финансијски веб сервиси намењени добављачима Кратак опис система

У циљу успостављања предуслова за испуњавање обавеза здравствених установа и добављача (фармацеутских компанија), дефинисаних Инструкцијом о ефикасном управљању и контроли трошкова лечења осигураних лица, као и директним плаћањем РФЗО према добављачима у име и за рачун здравствених установа, развијен је скуп веб сервиса који добављачима омогућава потпуну интеграцију са системима РФЗО, чиме се елиминише потреба мануелног рада здравствених рада, као и грешке приликом достављања података. Добављали су у обавези да достављају следеће скупове података, ажурно и тачно:

1. Податке о дуговању и обавезама здравствених установа

2. Податке о уговорима између добављача и здравствених установа

Опис пословног процеса

У циљу испуњавања Инструкције за ефикасније управљање и контролу трошкова лечења осигураних лица, добављачи су у обавези да достављају следеће скупове података посредством веб сервиса РФЗО:

1. Обавезе ЗУ према добављачима (фактуре)

2. Књижна одобрења

3. Укупне обавезе према добављачима на дан 31.12.2018. године

4. Укупне обавезе према добављачима на дан 28.02.2019. године

5. Стање обавеза према добављачима на дан, усаглашено између ЗУ и добављача, на дан 31.12.2018

6. Стање обавеза према добављачима на дан, усаглашено између ЗУ и добављача, на дан 28.02.2019

7. Уговори ЗУ и добављача

Корисници апликације

Добављачи (фармацеутске компаније), филијале РФЗО и Дирекција РФЗО.

Техничке карактеристике система

Linux, Apache, Java EE Web Services, MS SQL 2016, PHP7+, MariaDB 10.4.6, JavaScript, HTML 5, CSS.

Опис система за управљање базом података

DBMS који се користи је MS SQL 2016, kao i MySQL 5.7.

Комуникација са другим DBMS

Постоји веза са системима Пут лека, Електронска фактура, МЕОП и NextBiz финансијски систем.

Делови система

Скуп веб сервиса као што је описано у тексту изнад.

28. M24: Веб апликација и веб сервиси намењени интеграцији са интерним и екстерним системима, као и извештавањем за потребе директног плаћања и спровођења инструкције за ефикасније управљање и контролу трошкова лечења осигураних лица

Кратак опис система

У циљу спровођења Инструкције за ефикасно управљање и контролу трошкова лечења осигураних лица, као и у циљу успостављања свих предуслова за директно плаћање добављачима у име и за рачун здравствене установе, а према Закључку Владе Републике Србије, успостављен је скуп веб сервиса, као и веб апликација намењених Дирекцији и филијалама РФЗО. Веб сервиси подразумевају следеће:

1. Веб сервиси намењени интеграцији са информационим системима здравствених установа (видети тачке М2 и М19)

2. Веб сервиси намењени интеграцији са информационим системима добављачима (Видети тачке М6 и М23)

3. Веб сервиси намењени интеграцији са финансијским системом Републичког фонда (BitImpeks NextBiz)

4. Веб сервиси намењени интеграцији са софтверским системом Пут лека

5. Веб сервиси намењени интеграцији са core business sistemom Републичког фонда (MEOP)

6. Веб сервиси намењени интеграцији са системом електронског фактурисања у Републичком фонду

7. Веб сервиси намењени интеграцији са софтвером за централизоване јавне набавке у оквиру Републичког фонда

8. Веб сервис за преузимање, обраду и упис података из Централог регистра фактура (ЦРФ)

Осим веб сервиса, Дирекцији РФЗО и филијалама на располагању је централна веб апликација (видети тачку М3), као и помоћне веб апликације описане испод.

Опис пословног процеса

Укупан систем веб сервиса и веб апликација чине следећи подсистеми.

1. Веб сервиси намењени интеграцији са информационим системима здравствених установа (видети тачку М19)

2. Веб сервиси намењени интеграцији са информационим системима добављачима (видети тачку М23)

3. Веб сервиси намењени интеграцији са финансијским системом Републичког фонда

4. Веб сервиси намењени интеграцији са софтверским системом Пут лека

5. Веб сервиси намењени интеграцији са цоре бусинесс системом Републичког фонда

6. Веб сервиси намењени интеграцији са системом електронског фактурисања у Републичком фонду

7. Веб сервиси намењени интеграцији са софтвером за централизоване јавне набавке у оквиру Републичког фонда

8. Веб сервис за преузимање, обраду и упис података из Централог регистра фактура (ЦРФ)

9. Веб апликација за потребе извештавања унутар Републичког фонда

10. Веб апликација за потребе визуелне напредне аналитике у односу на податке који се прикупљају кроз друге интерне системе РФЗО

Веб сервиси намењени интеграцији са финансијским системом Републичког фонда

Подсистем се састоји од веб сервиса способних да испоруче потребне податке према финансијском софтверском систему РФЗО, као и да прихвате повратне информације из финансијског система.

Ови подаци се односе на:

1. Подате о здравственој установи

2. Податке о добављачу

3. Податке из уговора, анекса уговора, фактура и отпремница

4. Податке о дуговима и каматама

Веб сервиси намењени интеграцији са софтверским системом Пут лека

Софтверски систем Пут лека примарно прати улазе лекова у централну апотеку здравствених установа, као и кретање лекова унутар здравствене установе по одељенским апотекама. Такође, Пут лека прати реализацију лекова у здравственој установии.

Подсистем се састоји од веб сервиса способних да испоруче податке о залихама лекова и потрошњи лекова на нивоу здравствене установе, али и појединачних одељења на којима постоји формирана клиничка/одељенска/сателитска потека.

Ови веб сервиси морају у реалном времену да врше обраду података и њихово достављање према централној бази финансијске контроле у циљу укрштања са подацима које здравствене установе достављају путем већ успостављених веб сервиса и оптималног извештавања према менаџменту РФЗО, као и Министарству финансија и Министарству здравља.

Веб сервиси намењени интеграцији са цоре бусинесс системом Републичког фонда

Подсистем се састоји од веб сервиса способних да испоруче потребне податке према core business sistemu РФЗО, као и да прихвате повратне информације из core business sistema.

Ови подаци се односе на:

1. Подате о здравственој установи

2. Податке о осигураном лицу

Веб сервиси намењени интеграцији са системом електронског фактурисања у Републичком фонду

Подсистем се састоји од сервиса способних да испоруче потребне податке према систему електронског фактурисања РФЗО, као и да прихвате повратне информације из истог система.

Ови подаци се односе на:

1. Подате о стању залиха лекова, потрошног, санитетског и уградног материјала

2. Податке о утрошку залиха лекова, потрошног, санитетског и уградног материјала

3. Податке о уговорима и обавезама здравствених установа према добављачима

Веб сервиси намењени интеграцији са софтвером за централизоване јавне набавке у оквиру Републичког фонда

Подсистем се састоји од веб сервиса способних да испоруче потребне податке према систему Централизованих јавних набавки (ЦЈН) РФЗО, као и да прихвате повратне информације из истог система.

Ови подаци се односе на:

1. Подате о стању залиха лекова, потрошног, санитетског и уградног материјала

2. Податке о утрошку залиха лекова, потрошног, санитетског и уградног материјала

3. Податке о уговорима и обавезама здравствених установа према добављачима

4. Податке о уговорима и обавезама здравствених установа према добављачима

Веб сервис за преузимање, обраду и упис података из Централог регистра фактура (ЦРФ)

Подсистем се односи на веб сервис способан да преузме податке о фактурама које се односе на директна плаћања према добављачима од стране Републичког фонда.

Корисници апликације Дирекција и филијале РФЗО.

Техничке карактеристике система

Linux, Apache, Java EE Web Services, MS SQL 2016, PHP7+, MariaDB 10.4.6, JavaScript, HTML 5, CSS.

Опис система за управљање базом података

DBMS који се користи је MS SQL 2016, kao i MySQL 5.7.

Комуникација са другим DBMS

Постоји веза са системима Пут лека, Електронска фактура, МЕОП, NextBiz финансијски систем, Централизоване јавне набавке и Централни регистар фактуре Управе за трезор.

Делови система

- Скуп веб сервиса као што је описано у тексту изнад.

29. Исплаћене плате здравственим установама (ИПЛ)

Кратак опис система

Ова апликација је намењења планирању средстава за плате у установама са којима РФЗО има уговор.

Опис пословног процеса

Здравствене установе којима РФЗО преноси средства за зараде уговорених радника, месечно извештавају фонд о исплаћеним зарадама за примарну, секундарну здравствену заштиту и стоматологију на прописаним MS Excel обрасцима. У филијалама се уносе подаци о исплаћеним платама у месецу из табела добијених од здравствених установа и добијају прегледи за установе са подручја филијале. Омогућено је да се при уносу табеле део података копира из образаца.

Помоћна MS Access база се користи за кориговање параметара апликације, укрштања података и добијање нестандардних извештаја. Параметарска табела „Месеци“ отвара нови месец за унос (поље закљуцан 0 – није, 1 – јесте) и то је најчешћа активност из поменуте базе.

Апликација приступа и подацима из апликације „Уговорени радници". Читају се само подаци о корисничким налозима, пошто податке за ИПЛ углавном и уносе исти радници фонда који ажурирају податке о уговореним здравственим радницима.

У Дирекцији се добијају извештаји за цело подручје фонда преко апликације урађене у MS Excel који се налази на рачунару референта задуженог за праћење средстава за зараде уговорених ЗУ.

Централна табела са подацима је „IPL“ где је свака ћелија MS Excel табеле представљена једним пољем. Табела „Ipl_povraćaj“ повезана је са централном примарним кључем + редни број промене и садржи податке о повраћајима средстава. Остале табеле су шифарници.

Табела за унос и приказ дефинисана је у параметарској табелi „IPL_redovi“ где су називи редова и дефинисана поља у табели „IPL“ у које се уписује, односно из којих се чита одговарајући образац.

Корисници апликације

Дирекција фонда, филијале – радници одељења за уговарање.

Техничке карактеристике система

1. Веб апликација за унос података, преглед и штампу извештаја на нивоу филијле. Подаци су у MS SQL.

2. MS Excel табела са програмом за презимање података из базе и формирање сумарне табеле за све установе – користи се у Дирекцији.

Опис система за управљање базом података DBMS који се користи је MS Access и MS SQL.

Комуникација са другим системима

Апликација комуницира са системом уговорених здравствених радника. Делови система

Као у тексту.

30. Групер веб апликација и веб сервис Кратак опис система

Ова веб апликација је намењена групирању у реалном времену, чиме је превазиђен недостатак првобитне апликације за групирање, која представља десктоп апликацију без могућности мануелног попуњавања обрасца за потребе групирања. Апликација се састоји из веб апликације за унос података и интеграције са MS Access апликацијом за групирање која представља суштину. Осим веб апликације на располагању је и REST веб сервис. Апликација је намењена новом начину финансирања здравствених установа – према моделу дијагностички сродних група.

Опис пословног процеса

Дијагностички сродне групе (DSG) представљају методу класификације болнички лечених пацијената у групе које имају сличне клиничке специфичности и захтевају сличну потрошњу болничких ресурса. Термин дијагностички сродне групе (DSG) је превод енглеског израза Diagnosis Related Groups (DRG).

Прва класификација овог типа биле су дијагностичке групе које је 1975. године припремио тим са Универзитета Јејл (Yale University) у Америци. После међусобне сарадње америчких и аустралијских стручњака, развили су се системи DSG у многим државама света. Тренутно се у свету системи DSG примењују у преко 30 земаља у циљу финансирања акутног болничког лечења на основу учинка и мерљивих резултата. Међутим, за остале болничке активности (на пример истраживања и развој, лечење хроничних и психијатријских пацијената, амбулантно лечење), најчешће се користе други начини плаћања.

Класификација по систему DSG даје могућност груписања болнички лечених пацијената, повезивање података о пацијентима с трошковима болнице, поређење обима рада болница узимајући у обзир сложеност случајева, унапређење система интерне контроле трошкова и правилније расподеле средстава међу болницама. Примена овог система, у већини земаља у којима је уведен, донела је бољу и праведнију расподелу ограничених средстава и утицала је на повећање ефикасности лечења.

За правилно извештавање по систему DSG је неопходно коришћење Међународне класификације болести и сродних здравствених проблема, десета ревизија (MKB-10) и Правилника о Номенклатури услуга на секундарном и терцијарном нивоу здравствене заштите, као и поштовање правила шифрирања дијагноза и процедура.

Основа за разврставање пацијената по систему DSG се врши на основу дијагноза и урађених процедура, као и других података потребних за извештавање.

Подаци потребни за извештавање по систему DSG су:

- Основни узрок хоспитализације (MKB-10)

- Пратеће дијагнозе: компликације и коморбидитети (MKB-10)

- Процедуре (Правилник о Номенклатури)

- Старост

- Xxx

- Тежина на рођењу (само за новорођенчад)

- Исход лечења

- Број сати на механичкој вентилацији

- Број дана хоспитализације

Предметна веб апликација и веб сервис омогућавају кориснику да унесе горе поменуте атрибуте путем веб апликације или веб сервиса, у циљу добијања повратне информације о групи и коефицијенту који се везују за пацијента.

Након што се попуни образац и потврди форма, подаци се чувају у локалној MySQL бази. Након тога, покреће се процес трансфера тих података у MS Access базу према правилима која намеће desktop апликација Gruper (MS Access пројекат). Након успешног трансфера података, аутоматски се покреће EXE фајл са додељеним аргументима који опредељују табелу у MS Access bazi, као и путању експорта,

односно резултата групирања. Резултат групирања се чува у предметној MS Access бази, након чега се покреће нови процес који врши трансформацију података у MySQL базу одакле се подаци, односно резултат групирања, приказују у предметној апликацији кориснику.

Корисници апликације

Дирекција РФЗО – Сектор за уговарање и Сектор за медицинске послове, Пројектна јединица Министарства здравља, све здравствене установе укључене у пилот пројекат DSG.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, MS Access, JavaScript, HTML 5, CSS

Опис система за управљање базом података

DBMS који се користи је MySQL 5.7, док се за Gruper desktop апликацију користи MS Access.

Комуникација са другим DBMS

Апликација комуницира са Gruper desktop апликацијом и пратећом MS Access базом.

Делови система

Систем се састоји из следећих целина:

- Веб апликација са формом за групирање;

- Веб апликација намењена администрирању портала;

- Веб сервис намењен групирању;

- Gruper MS Access project као desktop апликација.

31. Портал капитације

Кратак опис система

Веб апликација за прикупљање и дистрибуцију релевантних информација и документације на тему капитације.

Опис пословног процеса

Представници Сектора за уговарање Дирекције РФЗО, као и представници Пројектне јединице испред Министарства здравља, достављају према Сектору за развој и информационе технологије информације у документа који морају да се поставе у кратком временском року на портал. С обзиром да портал није намењен јавности, посредством админ панела врши се управљање видљивошћу страница портала. Такође, у оквиру админ панела креирају се кориснички налози и права над порталом.

Корисници апликације

Дирекција РФЗО – Сектор за уговарање и Сектор за медицинске послове, Пројектна јединица Министарства здравља, све здравствене установе уклучене у пилот пројекат капитације.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Апликација не комуницира са другим системима.

Делови система

Систем се састоји из следећих целина:

- Веб апликација са поверљивим подацима којима приступају само корисници са вишом привилегијом;

- Веб апликација намењена администрирању портал.

32. Сервис за ажурирање изабраног лекара

Кратак опис система

Веб апликација за управљање трансфером података о изабраном лекару из локалних дистрибуираних база података РФЗО у централну базу за потребе рада веб сервиса у оквиру веб сајта РФЗО.

Опис пословног процеса

Здравствене установе на недељном нивоу достављају податке о изабраним лекарима и осигураним лицима. Филијале РФЗО учитавају ове податке у локалне филијалске базе. Након завршеног учитавања врши се трансфер података у централну базу којом управља Дирекција РФЗО. Ови подаци трпе одређене трансформације у циљу њиховог трансфера на сајт РФЗО. Ова апликација омогућава и ажурирање појединачних изјава о изабраном лекару, у случају хитних и специфичних ситуација са терена. Након трансфера података у mysql базу намењену сајту РФЗО сервис на сајту нуди могућност увида у изабраног лекара на основу комбинације атрибута ЛБО и број здравствене исправе осигураног лица.

Корисници апликације

Дирекција РФЗО, сва осигурана лица посредством веб сајта РФЗО.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Апликација комуницира са МЕОП базом података (MS SQL 2016).

Делови система

Систем се састоји из следећих целина:

- Веб апликација за управљање трансфером података из дистрибуираних база и централне базе у базу намењену сајту РФЗО;

- Веб апликација намењена управљању појединачним изјавама осигураних лица у вези са изабраним лекаром;

- Веб сервиси за комуникацију сајта РФЗО и базе података о изабраном лекару.

33. Листе чекања у здравственим установама

Кратак опис система

Ова апликација омогућава евидентирање пацијената на листама чекања за медицинске услуге за које је предвиђено да се воде листе чекања, евиденцију контролног прегледа, одлагање интервенција уз навођење разлога, управљање и контролу података о листама, објављивање редуковних података о листама на јавним страницама РФЗО, креирање различитих извештаја о листама (предефинисани и ад хоцк извештаји)... Такође, програм омогућава и евиденцију пацијената којима је извршена услуга за коју је обавезно да се води листа чекања, а који су из медицинских разлога (хитност и сл.) морали бити примљени ('Евиденција мимо листе чекања').

Опис пословног процеса

Евиденција пацијената на листу чекања, измена података у току егзистирања евиденције на листи чекања, померање датума очекиваног пријема, реализација и скидање са листе чекања (брисање са листе или извршена интервенција) врши се у здравственој установи, од стране запослених. Према уговору са РФЗО, све здравствене установе које пружају услуге за које се воде листе чекања ажурирају податке у централној бази РФЗО преко предметне апликације. Пацијенти за кардиохируршке процедуре се при упису на листе опредељују да ли остају на листи ЗУ или ће бити на централној листи одакле може бити упућен на реализацију у неку другу установу. За растерећивање листа за офталмолошке процедуре (катаракта), Фонд уговара и са приватним установама, контактира осигуранике са офталмолошких листа, и ако су заинтересовани, преусмерава их у приватне ЗУ, а установе са чијих су листа их бришу са разлогом „послат у другу установу“.

Корисници апликације

Запослени у здравственим установама (укупно 49 здравствених установа), запослени у РФЗО (све филијале, Покрајински фонд и Дирекција) и Министарство здравља.

Техничке карактеристике система Веб апликација се састоји из:

1. frontend: За израду frontend дела апликације коришћен је: HTML, CSS, JavaScript, JQuery, Bootstrap framework, JQuery DataTables.

2. backend: Java 1.8 , Jodd framework

3. aplikativni server: Linux, Tomcat 8.145, Java 8

Опис система за управљање базом података DBMS који се користи је MS SQL 2016.

Комуникација са другим DBMS

Код евиденције новог пацијента на листу чекања, позива се сторед процедура која враћа податке о пацијенту (осигуранику) из МЕОП базе.

Да би се подаци о листама објавили на веб страници РФЗО, врши се синхронизовани пренос података на веб сервер РФЗО. Ова активност је у потпуности аутоматизована кроз сервисни који се извршава сваких сат времена.

Делови система

Систем се састоји од следећих целина:

- Веб апликација намењена здравственим установама за потребе евидентирања пацијената на листама чекања;

- Веб апликација намењена РФЗО за потребе праћења листа чекања и креирања извештаја.

34. Апликација за Ad Hoc прикупљање података од здравствених установа из Olana мреже РФЗО Кратак опис система

Ова веб апликација омогућава стручној служби РФЗО да на захтев других сектора или руководства РФЗО брзо и у кратком року дефинише правила и екранске форме за прикупљање података од здравствених установа.

Опис пословног процеса

Сектори у Дирекцији РФЗО активно прелазе са традиционалног начина прикупљања података (excel табеле, мејлови) на централизова и униформисан начин прикупљања података од здравствених установа. У складу са великим бројем пословних процеса који однос између РФЗО и здравственх установа чине комплексним, стручна служба РФЗО креирала је софтверски систем који омогућава брзо креирања веб апликација за прикупљање података од здравствених установа. Сваки сектор има право да према стручној служби РФЗО упути формални захтев у коме описује потребу прикупљања података од стране здравствених установа из Плана мреже, затим описује правила у вези са прикупљањем података (која постају алгоритам у оквиру софтвера) и коначно скупове извештаја и евентуално напредну аналитику над подацима који су предмет прикупљања. Стручна служба РФЗО креира екранске форме и дефинише потребан алгоритам заједно са извештајима који постају доступни сектору који је поднео захтев. Нове екранске форме се представљају у виду посебног подсистема, као веб апликација, која подразумевано садржи и функционалност управљања корисницима који имају право уноса и увида у податке, као и функционалност праћења статуса доставе података од стране здравствених установа.

Корисници апликације

Дирекција РФЗО и филијале РФЗО, здравствене установе из Плана мреже.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Апликација не комуницира са другим системима.

Делови система

Систем се састоји из следећих целина:

- Веб апликација намењена информатичком сектору у РФЗО за креирање нових екранских форми, њихових релација и правила, извештаја над подацима који се прикупљају кроз екранске форме, као и правима за приступ екранским формама;

- Веб апликација намењена здравственим установама у циљу уноса података;

- Веб апликација намењена секторима у РФЗО у циљу увида у прикупљене податке, односно креирање предефинисаних извештаја над прикупљеним подацима.

35. Help desk и тicketing апликација Кратак опис система

Веб апликација за управљање захтевим интерних корисника (запослених у РФЗО).

Опис пословног процеса

Запослени у РФЗО у свом раду користе софтверске системе и информатичку инфраструктуру. У случају настанка проблема у раду појединих система или информатичке опреме, запослени креирају електронске тикете у којима наводе опис проблема и друге релевантне детаље. Запослени у информатичком сектору врше отклањање проблема и о томе обавештавају запослене електронским путем, као и у личном контакту – ако за тим постоји објективна потреба.

Корисници апликације

Дирекција РФЗО, сви запослени у Дирекцији РФЗО.

Техничке карактеристике система

Linux, Apache, PHP7+, MySQL 5.7, JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS

Апликација не комуницира са другим системима.

Делови система

Систем се састоји из следећих целина:

- Веб апликација намењена запосленима у РФЗО за креирање тикета и праћење статуса обраде;

- Веб апликација намењена информатичком сектору у РФЗО за евидентирање предузетих активности у циљу решавања тикета.

Напомена: У складу са уводним излагањем, овај софтверски систем треба заменити централним софтверским системом (Help Desk) са којим ће комуницирати сви преостали софтверски системи РФЗО намењени интерним и екстерним корисницима у циљу оптималног управљања комуникацијом између корисника и успостављања система следљивости. Централни софтверски систем треба да замени постојећу help desk и ticketing апликацију која тренутно не садржи потребне функционалности.

36. Пут лека

Кратак опис система

Централизована веб апликација за потребе ефикасне евиденција и праћења процеса дистрибуције лека унутар здравствене установе.

Функционалност система

Омогућава одговорним лицима РФЗО увид у дистрибуцију лекова унутар здравствених установа и детаљну анализу издавања лека поједничаним пацијентима у оквиру терапије. На основу анализе података доносе се пословне и стратешке одлуке.

Корисници апликације

Запослени РФЗО, здравствени радници

Техничке карактеристике система

Linux, Apache 2.4, PHP7+, Laravel, MySQL 5.7, JavaScript, HTML 5, CSS, WildFly.

Опис система за управљање базом података DBMS који се користи је MySQL 5.7.

Комуникација са другим DBMS:

• Подаци о пацијентима из локалне базе података

• Подаци из електронских фактура

• Подаци о леку из локалних база података

• Подаци о медицинским радницима из локалних база

• ASEBA SxS

Напомена: RESTful веб сервис – JSON фајл формат.

37. Интеракција између лекова Кратак опис система

Веб апликација која омогућава претраживање особина и употребе лекова и препознавање интеракција између различитих лекова.

Функционалност система

Структуиран унос и чување података о свим лековима, са свих постојећих листа, укључујући листу нерегистрованих лекова (листа D). Претрага и увид у податке о лековима, њиховим особинама као и о интеракцији.

Корисници апликације

Запослени РФЗО, здравствени радници, представници фармацеутских компанија.

Техничке карактеристике система

Linux, Apache, PHP, MySQL JavaScript, HTML 5, CSS.

Опис система за управљање базом података DBMS који се користи је MySQL.

Комуникација са другим системима

• Успостављено је аутоматско преузимање дела података о карактеристикама лека из локалне базе података РФЗО

• Успостављена је синхронизација података помоћу веб сервиса са базом РФЗО која садржи податке о карактеристикама лека-процес се обавља једном у 24 часова

• Успостављено је аутоматско преузимање података о медицинским радницима из локалне базе података РФЗО

• Успостављена је синхронизација података помоћу веб сервиса са базом РФЗО која садржи податке о медицинским радницима-процес се обавља једном у 24 часа.

„Web“ сервиси које је неопходно развити за потребе интеграције са спољашњим сарадницима:

- Веб сервиси намењени интеграцији са МУП-овим сервисима

- Веб сервиси намењени интеграцији са ИТ канцеларијом Владе РС

- Веб сервиси намењени интеграцији са ИЗИС системом Министарства здравља

- Веб сервиси намењени интеграцији са eRecept системом Министарства здравља

- Веб сервиси намењени интеграцији са Moj доктор системом Министарства здравља.

Додатне услуге

Понуђач је у обавези да изрши пословну анализу за потребе дефинисања Сервисно Оријентисане Архитектуре и да основу тога адекватно имплементира тражена решења и услуге везане за развој и модификацију постојећих система.

Тражене услуге укључују инсталацију понуђених добара на продукционо и не-продукционо окружење и конфигурацију.

Неопходно је да Извршилац изложи фунцкионалности постојећег решења за двофакторску аутентикацију (SxS) на интеграциону софтверску платформу за потребе интеграције са софтверским системима где је неопходан висок степен безбедности.

Извршилац је у обавези да изврши анализу пословних процеса, изнесе предлоге за оптимизацију процеса и дефинисање детаља функционалне спецификације за имплементацију софтверских решења, са фокусом на редизајн постојећих апликација.

РФЗО је сложен пословни систем који у већини својих пословних процеса подразумева интеракцију више резличитих учесника у процесу било да су они унутар РФЗО или установа које имају потребу за услугама које РФЗО пружа или које су предмет контроле РФЗО. Постојећи софтверски системи РФЗО прилагођени су добрим делом постојећим пословним процесима. Обзиром на увођење великог броја нових софтверских компоненти, а све у складу са дефинисаном стратегијом РФЗО потребно је да прва фаза пројекта обухвати анализу пословних процеса, предлоге за евентуалне измене процеса било у циљу повећања ефикасности рада или прилагођавања процеса функционалностима софтверских решења. Поред пословних процеса у овој фази је битно дефинисати и начин прилагођавања софтверског решења дефинисаној таргет архитектури информационог система РФЗО, системима за заштиту података као и информационе сигурности система. На крају је потребно да се опише детаљан начин интеграције ових софтверских решења са осталим дефинисаним софтверским компонентама у оквиру дефинисане архитектуре информационог ситема РФЗО. Резултат треба да буде испоручен у виду извештаја које ће потврдити стручне службе РФЗО а који ће се састојати из:

- Описа постојећих пословних процеса и „high level“ процесне мапе постојећих процеса (активности, учесници, кораци, документи, „workflow“).

- Предлога за унапређење/прилагођавање пословних процеса обухвећених дефинисаним софтверским решењем (активности, учесници, кораци, документи, „workflow“).

- Описа функционалних захтева који ће бити покривени софтверским решењем – функционална спецификација за имплементацију.

- Дефиниције начина интеграције софтверског решења са остатком софтверских Система у РФЗО.

За потребе извођења ових фаза Извршилац ће спровести низ интервјуа и радионица са стручним службама РФЗО како би кроз дефинисање потребних детаља олакшао имплементацију софтверских решења. За ове потребе РФЗО ће формирати радну групу од свих релевантних учесника који су укључени у пословне процесе обухвећене овим софтверским системима као и запослених у ИТ.

Очекује се да понуђач обезбеди стручне конусултанте са искуством који ће поред анализе бити задужени и да кроз добре примере из праксе упуте стручне службе РФЗО у потенцијал унапређења пословних процеса.

План развоја и имплементације

Развој и имплементација овог софтверског решења треба да се одвија кроз следеће фазе:

1. Испорука Софтвера за интеграцију апликација и наменског интеграционог „security gateway appliance уређаја – прва фаза

2. Услуга анализе и редизајна пословних процеса – друга фаза

3. Услуга пословне анализе за потребе имплементације СОА – трећа фаза

4. Услуга модификације постојећих „web“ сервиса за потребе излагања на ЕСБ – четврта фаза

5. Услуга развоја нових „web” сервиса за потребе излагања на ЕСБ – пета фаза

6. Услуга развоја и излагања „web“ сервиса за потребе интеграције са спољним сарадницима – шеста фаза

Извршилац као саставни део понуде треба да достави детаљан план који би обавезно укључивао све испоруке и фазе уз прецизно навођење датума почетка и краја за сваки елемент. План треба да буде у форми гантограма. Гантограм треба да садржи све фазе, задатке и кључне догађаје (milestones) за успешно увођење система.

Рокови и примопредаја:

Испорука Софтвера за интеграцију апликација и наменског интеграционог „security gateway appliance уређаја (прва фаза) - рок је максимално 90 дана од потписивања Записника о почетку пројекта.

Након испоруке Наручилац и Извршилац потписују Записник о извршеној примопредаји софтвера и уређаја који уједно и подразумева окончање прве фазе.

Услуга анализе и редизајна пословних процеса (друга фаза) - рок за реализацију услуге је максимално 60 дана од тренутка потписивања Записника о извршеној примопредаји софтвера и уређаја.

Након реализације наведене услуге биће потписан Записник који уједно подразумева окончање друге фазе.

Услуга пословне анализе за потребе имплементације СОА (трећа фаза) - рок за реализацију услуге је максимално 60 дана од тренутка потписивања записника о примопредаји претходне фазе.

Након реализације наведене услуге биће потписан Записник који уједно подразумева окончање треће фазе.

Услуга модификације постојећих „web“ сервиса за потребе излагања на ЕСБ (четврта фаза) - рок за реализацију услуге је максимално 150 дана од тренутка потписивања записника о примопредаји претходне фазе.

Након реализације наведене услуге биће потписан Записник који уједно подразумева окончање четврте фазе.

Услуга развоја нових „web” сервиса за потребе излагања на ЕСБ (пета фаза) - рок за реализацију услуге је максимално 180 дана од тренутка потписивања записника о примопредаји претходне фазе.

Након реализације наведене услуге биће потписан Записник који уједно подразумева окончање пете фазе.

Услуга развоја и излагања „web” сервиса за потребе интеграција са спољним сарадницима (шеста фаза) - рок за реализацију услуге је максимално 180 дана од тренутка потписивања записника о примопредаји претходне фазе.

Након реализације наведене услуге биће потписан Записник који уједно подразумева окончање шесте фазе.

Динамика плаћања уговора

Плаћање се врши за сваку фазу појединично по издавању рачуна за сваку фазу појединачно.

Гарантни период

Понуђач се обавезује на гарантни рок од 12 (дванаест) месеци, почевши од датума потписивања Записника о извршеној примопредаји софтвера и уређаја. У гарантном року исправка уочених грешака у испорученом систему, у року од 4 радна дана.

Понуђач се обавезује на гарантни рок од 12 (дванаест) месеци за све услуге, почевши од датума потписивања појединачних записника након окончања фаза бр. 2-6. У гарантном року исправка уочених грешака у испорученом систему, у року од 4 радна дана.

Напомена: Понуђач је у обавези да сходно члану 71. став 2. ЗЈН поштује техничке стандарде приступачности за особе са инвалидитетом, односно да техничко решење буде приступачно за све кориснике.

IV УПУТСТВО ПОНУЂАЧИМА

1. Језик

1.1. Понуда и остала документација која се односи на понуду морају бити на српском језику.

1.2. Понуђач није у обавези да приликом сачињавања понуде употребљава печат. Наручилац неће одбити као неприхватљиву понуду која не садржи печат, у складу са Законом о привредним друштвима („Сл гласник РС“, број 36/2011, 99/2011, 83//2014 –др. закон, 5/2015, 44/2018, 95/2018).

2. Обавезна садржина понуде и начин попуњавања образаца датих у конкурсној документацији

2.1. Понуђач подноси понуду која садржи следеће документе:

1) попуњен образац Подаци о понуђачу, уколико понуђач самостално подноси понуду или када понуђач подноси понуду са подизвођачем - образац бр.1 у конкурсној документацији;

2) попуњен образац Подаци о понуђачу у заједничкој понуди, уколико понуду подноси група понуђача - образац бр. 2 у конкурсној документацији;

3) попуњен образац Подаци о подизвођачу, уколико понуђач делимично извршење набавке поверава подизвођачу - образац бр. 3 у конкурсној документацији;

4) попуњен и потписан образац Xxxxxx за јавну набавку: Услугa успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО – образац бр. 4 у конкурсној документацији;

5) попуњен и потписан образац 4.1 - Понуда за јавну набавку: Услугa успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО, који у себи садржи образац структуре цене.

6) Попуњен и потписан образац Xxxxxx понуђача о независној понуди (образац бр. 5 у конкурсној документацији);

7) Попуњен и потписан образац Xxxxxx понуђача у складу са чланом 75. став 2. ЗЈН (образац бр. 6 у конкурсној документацији);

8) попуњен и потписан образац – Xxxxxxx/референце (образац бр. 9, у конкурсној документацији);

9) План у форми гантограма;

10) доказе о испуњености обавезних и додатних услова за учешће у складу са упутствима и инструкцијама датим у одељку V – Услови за учешће и доказивање испуњености услова;

11) потписан модел уговора – одељак VI у конкурсној документацији;

12) средство финансијског обезбеђења за озбиљност понуде у складу са тачком 5. овог Упутства;

2.2. Понуђач доставља понуду у складу са обрасцима који су саставни део конкурсне документације, као и на сопственим обрасцима потраживаним у конкурсној документацији.

2.3. Подаци који се уносе у образац понуде и друге обрасце предвиђене конкурсном документацијом морају бити јасни и недвосмислени, унети електронским путем или уписани, читко, хемијском оловком.

3. Цена у понуди

3.1. Цена у понуди мора бити исказана у динарима, без и са урачунатим ПDВ-ом и подразумева све пратеће трошкове.

3.2. Ако је у понуди исказана неуобичајено ниска цена, Наручилац ће поступити у складу са чланом 92. Закона о јавним набавкама.

3.3. Цена у понуди је непромењива и не може се мењати након отварања понуда.

3.4. У цену у понуди морају да буду урачунати и кроз њу исказани сви попусти и све погодности које понуђач нуди. Посебни попусти и погодности неће бити узимани у обзир приликом примене критеријума за доделу уговора.

4. Рок и начин плаћања

4.1. Плаћање уговорене цене за услугу успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО вршиће се након окончања сваке фазе и то:

Редни број	Назив фазе
1	Испорука софтвера за интеграцију апликација и наменског интеграционог „security gateway appliance“ урађаја
2	Услуга анализе и редизајна пословних процеса
3	Услуга пословне анализе за потребе имплементације СОА
4	Услуга модификације постојећих „web“ сервиса за потребе излагања на ЕСБ
5	Услуга развоја нових „web“ сервиса за потребе излагања на ЕСБ
6	Услуга развоја и излагања „web“ сервиса за потребе интеграције са спољним сарадницима

Плаћање ће се вршити у року од најмање 30 а надуже 45 дана од дана издавања рачуна. Рачун се издаје након окончања сваке фазе односно након потписивања записника.

4.2. Понуђач је у обавези да рачун достави Наручиоцу најкасније 5 дана од дана издавања рачуна.

4.3. Уколико понуђач у понуди наведе другачији начин и краћи рок плаћања од наведеног у конкурсној докментацији, његова понуда ће бити одбијена као неприхватљива.

5. Обезбеђење за озбиљност понуде

5.1.Банкарска гаранција доставља се УЗ ПОНУДУ. У супротном понуда ће бити одбијена као неприхватљива.

5.2 Банкарска гаранција:

Мора да садржи клаузуле: неопозива, безусловна и наплатива на први позив, са роком важења који је 30 дана дужи од рока важења понуде, с тим да евентуални продужетак рока важења понуде има за последицу и продужење рока важења банкарске гаранције за исти број дана,

Мора бити издата на износ од 10% вредности понуде без ПДВ-а.

Не може да садржи додатне услове за исплату, краће рокове, мањи износ, или промењену месну надлежност за решавање спорова. У супротном, сматраће се да није достављена на прописани начин, у ком случају ће понуда бити одбијена као неприхватљива.

5.3 Може бити издата од иностране банке само ако је тој банци додељен кредитни рејтинг коме одговара најмање ниво кредитног квалитета 3 (инвестициони ранг). У том случају, понуђач је обавезан да Наручиоцу достави контрагаранцију домаће банке.

5.4 Наручилац има право да у целини наплати банкарску гаранцију за озбиљност понуде, у случају да:

- Понуђач након истека рока за подношење понуда измени, допуни или опозове своју понуду,

- Понуђач, након што је обавештен о прихватању понуде од стране Наручиоца, у току периода важења понуде не потпише или одбије да потпише уговор или не достави средство обезбеђења за добро извршење посла у року од 10 дана од дана закључења уговора,

- Понуђач достави неистините податке у понуди,

- Понуђач чија је понуда на основу Извештаја о стручној оцени понуда оцењена као најповољнија, у року од 5 дана од дана пријема писменог позива Наручиоца не достави на увид оригинал или оверену фотокопију свих или појединих доказа које Xxxxxxxxx захтева.

5.5 Наручилац ће изабраном понуђачу вратити банкарску гаранцију за озбиљност понуде након закључења уговора и предаје средства обезбеђења за добро извршење посла, на његов писмени захтев.

5.6 Наручилац ће понуђачима са којима није закључен уговор вратити банкарску гаранцију за озбиљност понуде, након што изабрани понуђач закључи уговор и преда средство обезбеђења за добро извршење посла Xxxxxxxxx, на њихов писмени захтев.

Уколико понуду подноси група понуђача средство финансијског обезбеђења за озбиљност понуде издаје се у складу са СПОРАЗУМОМ.

6. Обезбеђење за добро извршење посла

6.1 Изјава (писмо) о намерама банке (оригинал) доставља се УЗ ПОНУДУ. У супротном понуда ће бити одбијена као неприхватљива.

Изјава о намерама банке да ће банка понуђачу издати банкарску гаранцију за добро извршење посла:

- Мора бити оверена и потписана од стране овлашћеног лица банке,

- Мора бити обавезујућег карактера,

- Мора да садржи: датум издавања, назив, место и адресу банке (гарант), понуђача (клијент

- налогодавац) и корисника банкарске гаранције (Наручилац),

- Мора да садржи навод да ће банка на захтев клијента (понуђача) издати неопозиву, безусловну и на први позив наплативу банкарску гаранцију за добро извршење посла у износу од 10% вредности уговора без ПДВ-а,

- Мора да садржи навод да ће гаранција бити издата за рачун клијента (понуђача) уколико његова понуда буде изабрана као најповољнија у поступку XX број 000-0-000/20-11.

6.2 Банкарска гаранција за добро извршење посла се доставља у року од 10 дана од дана закључења уговора, са роком важности 30 дана дуже од уговореног рока за извршење уговорне обавезе. У супротном ће се сматрати да је Извршилац одустао/одбио да закључи уговор, и у ком случају Наручилац може да реализује средство обезбеђења за озбиљност понуде и да закључи уговор са првим следећим најповољнијим понуђачем.

Понуђач/Извршилац може да достави банкарску гаранцију за добро извршење посла са роком важења не краћим од 6 месеци рачунајући од дана почетка важења банкарске гаранције, с тим да је обавезан да најкасније 8 дана пре истека банкарске гаранције, без обавештења Наручиоца, продужава гаранцију банке на исти износ, односно износ који је умањен за износ евентуално активирене гаранције. Уколико Понуђач/Извршилац не продужи банкарску гаранцију у наведеном року Наручилац ће у целини наплатити банкарску гаранцију за добро извршење посла, а може и раскинути уговор. Последња гаранција, односно последње продужење банкарске гаранције за добро извршење посла, мора бити са роком важења који је најмање 30 дана дужи од уговореног рока за извршење уговорне обавезе.

Достављена банкарска гаранција не може да садржи додатне услове за исплату, краће рокове, мањи износ, или промењену месну надлежност за решавање спорова. У супротном, сматраће се да није достављена на прописани начин, у ком случају ће се сматрати да је изабрани понуђач одустао/одбио да закључи уговор, и у ком случају Наручилац може да реализује

средство обезбеђења за озбиљност понуде и да закључи уговор са првим следећим најповољнијим понуђачем.

Наручилац има право да у целини наплати банкарску гаранцију за добро извршење посла, у случају да:

- Извршилац не извршава уговорне обавезе у уговореном року, под уговореним условима и на уговорени начин,

- Извршилац једнострано раскине уговор супротно уговору.

Наручилац има право да наплати банкарску гаранцију за добро извршење посла у случају наплате уговорне казне.

Наручилац ће Извршиоцу вратити банкарску гаранцију за добро извршење посла након истека рока на који је издата, уколико није реализована, на његов писмени захтев.

Уколико понуду подноси група понуђача средство финансијског обезбеђења издаје се у складу са СПОРАЗУМОМ.

7. Овлашћење за потписивање

7.1 Конкурсна документација се може потписати својеручно или оверити факсимилом.

7.2 Уколико конкурсну документацију потписује лице које није овлашћено за заступање по решењу из регистра привредних субјеката, потребно је доставити Овлашћење за потписивање конкурсне документације.

7.3 Уколико понуђачи подносе заједничку понуду, група понуђача може да се определи да обрасце дате у конкурсној документацији потписују сви понуђачи из групе понуђача или група понуђача може да одреди једног понуђача из групе који ће попуњавати обрасце дате у конкурсној документацији, и у том случају прилажу овлашћење дато том понуђачу, осим образаца бр. 5 и бр. 6.

7.4 Уколико понуђачи подносе заједничку понуду, сваки понуђач из групе понуђача мора самостално потписати Образац бр. 5 – Изјава понуђача о независној понуди и Образац бр. 6 – Изјава понуђача у складу са чланом 75. став 2. Закона о јавним набавкама и доставити у понуди.

8 Подношење понуде

8.1 Понуђач понуду подноси непосредно или путем поште.

8.2 Понуђач подноси понуду у затвореној коверти или кутији, затворену на начин да се приликом отварања понуда може са сигурношћу утврдити да се први пут отвара.

8.3 Коверат или кутија са понудом мора имати ознаку "ПОНУДА ЗА ЈАВНУ НАБАВКУ УСЛУГЕ УСПОСТАВЉАЊА ПЛАТФОРМЕ ЗА РАЗМЕНУ ПОДАТАКА УНУТАР РФЗО, КАО И ИЗМЕЂУ РФЗО И СПОЉНИХ КОРИСНИКА ПОСРЕДСТВОМ СИСТЕМА ЗА ПОДРШКУ СИНХРОНИМ И АСИНХРОНИМ ТРАНСПОРТНИМ ПРОТОКОЛИМА ЗА ПОЗИВ ФУНКЦИЈА ПОСЛОВНИХ АПЛИКАЦИЈА РФЗО, број набавке 000-0-000/20-11, - НЕ ОТВАРАТИ".

8.4 На полеђини коверте или кутије понуђач наводи своје пословно име, адресу, телефон, е– mail адресу и одговорно лице.

8.5 Понуду доставити на адресу Републичког фонда за здравствено осигурање у Београду, ул. Xxxxxx Xxxxxxxxxx бр. 2, ПИСАРНИЦА, од 7:30-15:30.

8.6 Благовременим се сматрају понуде које Xxxxxxxxx стигну најкасније до 01.06.2020.године до 11,30 часова, без обзира на начин како су послате.

9. Могућност подношења понуде за једну или више партија

9.1 Предметна јавна набавка није обликована по партијама.

10. Понуда са варијантама

10.1 Понуда са варијантама није дозвољена.

11. Рок важења понуде

11.1 Рок важења понуде обавезно се наводи у понуди и не може бити краћи од 90 дана од

дана отварања понуда.

11.2 У случају да понуђач наведе краћи рок важења понуде, понуда ће бити одбијена као неприхватљива.

12. Измене, допуне и опозив понуде

12.1 У року за подношење понуде понуђач може да измени, допуни или опозове своју понуду.

12.2 Понуђач може да измени, допуни или опозове своју понуду након достављања исте под условом да наручилац прими писано обавештење о измени, допуни или опозиву пре крајњег рока који је прописан за подношење понуда.

12.3 Обавештење о измени, допуни или опозиву понуде треба да буде припремљено, запечаћено, обележено и послато на исти начин као и претходна понуда. Наручилац ће ово обавештење прихватити као благовремено уколико је достављено код наручиоца пре истека рока за подношење понуда.

12.4 По истеку рока за подношење понуда понуђач не може да мења своју понуду. У случају да након истека рока за подношење понуда, понуђач повуче своју понуду, Наручилац ће активирати средство обезбеђења у складу са тачком 5.2 овог Упутства. Понуђач је одговоран за сваку штету коју Xxxxxxxxx претрпи у случају опозива понуде након истека рока за подношење понуда.

13. Учешће са подизвођачем

13.1 Понуђач може реализовати предмет набавке и преко подизвођача.

13.2 Уколико реализује набавку преко подизвођача, понуђач је у обавези и да наведе проценат укупне вредности набавке који ће поверити подизвођачу, а који не може бити већи од 50% као и део предмета набавке који ће извршити преко подизвођача.

13.3 Ако понуђач у понуди наведе да ће делимично извршење набавке поверити подизвођачу, дужан је да наведе назив подизвођача, а уколико уговор између наручиоца и понуђача буде закључен, тај подизвођач ће бити наведен у уговору.

13.4 Понуђач у потпуности одговара наручиоцу за извршење уговорене набавке, без обзира на број подизвођача.

13.5 Извршилац не може ангажовати као подизвођача лице које није навео у понуди, у супротном наручилац ће реализовати средство обезбеђења и раскинути уговор, осим ако би раскидом уговора наручилац претрпео знатну штету. У овом случају наручилац ће обавестити организацију надлежну за заштиту конкуренције – члан 80. став 12. и 13. Закона о јавним набавкама (''Сл. гласник РС'' бр. 124/12, 14/15 и 68/15).

13.6 Извршилац може ангажовати као подизвођача лице које није навео у понуди, ако је на страни подизвођача након подношења понуде настала трајнија неспособност плаћања, ако то лице испуњава све услове одређене за подизвођача и уколико добије претходну сагласност наручиоца - члан 80. став 14. Закона о јавним набавкама (''Сл. гласник РС'' бр.124/12, 14/15 и 68/15).

14. Заједничка понуда

14.1 Понуду може поднети и група понуђача.

14.2 Саставни део заједничке понуде је споразум којим се понуђачи из групе међусобно и према наручиоцу обавезују на извршење јавне набавке, а који обавезно садржи податке о:

1) члану групе који ће бити носилац посла, односно који ће поднети понуду и који ће заступати групу понуђача пред наручиоцем;

2) опис послова сваког од понуђача из групе понуђача у извршењу уговора.

14.3 У случају заједничке понуде понуђачи одговарају Наручиоцу неограничено солидарно.

15. Јавно отварање понуда

15.1 Наручилац ће извршити јавно отварање понуда дана 01.06.2020. године са почетком у

12,00 часова.

15.2 Понуде ће се отварати редоследом којим су примљене/заведене од стране Наручиоца.

15.3 Представници понуђача, који присуствују јавном отварању понуда, морају Комисији наручиоца поднети овлашћење за учешће у поступку отварања понуда.

16. Трошкови припремања понуде

16.1 Понуђач може да у оквиру понуде достави укупан износ и структуру трошкова припремања понуде.

16.2 Трошкове припреме и подношења понуде сноси искључиво понуђач и не може тражити од наручиоца накнаду трошкова.

16.3 Ако је поступак јавне набавке обустављен из разлога који су на страни наручиоца, наручилац је дужан да понуђачу надокнади трошкове прибављања средства обезбеђења, под условом да је понуђач тражио накнаду тих трошкова у својој понуди.

17. Неблаговремене понуде

17.1 Биће размотрене само понуде које су благовремено предате.

17.2 Благовременим се сматрају понуде примљене од стране наручиоца до 01.06.2020. године до 11,30 часова, без обзира на начин на који су послате.

17.3 Неблаговремене понуде се неће разматрати.

17.4 Наручилац ће, након окончања поступка отварања понуда, неблаговремену понуду вратити неотворену понуђачу, са назнаком да је поднета неблаговремено.

18. Поверљивост података

18.1 Предметна јавна набавка не садржи поверљиве информације које наручилац ставља на располагање.

18.2 Подаци које понуђач оправдано означи као поверљиве, биће коришћени само у предметној јавној набавци и неће бити објављени приликом отварања понуда, нити у наставку поступка или касније (сходно чл. 14. ЗЈН-а).

18.3 Наручилац ће као поверљиве третирати податке у понуди који су садржани у документима који су означени као такви, одн. који у горњем десном углу садрже ознаку ''ПОВЕРЉИВО'', као и испод поменуте ознаке потпис овлашћеног лица понуђача.

18.4 Уколико се поверљивим сматра само одређени податак садржан у документу који је достављен уз понуду, поверљив податак мора бити обележен црвеном бојом, поред њега мора бити наведено ''ПОВЕРЉИВО'', а испод поменуте ознаке потпис овлашћеног лица понуђача.

18.5 Наручилац не одговара за поверљивост података који нису означени на поменути начин.

18.6 Неће се сматрати поверљивим докази о испуњености обавезних услова, цена и остали подаци из понуде који су од значаја за примену елемената критеријума и рангирање понуде.

18.7 Информације у вези са прегледом и оценом понуда, као и у вези са предлогом одлуке о додели уговора неће бити обелодањене ниједном понуђачу или било којем другом лицу које није званично укључено у процес стручне оцене понуда до тренутка објављивања одлуке о додели уговора.

18.8 Сваки покушај понуђача да утиче на Наручиоца у процесу стручне оцене понуда или доношења одлуке о додели уговора, може да доведе до одбијања понуде тог понуђача.

19. Додатне информације и појашњења у вези са припремањем понуде

19.1 Заинтересовано лице може, у писаном облику тражити од наручиоца додатне информације или појашњења у вези са припремањем понуде, при чему може да укаже наручиоцу и на евентуално уочене недостатке и неправилности у конкурсној документацији, најкасније 5 дана пре истека рока за подношење понуда.

19.2 Наручилац ће у року од 3 (три) дана од дана пријема захтева за додатним информацијама или појашњења конкурсне документације, одговор објавити на Порталу јавних набавки и на својој интернет страници (xxx.xxxx.xx).

19.3 Захтев за додатним информацијама или појашњењима у вези са припремањем понуде заинтересовано лице ће упутити уз напомену "Додатне информације и појашњења – јавна набавка бр. 000-0-000/20-11 (јавна набавка: Услугa успостављања платформе за

размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО)'' на неки од следећих начина:

1) путем поште на адресу Наручиоца Xxxxxx Xxxxxxxxxx бр. 2, Београд,

2) путем електронске поште на адресу xxxxxx.xxxxxxxxx@xxxx.xx.

Додатна појашњења послата након истека радног времена, сматраће се да су примљена наредног радног дана.

19.4 Тражење додатних информација и објашњења телефоном није дозвољено.

19.5 Комуникација у поступку предметне јавне набавке ће се вршити у складу са чланом 20. Закона о јавним набавкама.

20. Додатна објашњења од понуђача

20.1 Наручилац може приликом стручне оцене понуда да захтева од понуђача додатна објашњења која ће му помоћи при прегледу, вредновању и упоређивању понуда.

20.2 Захтев за објашњењем, као и само објашњење биће искључиво у писaној форми. Кроз објашњење се не може тражити, нудити или дозволити никаква измена цене, односно измена неког другог битног елемента понуде, осим уколико се ради о исправци рачунске грешке уочене од стране Наручиоца током оцене понуда.

20.3. Наручилац може да врши и контролу (увид) код понуђача односно његовог подизвођача.

20.4 Наручилац ће, уз сагласност понуђача, извршити исправке рачунских грешака уочених приликом разматрања понуде, а по окончаном поступку отварања понуда.

20.5 У случају разлике између јединичне и укупне цене, меродавна је јединична цена.

20.6 Ако се понуђач не сагласи са исправком рачунских грешака, наручилац ће његову понуду одбити као неприхватљиву.

21. Критеријум за доделу уговора

21.1 Критеријум за доделу уговора је најнижа понуђена цена.

21.2 Резервни елемент критеријума, у смислу члана 84. став 4. Закона о јавним набавкама, јесте дужи рок плаћања рачуна. Уколико након стручне оцене достављених понуда, две или више прихватљивих понуда буду имале исту цену, предност ће имати она понуда понуђача који понуди дужи рок плаћања рачуна.

22. Негативне референце

22.1 Наручилац може одбити понуду уколико поседује доказ да је понуђач у претходне три године пре објављивања позива за подношење понуда у поступку јавне набавке:

1) поступао супротно забрани из чл. 23. и 25. Закона о јавним набавкама;

2) учинио повреду конкуренције;

3) доставио неистините податке у понуди или без оправданих разлога одбио да закључи уговор о јавној набавци, након што му је уговор додељен;

4) одбио да достави доказе и средства обезбеђења на шта се у понуди обавезао.

22.2 Наручилац може одбити понуду уколико поседује доказ који потврђује да понуђач није испуњавао своје обавезе по раније закљученим уговорима о јавним набавкама који су се односили на исти предмет набавке, за период од претходне три године пре објављивања позива за подношење понуда. Доказ може бити:

- правоснажна судска одлука или коначна одлука другог надлежног органа;

- исправа о реализованом средству обезбеђења испуњења обавеза у поступку јавне набавке или испуњења уговорних обавеза;

- исправа о наплаћеној уговорној казни;

- рекламације потрошача, односно корисника, ако нису отклоњене у уговореном року;

- изјава о раскиду уговора због неиспуњења битних елемената уговора дата на начин и под условима предвиђеним законом којим се уређују облигациони односи;

- доказ о ангажовању на извршењу уговора о јавној набавци лица која нису означена у понуди као подизвођачи, односно чланови групе понуђача;

- други одговарајући доказ примерен предмету јавне набавке, који се односи на испуњење обавеза у ранијим поступцима јавне набавке или по раније закљученим уговорима о јавним набавкама.

22.3 Наручилац може одбити понуду ако поседује доказ из чл. 82 става 3. тачка 1) Закона, који се односи на поступак који је спровео или уговор који је закључио и други наручилац ако је предмет јавне набавке истоврсан.

23. Поштовање обавеза које произилазе из важећих прописа

23.1 Понуђач је дужан да у оквиру своје понуде достави изјаву да је поштовао све обавезе које произилазе из важећих прописа о заштити на раду, запошљавању и условима рада, заштити животне средине, као и да нема забрану обављања делатности која је на снази у време подношења понуде (образац бр. 6 у конкурсној документацији).

24.Коришћење патента и одговорност за повреду заштићених права интелектуалне својине трећих лица

24.1 Накнаду за коришћење патената, као и одговорност за повреду заштићених права интелектуалне својине трећих лица сноси понуђач.

25. Начин и рок за подношење захтева за заштиту права понуђача

25.1 Захтев за заштиту права може да поднесе понуђач, односно заинтересовано лице, који има интерес за доделу уговора у конкретном поступку јавне набавке и који је претрпео или би могао да претрпи штету због поступања наручиоца противно одредбама Закона о јавним набавкама. Захтев за заштиту права подноси се наручиоцу, а копија се истовремено доставља Републичкој комисији.

25.2 Захтев за заштиту права подноси се наручиоцу непосредно – предајом у писарници наручиоца, електронском поштом на адресу xxxxxx.xxxxxxxxx@xxxx.xx, факсом на број (000) 0000 000, 0000 000 или препорученом пошиљком са повратницом, на адресу ул. Xxxxxx Xxxxxxxxxx бр. 2, Београд, у радно време Републичког фонда, и то од 7:30-15:30. Захтев примљен после наведеног времена, сматраће се да је примљен првог наредног радног дана.

25.3 Захтев за заштиту права може се поднети у току целог поступка јавне набавке, против сваке радње наручиоца, осим уколико Законом о јавним набавкама није другачије одређено. Наручилац објављује Обвештење о поднетом захтеву за заштиту права на Порталу јавних набавки и на својој интернет страници, најкасније у року од 2 дана од дана пријема захтева за заштиту права.

25.4 Уколико се захтевом за заштиту права оспорава врста поступка, садржина позива за подношење понуда или конкурсне документације, захтев ће се сматрати благовременим уколико је примљен од стране наручиоца најкасније 7 дана пре истека рока за подношење понуда, без обзира на начин достављања и уколико је подносилац захтева у складу са чланом 63. став 2 Закона о јавним набавкама (''Сл. гласник РС'' бр.124/12, 14/15 и 68/15) указао наручиоцу на евентуалне недостатке и неправилности, а наручилац исте није отклонио.

25.5 Захтев за заштиту права којим се оспоравају радње које наручилац предузме пре истека рока за подношење понуда, а након истека рока из претходног става (тачка 26.4), сматраће се благовременим уколико је поднет најкасније до истека рока за подношење понуда.

25.6 После доношења одлуке о додели уговора или одлуке о обустави поступка јавне набавке, рок за подношење захтева за заштиту права је 10 дана од дана објављивања одлуке на Порталу јавних набавки.

25.7 Захтевом за заштиту права не могу се оспоравати радње наручиоца предузете у поступку јавне набавке ако су подносиоцу захтева били или могли бити познати разлози за његово подношење пре истека рока за подношење понуда, а подносилац захтева га није поднео пре истека тог рока.

25.8 Ако је у истом поступку јавне набавке поново поднет захтев за заштиту права од стране истог подносиоца захтева, у том захтеву се не могу оспоравати радње наручиоца за које је подносилац захтева знао или могао знати приликом подношења претходног захтева.

25.9 Захтев за заштиту права не задржава даље активности наручиоца у поступку јавне набавке

у складу са одредбама члана 150. Закона о јавним набавкама (''Сл. гласник РС'' бр.124/12, 14/15 и 68/15). Наручилац може да одлучи да заустави даље активности у случају подношења захтева за заштиту права и у том случају ће у обавештењу о поднетом захтеву за заштиту праву навести да зауставља даље активности у поступку јавне набавке.

25.10 Подносилац захтева је дужан да на рачун буџета Републике Србије уплати таксу у изнoсу од 250.000,00 динара ако се захтев за заштиту права подноси пре отварања понуда, на 840-30678845-06, шифра плаћања: 153 или 253, позив на број: број или друга ознака конкретне јавне набавке (редни број јавне набавке), сврха уплате: Републичка административна такса, корисник: буџет Републике Србије. Упутство о уплати таксе за подношење захтева за заштиту права може се наћи на интернет страници Републичке комисије за заштиту права у поступцима јавних набавки xxxx://xxx.xxx.xxx.xx .

25.11 Ако се захтев за заштиту права подноси након отварања понуда, подносилац захтева је дужан да на рачун буџета Републике Србије уплати таксу у износу од 0,1 % процењене вредности јавне набавке, односно понуђене цене понуђача коме је додељен уговор, ако је та вредност већа од 120.000.000,00 динара.

25.12 Поступак заштите права понуђача регулисан је одредбама чл. 138. - 167. Закона о јавним набавкама.

26. Одлука о додели уговора

26.1 Наручилац ће у року од 25 дана од дана отварања понуда донети одлуку о додели уговора осим у нарочито оправданим случајевима када рок за доношење одлуке може бити 40 дана од дана отварања понуда.

27. Увид у документацију

27.1 Понуђач има право да изврши увид у документацију о спроведеном поступку јавне набавке после доношења одлуке о додели уговора, односно одлуке о обустави поступка о чему може поднети писани захтев наручиоцу.

27.2 Наручилац је дужан да понуђачу који поднесе захтев омогући увид и копирање документације из поступка о трошку подносиоца захтева, у року од два дана од дана пријема писаног захтева, уз обавезу да заштити податке у складу са тачком 20. из овог Упутства.

28. Рок за закључење уговора

28.1 Уговор ће бити закључен са изабраним понуђачем у року од 8 дана од дана протека рока за подношење захтева за заштиту права из члана 149. Закона о јавним набавкама.

28.2 У случају да је поднета само једна понуда наручилац може закључити уговор пре истека рока за подношење захтева за заштиту права, у складу са чланом 112. став 2. тачка 5) Закона о јавним набавкама.

28.3 Уколико изабрани понуђач одбије да закључи уговор, односно не достави средство обезбеђења за добро извршење посла из тачке 6. овог Упутства, приступиће се заључивању уговора са првим следећим најповољнијим понуђачем.

29. Измена и допуна конкурсне документације, одустајање од јавне набавке

29.1 Наручилац задржава право да:

1) измени или допуни конкурсну документацију уколико се, у року предвиђеном за достављање понуда, укаже потреба за тим, с тим што је дужан да све новонастале измене или допуне конкурсне документације, објави на Порталу јавних набавки и на својој интернет страници (сходно члану 63. Закона о јавним набавкама).

2) одустане од вршења избора ако установи да ниједна понуда не одговара захтевима из конкурсне документације.

3) одустане од вршења избора ако дође до престанка потребе наручиоца за предметним добром.

30. Измена уговора

Рок за извршење услуге успостављања платформе за размену података (и појединачних фаза) може се продужити у случају више силе дефинисане уговором и у случају да Извршилац није у року извршио услугу успостављања из разлога који су на страни Наручиоца и који су онемогућили да се услуга заврши у уговореном року.

V УСЛОВИ ЗА УЧЕШЋЕ И ДОКАЗИВАЊЕ ИСПУЊЕНОСТИ УСЛОВА

1. Услови за учешће у поступку

1.1. Право на учешће у поступку предметне јавне набавке има понуђач који испуњава ОБАВЕЗНЕ УСЛОВЕ за учешће у поступку јавне набавке, и то:

1) да је регистрован код надлежног органа, односно уписан у одговарајући регистар;

2) да он и његов законски заступник није осуђиван за неко од кривичних дела као члан организоване криминалне групе, да није осуђиван за кривична дела против привреде, кривична дела против животне средине, кривично дело примања или давања мита, кривично дело преваре;

3) да је измирио доспеле порезе, доприносе и друге јавне дажбине у складу са прописима Републике Србије или стране државе када има седиште на њеној територији;

4) да је поштовао обавезе које произлазе из важећих прописа о заштити на раду, запошљавању и условима рада, заштити животне средине, као и да нема забрану обављања делатности која је на снази у време подношења понуде.

1.2. Право на учешће у поступку јавне набавке има понуђач који испуњава ДОДАТНЕ УСЛОВЕ за учешће у поступку јавне набавке, и то:

1) Финансијски капацитет:

1. да је понуђач у 2016, 2017. и 2018. години остварио пословни приход у минималном износу од 700.000.000,00 динара без ПДВ;

2. Да понуђач у последњих 6 (шест) месеци пре дана објављивања позива није имао блокаду на својим текућим рачунима;

2) Пословни капацитет:

1. Да понуђач има уведене следеће системе управљања:

• ИСО 9001:2015 - систем управљања квалитетом.

• ИСО 27001:2013 - систем управљања безбедности информација.

• ИСО 20000-1:2011 - систем управљања сервисима.

2. Да поседује ауторизацију произвођача за продају понуђене интеграционе платфоме.

3. Да поседује ауторизацију произвођача за сервисе постојећег решења за двофакторску аутентификацију.

4. Да је реализовао најмање један WEB базирани софтверски пројекат:

o реализован у складу са сервисно оријентисаном архитектуром (СОА),

o све WEB странице корисничког интерфејса су у кладу са Web Content Accessibility Guidelines 2.0

o са подршком за следеће претраживаче Microsoft Edge, Mozilla Firefox 5+, Google Chrome 12+,

o са омогућеним приступом софтверском систему са било ког места у било ком тренутку у складу са улогом корисника у оквиру система

o који укључује испоруку или интеграцију са софтверским системом за двофакторску аутентикацију

за минимално 100 корисника, у институцији/организацији чији су примарни послови одређени Законом, сличне делатности као Наручилац, минималне вредности 10.000.000,00 динара без ПДВ, у последње 3 (три) године пре дана објављивања позива за подношење понуда.

3) Кадровски капацитет:

Kадровски капацитет понуђач испуњава уколико понуди стручни тим оспособљен за реализацију јавне набавке који се састоји од:

1. једног руководиоца пројекта који мора да има:

- Минимум 8 (осам) година искуства на вођењу и управљању имплементацијом софтверских пројеката- Одговарајући сертификат за руководиоца пројекта (Project Manager) PRINCE2 или PMP.

2. једног пословног аналитичара који мора да поседује адекватан сертификат за пословну анализу PMI- PBA или сличан

3. минимум четири запослена/ангажована лица на позицији програмера, софтверског инжењера или слично који ће бити одговорни за извршење уговора;

4. минимум два запослена/ангажована сертификована службеника за заштиту личних података.

2. Докази који се достављају уз понуду

2.1. Доказ за услов из тачке 1.1. подтачка 1):

Правна лица:Извод из Регистра АПР-а, односно извод из Регистра надлежног Привредног суда.

Предузетници: Извод из Регистра АПР-а, односно извод из одговарајућег Регистра;

2.2. Доказ за услов из тачке 1.1. подтачка 2): Правна лица:

1) Извод из казнене евиденције, односно уверење надлежног суда (Основног суда, Вишег суда) на чијем подручју се налази седиште правног лица, односно седиште представништва или огранка страног правног лица, којим се потврђује да правно лице није осуђивано за кривична дела против привреде, кривична дела против животне средине, кривично дело примања или давања мита, кривично дело преваре.

Напомена: Уколико уверење Основног суда не обухвата податке из казнене евиденције за кривична дела која су у надлежности Редовног кривичног Одељења Вишег суда, потребно је поред уверења Основног суда доставити и уверење Вишег суда на чијем подручју је седиште домаћег правног лица, односно седиште представништва или огранка страног правног лица.

2) Извод из казнене евиденције Посебног Одељења за организовани криминал Вишег суда у Београду, којим се потврђује да правно лице није осуђивано за неко од кривичних дела организованог криминала.

3) Извод из казнене евиденције, односно уверење надлежне полицијске Управе МУП-а, којим се потврђује да законски заступник понуђача није осуђиван за кривична дела против привреде, кривична дела против животне средине, кривично дело примања или давања мита, кривично дело преваре и неко од кривичних дела организованог криминала (захтев се може поднети према месту рођења или месту пребивалишта закконског заступника). Уколико понуђач има више законских заступника дужан је да достави доказ за сваког од њих.

Предузетници и физичка лица: Извод из Казнене евиденције полицијске Управе МУП-а, којим се потврђује да законски заступник понуђача није осуђиван за кривична дела против привреде, кривична дела против животне средине, кривично дело примања или давања мита, кривично дело преваре (захтев се може поднети према месту рођења или месту пребивалишта);

2.3. Доказ за услов из тачке 1.1. подтачка 3):

Уверење Пореске управе Министарства финансија и привреде да је измирио доспеле порезе и доприносе и уверење надлежне управе локалне самоуправе да је измирио обавезе по основу изворних локалних јавних прихода или потврду Агенције за приватизацију да се понуђач налази у поступку приватизације;

2.4. Доказ за услов из тачке 1.1. подтачка 4):

Попуњен и потписан образац Xxxxxx понуђача о поштовању обавеза које произлазе из важећих прописа о заштити на раду, запошљавању и условима рада, заштити животне средине као и да нема забрану обављања делатности која је на снази у време подношења понуде. (образац бр. 6 у конкурсној документацији);

Докази додатних услова:

2.5. Финансијски капацитет:

1. Извештај о бонитету за јавне набавке (образац БОН-XX), који издаје Агенција за привредне регистре, који мора да садржи: статусне податке понуђача, сажети биланс стања и биланс успеха за обрачунске године (2016, 2017. и 2018. година);

2. Потврда Народне банке Србије о броју дана неликвидности, за период од претходних 6 (шест) месеци пре дана објављивања позива за подношење понуда;

2.6. Пословни капацитет::

1. фотокопије важећих акредитованих сертификата ИСО 9001:2015, ИСО 27001:2013, ИСО 20000-1:2011,

2. ауторизација произвођача понуђене интеграционе платформе за продају насловљена на Понуђача за ову предметну набавку или потврда да је понуђач произвођач платформе,

3. ауторизација произвођача постојећег решења за двофакторску аутентикацију за сервисе насловљена на Понуђача за ову предметну набавку или потврда да је понуђач произвођач решења,

4. Потврда/рефренца образац број 8.

2.7. Кадровски капацитет:

Потребно је да понуђач достави листу (списак) запослених/ангажованих лица која ће бити одговорна за извршење уговора.

1) Докази за услов бр. 1:

- Образложена радна биографија руководиоца пројекта из које се може недвосмислено утврдити да има минимум 8 (осам) година искуства на вођењу имплементације софтверских пројеката (радна биографија мора бити праћена Xxxxxxx понуђача да је истинита и тачна),

- доказ о ангажовању на конкретном пословима (копија обрасца пријаве на обавезно социјално осигурање ако је запослен код понуђача, односно копија уговора о делу, уговора о обављању привремених и повремених послова, уговора о допунском раду или другог уговора који је правни основ њиховог ангажовања од стране понуђача (уговор мора бити важећи у тренутку подношења понуде)),

- копије важећих сертификата.

2) Докази за услов бр. 2:

- Образложена радна биографија из које се може недвосмислено утврдити искуства у пословној анализи (радна биографија мора бити праћена Изјавом понуђача да је истинита и тачна),

- копије важећих сертификата.

3) Докази за услов бр. 3:

- Образложена радна биографија из које се може недвосмислено утврдити искуство на позицији програмера, софтверског инжењера или слично (радна биографија мора бити праћена Изјавом понуђача да је истинита и тачна),

уговора који је правни основ њиховог ангажовања од стране понуђача (уговор мора бити важећи у тренутку подношења понуде)),

4) Докази за услов бр. 4:

- доказ о ангажовању на конкретном пословима (копија обрасца пријаве на обавезно социјално осигурање ако је запослен код понуђача, односно копија уговора о делу, уговора о обављању привремених и повремених послова, уговора о допунском раду или другог уговора који је правни основ њиховог ангажовања од стране понуђача (уговор мора бити важећи у тренутку подношења понуде)),

- копије важећих сертификата.

3. Начин доказивања испуњености услова

3.1. Докази о испуњености услова могу бити достављени у неовереним копијама.

3.2. Докази под тачком 2.2 - 2.3 не могу бити старији од два месеца пре отварања понуда.

3.3. Понуђач уписан у регистар понуђача није дужан да приликом подношења понуде доставља доказе наведене у тачкама 2.1 – 2.3.

3.4. Наручилац задржава право да, пре доношења одлуке о додели уговора, тражи од понуђача чија је понуда на основу извештаја за јавну набавку оцењена као најповољнија, да достави на увид оригинал или оверену копију свих или појединих доказа.

3.5. Уколико понуђач не достави доказ наведен под тачком 2.1 и тачком 2.5, испуњеност услова из тачке 1.1 подтачке 1) и тачке 1.2. подтачке 1) утврдиће се на основу података доступних у бази података која се налази на интернет страници Агенције за привредне регистре и НБС.

3.8. Уколико понуду подноси група понуђача сваки члан групе понуђача мора да докаже да самостално испуњава услове из тачке 1.1, док услове из тачке 1.2 испуњавају заједнички.

3.9. Уколико понуђач подноси понуду са подизвођачем, понуђач је дужан да докаже за сваког подизвођача појединачно да испуњава услове из тачке 1.1. Услове из тачке 1.2. подизвођач је дужан да испуни ако се односе на део набавке који ће он извршити.

3.10. Ако се у држави у којој понуђач има седиште не издају тражени докази, понуђач може, уместо доказа, приложити своју писану изјаву, дату под кривичном и материјалном одговорношћу оверену пред судским или управним органом, јавним бележником или другим надлежним органом те државе.

VI МОДЕЛ УГОВОРА

УГОВОР БР.

О НАБАВЦИ УСЛУГЕ УСПОСТАВЉАЊА ПЛАТФОРМЕ ЗА РАЗМЕНУ ПОДАТАКА УНУТАР РФЗО, КАО И ИЗМЕЂУ РФЗО И СПОЉНИХ КОРИСНИКА ПОСРЕДСТВОМ СИСТЕМА ЗА ПОДРШКУ СИНХРОНИМ И АСИНХРОНИМ ТРАНСПОРТНИМ ПРОТОКОЛИМА ЗА ПОЗИВ

ФУНКЦИЈА ПОСЛОВНИХ АПЛИКАЦИЈА РФЗО

Закључен између:

1. Републичког фонда за здравствено осигурање, са седиштем у Београду, ул. Xxxxxx Xxxxxxxxxx 2, матични број 06042945, ПИБ 101288707, који заступа в.д. директора (у даљем тексту уговора: Xxxxxxxxx, и

2. Привредног друштва

, са седиштем у

, ул.

, матични број , ПИБ , које заступа

(у даљем тексту уговора: Извршилац). Наручилац и Извршилац у уводу констатују:

- да се уговор закључује на основу спроведеног отвореног поступка јавне набавке услуге успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО, број набавке 000-0-000/20-11, у свему у складу са Законом о јавним набавкама (’’Службени гласник РС’’, бр.124/2012,14/2015 и 68/2015);

- да је Извршилац достaвио Понуду број , од , године примљена код Наручиоца под бројем од године, у свему у складу са Конкурсном документацијом, 08/3 број , од године;

- да је Наручилац на основу Извештаја Комисије за јавну набавку, 08/3 број , од

. године, донео Одлуку о додели уговора, 08/3 број , од ,године на основу које је изабрао Извршиоца за извршење предметне јавне набавке за потребе РФЗО, у свему у складу са Законом о јавним набавкама (’’Службени гласник РС’’, бр.124/2012, 14/2015 и 68/2015).

ВАРИЈАНТА ЗАЈЕДНИЧКА ПОНУДА:

- Извршилац је носилац посла следеће групе понуђача

- Понуђачи који поднесу заједничку понуду одговарају неограничено солидарно према

Наручиоцу.

ВАРИЈАНТА ПОНУДА СА ПОДИЗВОЂАЧЕМ:

- Извршилац је понуду поднео са следећим подизвођачем

- Извршилац је следећи део набавке: поверио наведеном подизвођачу.

Члан 1.

Предмет овог уговора је услуга успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО, у свему према усвојеној Понуди Извршиоца, бр. , од , (прилог 1), заведена код Наручиоца под бр. , од , Техничкој спецификацији (прилог 2), које чине саставни део овог уговора.

Услуга из става 1. овог члана реализује се кроз следеће фазе које су детаљно дефинисане техничком спецификацијом:

- Испорука софтвера за интеграцију апликација и наменског интеграционог „security gateway appliance“ урађаја - прва фаза,

- Услуга анализе и редизајна пословних процеса - друга фаза,

- Услуга пословне анализе за потребе имплементације СОА – трећа фаза,

- Услуга модификације постојећих „web“ сервиса за потребе излагања на ЕСБ - четврта фаза,

- Услуга развоја нових „web“ сервиса за потребе излагања на ЕСБ – пета фаза,

- Услуга развоја и излагања „web“ сервиса за потребе интеграције са спољним сарадницима – шеста фаза.

Након окончања сваке фазе Xxxxxxxxx и Извршилац ће потписати записник који чини обавезну пратећу документацију уз испостављени рачун.

Потписивање Записника о извршењу услуге развоја и излагања „web“ сервиса за потребе интеграције са спољним сарадницима подразумева да је Извршилац у целости извршио услугу из члана 1. овог уговора.

Рокови за окончање сваке фазе појединачно из става 2. овог члана одређени су Техничком спецификацијом која чини прилог уговора.

Члан 2.

Укупна вредност услуге успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО износи

динара без ПДВ-а односно динара са ПДВ-ом.

У вредност из става 1. овог члана урачунати су сви трошкови Извршиоца у вези развоја, испоруке и одржавања софтверског система.

Вредност из става 1. овог члана је фиксна.

Вредност из става 1. овог члана утврђена је на основу усвојене Понуде Извршиоца бр. , од , заведена код Наручиоца под бр. , од .

Члан 3.

Наручилац се обавезују да цену увећану за износ ПДВ-а, плати Извршиоцу након окончања сваке фазе из члана 1. став 2. овог уговора, уплатом на текући рачун бр. ,

код

банке, у року од

_ дана од дана издавања рачуна, са неопходном

пратећом документацијом, који ће Извршилац доставити Xxxxxxxxx.

Наручилац ће извршити плаћање након окончања фазе и то:

- за испоруку софтвера за интеграцију апликација и наменског интеграционог „security gateway appliance“ урађаја у износу од динара без ПДВ,

- за услугу анализе и редизајна пословних процеса у износу од динара без ПДВ,

- за услугу пословне анализе за потребе имплементације СОА у износу од

динара без ПДВ,

- за услугу модификације постојећих „web“ сервиса за потребе излагања на ЕСБ у износу од динара без ПДВ,

- за услугу развоја нових „web“ сервиса за потребе излагања на ЕСБ у износу од

динара без ПДВ,

- за услугу развоја и излагања „web“ сервиса за потребе интеграције са спољним сарадницима у износу од динара без ПДВ.

Извршилац се обавезује да рачун из става 1. овог члана, достави Наручиоцу након окончања сваке фазе, а најкасније 5 дана од дана издавања.

Обавезе преузете овим уговором које доспевају у буџетским годинама (2021. и 2022.), биће реализоване највише до износа средстава која ће за ову намену бити одобрена у тим

буџетским годинама (2021. и 2022.), у супротном уговарачи су сагласни да овај уговор престаје да важи због немогућности извршења обавеза преузетих од стране Наручиоца.

Члан 4.

Наручилац и Извршилац ће након ступања на снагу уговора потписати Записник о почетку пројекта .

Наручилац се обавезује да предузме све припремне радње како би Извршиоцу омогућио да изврши услугу успостављања система у уговореном року и на уговорени начин.

Члан 5.

Извршилац се обавезује да испоручи савремену интеграциону софтверску платфому која ће задовољити дугорочне потребе у домену интеграција система.

Платформа се састоји из два дела:

- Софтвер за интеграцију апликација који мора да буде испоручен у складу са техничком спецификацијом и

- интеграциони „security gateway“ који мора бити испоручен као appliance у складу са техничком спецификацијом.

Члан 6.

Извршилац је у обавези да изрши пословну анализу за потребе дефинисања Сервисно Оријентисане Архитектуре и да основу тога адекватно имплементира решења и услуге везане за развој и модификацију постојећих система.

Захтеване услуге укључују инсталацију понуђених добара на продукционо и не- продукционо окружење и конфигурацију.

Члан 7.

Гарантни рок за испоручени софтвер и уређај је 12 (дванаест) месеци, почевши од датума потписивања записника о извршеној примопредаји софтвера и уређаја.

У гарантном року врши се исправка уочених грешака у испорученом систему у року од 4 радна дана од дана пријема захтева Наручиоца.

Понуђач се обавезује на гарантни рок од 12 (дванаест) месеци за све услуге, почевши од датума потписивања појединачних записника након окончања фаза бр. 2-6.

Члан 8.

Извршилац се обавезује да услугу која је предмет овог уговора изврши у року од 24 месеца од дана потписивања Записника о почетку пројекта између Xxxxxxxxx и Извршиоца.

Рок за извршење услуге из става 1. овог члана може се продужити Анексом овог уговора у следећим случајевима:

- околности више силе, према важећим прописима,

- наступањем околности које се у тренутку закључења уговора нису могле предвидети.

У случају наступања околности из става 2. овог члана, уговорна страна која захтева измену уговора дужна је да докаже основаност тог захтева.

Не може се захтевати измена уговора због ванредних околности које су настале после истека рока предвиђеног за реализацију уговора.

Рок за извршење услуге (и појединачних фаза) може се продужити и у случају да Извршилац није у року извршио услугу из разлога који су на страни Наручиоца и који су онемогућили да се услуга изврши у уговореном року.

Члан 9.

Извршилац се обавезује да Наручиоцу достави листу запослених/ангажованих лица која ће бити одговорна за извршење уговора Извршилац је у обавези да за извршење уговора ангажује лица са знањем српског језика (говор и писање).

Члан 10.

Извршилац се обавезује да у року од 10 дана од дана потписивања уговора Наручиоцу достави банкарску гаранцију на износ од 10% од укупно уговорене вредности, са роком важења 30 дана дуже од дана истека рока важења уговора односно извршења уговорене обавезе.

У случају да Извршилац не достави банкарску гаранцију у року из става 1. овог члана сматраће се да уговор није закључен.

Извршилац може да достави банкарску гаранцију за добро извршење посла са роком важења не краћим од 6 месеци рачунајући од дана почетка важења банкарске гаранције, с тим да је обавезан да најкасније 8 дана пре истека банкарске гаранције, без обавештења Наручиоца, продужава гаранцију банке на исти износ, односно износ који је умањен за износ евентуално активирене гаранције.

Уколико Извршилац не продужи банкарску гаранцију у наведеном року Наручилац ће у целини наплатити банкарску гаранцију за добро извршење посла, а може и раскинути уговор. Последња гаранција, односно последње продужење банкарске гаранције за добро извршење посла, мора бити са роком важења који је најмање 30 дана дужи од уговореног рока за извршење уговорне обавезе.

Наручилац има право да у целини наплати банкарску гаранцију за добро извршење посла, у случају да:

- Извршилац не извршава уговорне обавезе у уговореном року, под уговореним условима и на уговорени начин,

- Извршилац једнострано раскине уговор супротно уговору.

Члан 11.

Уговорне стране су сагласне да је Извршилац дужан да на име уговорне казне плати Наручиоцу износ у висини од 0,5% од укупно уговорене вредности за сваки дан закашњења, а највише до 5% од укупно уговорене вредности, уколико својом кривицом не изврши услугу која је

предмет овог уговора у свему према уговореним условима, у уговореном року и на уговорени начин у целости.

Делимично извршење уговорне обавезе у уговореном року не искључује обавезу плаћања уговорне казне.

Уколико је Наручилац због кашњења Извршиоца претрпео штету која је већа од уговорне казне, Наручилац има право да захтева разлику до потпуне накнаде штете.

Члан 12.

Извршилац је дужан да Наручиоцу надокнади штету коју причини на имовини Наручиоца својом кривицом или грубом непажњом.

Xxxxxxx Xxxxxxxxx у току реализације овог уговора претрпи штету која је последица неиспуњавања уговорених обавеза од стране Извршиоца, Извршилац је одговоран за штету коју је Наручилац у том случају претрпео и дужан је да је надокнади.

Уговорне стране су сагласне да у случају наступања штете из става 1. и става 2. овог члана заједничка комисија утврди евентуалну одговорност Извршиоца, обим и висину штете, о чему ће се сачинити записник.

Члан 13.

Извршилац се обавезује да поверљиве информације које је сазнао у вези са извршењем овог уговора неће користити у друге сврхе, осим за испуњење уговорних обавеза, као и да их неће открити трећем лицу, осим уколико је то неопходно за извршење предмета овог уговора, уз претходну сагласност Наручиоца.

Обавеза из става 1. овог члана не односи се на информације које је Извршилца дужан да саопшти у складу са позитивноправним прописима.

У случају да дође до откривања поверљивих информација без претходне сагласности Наручиоца, Извршилац је дужан да без одлагања о томе обавести Наручиоца, а у случају да је Xxxxxxxxx том приликом претрпео штету, Извршилац је дужан да је накнади.

Члан 14.

Извршилац је дужан да у складу са позитивноправним прописима, актима Наручиоца и нормативима и стандардима чија је употреба обавезна, примењује прописане мере у циљу осигурања безбедности и здравља на раду и обезбеђења сигурности људи и имовине, као и мере заштите од пожара.

Члан 15.

Уговарачи су сагласни да све евентуалне спорове који настану из овог уговора реше мирним путем, у супротном сагласни су да је надлежан Привредни суд у Београду.

У случају евентуалних неслагања уговорних страна у погледу примене одредби овог уговора примењиваће се одредбе Закона о облигационим односима и других позитивноправних прописа.

Члан 16.

Уговор ступа на снагу даном потписивања од стране овлашћених лица уговорних страна.

Уколико је датум потписивања уговорних страна различит, уговор ступа на снагу даном потписивања уговорне стране која га је касније потписала.

Члан 17.

Овај уговор сачињен је у 4 (четири) примерака, од којих 2 (два) примерка задржава Наручилац, а 2 (два) примерка Продавац.

Прилог 1 – Понуда Извршиоца број од

Прилог 2 – Техничка спецификација Прилог 3 – Подаци о понуђачу

ИЗВРШИЛАЦ:

НАРУЧИЛАЦ:

Републички фонд за здравствено осигурање

НАПОМЕНА:

Модел уговора понуђач мора да потпише, чиме потврђује да је сагласан са садржином уговора. Уколико понуђачи подносе заједничку понуду, група понуђача модел уговора потписује у складу са потписаним споразумом који је прилог заједничке понуде.

ОБРАЗАЦ БР. 1 - ПОДАЦИ О ПОНУЂАЧУ

Назив предмета набавке: Услугa успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО, бр. 000-0-000/20-11

Назив понуђача
Седиште понуђача (град, општина и адреса)
Особа за контакт
Име и презиме директора
Име и презиме законских заступника
Телефон/мобилни телефон
Факс
Електронска пошта
Назив банке
Текући рачун понуђача
Матични број понуђача
Порески идентификациони број

Напомена:

Образац се попуњава у случају када понуђач самостално подноси понуду или када понуђач подноси понуду са подизвођачем, у супротном исти не треба попунити и доставити.

ОБРАЗАЦ БР. 2 - ПОДАЦИ О ПОНУЂАЧУ У ЗАЈЕДНИЧКОЈ ПОНУДИ

Назив учесника у заједничкој понуди
Седиште учесника у заједничкој понуди (град, општина и адреса)
Особа за контакт
Име и презиме директора
Име и презиме законских заступника
Телефон/мобилни телефон
Факс
Електронска пошта
Назив банке
Текући рачун учесника у заједничкој понуди
Матични број учесника у заједничкој понуди
Порески идентификациони број
Назив учесника у заједничкој понуди
Седиште учесника у заједничкој понуди (град, општина и адреса)
Особа за контакт
Име и презиме директора
Име и презиме законских заступника
Телефон/мобилни телефон
Факс
Електронска пошта
Назив банке
Текући рачун учесника у заједничкој понуди
Матични број учесника у заједничкој понуди
Порески идентификациони број

Напомена:

▪ Образац се попуњава само у случају подношења заједничке понуде, у супротном исти не треба попунити и доставити.

▪ Уколико има већи број учесника у заједничкој понуди од места предвиђених у табели, потребно је наведени образац копирати у довољном броју примерака, да се попуни и достави за сваког понуђача који је учесник у заједничкој понуди.

ОБРАЗАЦ БР. 3 - ПОДАЦИ О ПОДИЗВОЂАЧУ

Назив подизвођача
Седиште подизвођача (град, општина и адреса)
Особа за контакт
Име и презиме директора
Име и презиме законских заступника
Телефон/мобилни телефон
Факс
Електронска пошта
Назив банке
Текући рачун подизвођача
Матични број подизвођача
Порески идентификациони број

Напомена:

Образац се попуњава само у случају да понуђач наступа са подизвођачем, у супротном исти не треба попунити и доставити.

Уколико има већи број подизвођача од места предвиђених у табели, потребно је наведени образац копирати у довољном броју примерака, да се попуни и достави за сваког подизвођача.

ОБРАЗАЦ БР. 4 - ПОНУДА ЗА ЈАВНУ НАБАВКУ

Као понуђач /назив понуђача или члана групе понуђача/ у јавној набавци: Услугa успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО, бр. 000-0-000/20-11, изјављујем да сам упознат са свим условима и захтевима из Позива за подношење понуде, конкурсне документације и модела уговора, објављених на Порталу јавних набавки дана 12.05.2020. године, укључујући и све евентуалне измене наведених докумената и подносим ову понуду у складу са тим условима и захтевима.

I Понуда се подноси: (заокружити)

А. Самостално

Б. Као заједничка понуда

3. (навести назив и седиште свих учесника у заједничкој понуди) X. Са подизвођечем:

1. Назив подизвођача

(навести назив и седиште подизвођача)

2. Проценат укупне вредности набавке поверен подизвођачу

3. Део предметне набавке који ће извршити подизвођач

У	Овлашћено лице понуђача:
м.п.
дана

Напомена: Образац понуде понуђач мора да попуни и потпише, чиме потврђује да су тачни подаци који су у обрасцу понуде наведени.

Уколико понуђачи подносе заједничку понуду, група понуђача потписује образац, у складу са потписаним споразумом који је прилог заједничке понуде.

ОБРАЗАЦ БР. 4.1 – ПОНУДA СА СТРУКТУРОМ ЦЕНЕ – Услугa успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО, бр. 000-0-000/20-11

Назив и седиште понуђача:

Број и датум понуде:

Матични број понуђача:

ПИБ понуђача:

I

Ред. бр.	Назив услуге	Цена у динарима без ПДВ-а	Цена у динарима са ПДВ-ом
1	Услуге анализе и редизајна пословних процеса
2	Услуге пословне анализе за потребе имплементације СОА
3	Услугу модификације постојећих „web“ сервиса за потребе излагања на ЕСБ
4	Услугу развоја нових „web” сервиса за потребе излагања на ЕСБ
5	Услугу развоја и излагања „web“ сервиса за потребе интеграције са спољним сарадницима
УКУПНО:

II

Ред.бр	Назив	Јединица мере	Количина	Јединична цена у динарима без ПДВ-а	Јединична цена у динарима са ПДВ-ом	Укупна цена у динарима без ПДВ-а	Укупна цена у динарима са ПДВ-ом
1	2	3	4	5	6	7 (4*5)	8 (4*6)
1	Софтвер за интеграцију апликација	ком.	1
2	Наменски интеграциони „security gateway appliance“ урађај	ком.	2
УКУПНО:

УКУПНО без ПДВ-а (I + II ) динара. УКУПНО са ПДВ-ом (I + II ) динара.

Стопа ПДВ-а: (изражена у процентима).

Рок важења понуде је дана од дана отварања понуда. (минимум 90 дана).

Рок плаћања рачуна за сваку фазу појединачно је дана од дана издавања рачуна. (најмање 30 а најдуже 45 дана).

Овлашћено лице

понуђача:

м.п.

дана

Напомена: Образац понуде понуђач мора да попуни и потпише, чиме потврђује да су тачни подаци који су у обрасцу понуде наведени.

ОБРАЗАЦ БР. 5 - ИЗЈАВA ПОНУЂАЧА О НЕЗАВИСНОЈ ПОНУДИ

У складу са чланом 26. Закона

(Назив понуђача или члана групе понуђача)

даје:

ИЗЈАВУ

О НЕЗАВИСНОЈ ПОНУДИ

Под пуном материјалном и кривичном одговорношћу потврђујем да сам понуду у поступку јавне набавке: Услугa успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО, бр. 000-0-000/20-11, поднео независно, без договора са другим понуђачима или заинтересованим лицима.

У	Овлашћено лице понуђача:
	м.п.
дана

Напомена: У случају постојања основане сумње у истинитост изјаве о независној понуди, наручилац ће одмах обавестити организацију надлежну за заштиту конкуренције. Организација надлежна за заштиту конкуренције, може понуђачу, односно заинтересованом лицу изрећи меру забране учешћа у поступку јавне набавке ако утврди да је понуђач, односно заинтересовано лице повредило конкуренцију у поступку јавне набавке у смислу закона којим се уређује заштита конкуренције. Мера забране учешћа у поступку јавне набавке може трајати до две године. Повреда конкуренције представља негативну референцу, у смислу члана 82. став 1. тачка 2. Закона.

Уколико понуду подноси група понуђача, сваки члан групе понуђача мора доставити Изјаву, која мора бити потписана од стране овлашћеног лица тог понуђача.

ОБРАЗАЦ БР. 6 - ИЗЈАВA ПОНУЂАЧА У СКЛАДУ СА ЧЛАНОМ 75. СТАВ 2. ЗАКОНА О ЈАВНИМ НАБАВКАМА

У складу са чланом 75. став 2. Закона о јавним набавкама,

/назив понуђача или члана групе понуђача/ даје:

ИЗЈАВУ

да је приликом састављања понуде у поступку јавне набавке: Услугa успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО, бр. 000-0-000/20-11, поштовао обавезе које произлазе из важећих прописа о заштити на раду, запошљавању и условима рада, заштити животне средине као и да нема забрану обављања делатности која је на снази у време подношења понуде.

У	Овлашћено лице понуђача:
	м.п.
дана

Напомена:

ОБРАЗАЦ БР. 7 - ТРОШКОВИ ПРИПРЕМЕ ПОНУДЕ

На основу члана 88. став 1. Закона о јавним набавкама („Службени гласник РС“, бр.124/12, 14/15 и 68/15), а сходно члану 15. Правилника о обавезним елементима конкурсне документације у поступцима јавних набавки и начину доказивања испуњености услова (”Службени гласник РС” бр. 86/15), као понуђач уз понуду прилажем

СТРУКТУРУ ТРОШКОВА ПРИПРЕМАЊА ПОНУДЕ

За јавну набавку: Услугa успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО, бр. 000-0-000/20-11

Трошкови прибављања средстава обезбеђења

динара без ПДВ-а

Укупни трошкови без ПДВ

динара

ПДВ

динара

Укупни трошкови са ПДВ

динара

Структуру трошкова припреме понуде прилажем и тражим накнаду наведених трошкова уколико наручилац предметни поступак јавне набавке обустави из разлога који су на страни наручиоца, сходно члану 88. став 3. Закона о јавним набавкама („Службени гласник РС“, бр.124/12, 14/15 и 68/15)

У	Овлашћено лице понуђача:
м.п.
дана

Напомена:

- Образац трошкова припреме понуде попуњавају понуђачи који су имали наведене трошкове и који тражи да му их наручилац надокнади.

- Остале трошкове припреме и подношења понуде сноси искључиво понуђач и не може тражити од наручиоца xxxxxxx xxxxxxxx (члан 88. став 2. Закона о јавним набавкама („Службени гласник РС“, бр.124/12,14/15 и 68/15).

- Уколико понуђач не попуни образац xxxxxxxx припреме понуде, наручилац није дужан да му надокнади трошкове.

- Уколико понуђачи подносе заједничку понуду, група понуђача може у споразуму о заједничкој понуди да се определи да образац потписују сви понуђачи из групе понуђача или група понуђача може да одреди једног понуђача из групе који ће исти попунити и потписати.

ОБРАЗАЦ БР. 8 - ПОТВРДЕ/РЕФЕРЕНЦЕ

НАЗИВ НАРУЧИОЦА:
СЕДИШТЕ:
УЛИЦА И БРОЈ:
ТЕЛЕФОН:
МАТИЧНИ БРОЈ:
ПИБ:
ОСОБА ЗА КОНТАКТ:

У складу са чланом 77. став 2. тачка 2) Закона о јавним набавкама, издаје се

ПОТВРДА

којом се потврђује да је

(уписати назив Понуђача)

кориснику/наручиоцу реализовао најмање један WEB базирани софтверски пројекат:

o реализован у складу са сервисно оријентисаном архитектуром (СОА),

o све WEB странице корисничког интерфејса су у кладу са Web Content Accessibility Guidelines 2.0

o са подршком за следеће претраживаче Microsoft Edge, Mozilla Firefox 5+, Google Chrome 12+,

o који укључује испоруку или интеграцију са софтверским системом за двофакторску аутентикацију

и то:

- по уговору/рачуну бр. _од . . године, у вредности од

динара без ПДВ-а.

- по уговору/рачуну бр. _од . . године, у вредности од

динара без ПДВ-а.

- по уговору/рачуну бр. _од . . године, у вредности од

динара без ПДВ-а.

Потврда се издаје на захтев привредног друштва ради учешћа у поступку јавне набавке: Услугa успостављања платформе за размену података унутар РФЗО, као и између РФЗО и спољних корисника посредством система за подршку синхроним и асинхроним транспортним протоколима за позив функција пословних апликација РФЗО, бр. 404- 1-208/20-11 и у другу сврху се не може употребити.

МЕСТО И ДАТУМ:

ПОТПИС РЕФЕРЕНТНОГ НАРУЧИОЦА:

X.X.

Document Metadata

Table of Contents

Document Metadata