Інформаційна система InsCom

Короткий опис функціональності InsCom

Єдина база даних

Всі види страхування

Розрахунки і контроль даних

Зручне користування

Захист даних

Для кожного користувача визначаються права доступу:

Internet

Багатомовна реалізація

Страхові продукти

Страховий продукт є основою обліку InsCom. Всі характеристики кожного страхового продукту визначаються при налаштуванні. InsCom дозволяє оперативно створювати різноманітні продукти і пропонувати страхові поліси з багатьма ризиками і об'єктами страхування.

Клієнти

У InsCom реалізований єдиний реєстр клієнтів. Він містить фізичні та юридичні особи, які є реальними або потенційними клієнтами страхової компанії, а також будь-яких інших учасників страхового процесу.

Персональні дані фізичної або юридичної особи зберігаються в одному місці. InsCom забезпечує можливість звіту про зв'язок між будь-яким застрахованою особою і його договорами, платежами, виплатами, застрахованими об'єктами. Це дає можливість здійснити ефективний контроль взаємодій з клієнтом, знизити ймовірність помилок або фальсифікацій. Таким чином в системі зберігається повна інформація про кожного клієнта.

Об'єкти

У InsCom реалізований єдиний реєстр об'єктів. Об'єкти мають широкий спектр атрибутів, необхідних для подальшого аналізу. Наявність інформації про застрахованих об'єктах і їх власників, фіксація зв'язків між ними і можливість оперативного пошуку є ефективними засобами контролю і боротьби з шахрайством.

Модулі

Конфігуратор 

Документи

Основний модуль InsCom, здійснює облік полісів і збитків. InsCom здійснює контроль над введеними даними: відповідність їх правилам страхування і умов конкретного продукту. InsCom може автоматично обчислювати страхову премію та інші складові за полісом.

Поліси прямого страхування

У InsCom реалізований облік полісів прямого страхування з будь-яким правилам страхування. Інформація про планові платежі за полісом передається в бухгалтерію. Поліс можна друкувати на принтері.

Перестрахування

Врегулювання збитків

InsCom підтримує повний цикл врегулювання збитків:

InsCom забезпечує ефективний облік врегулювання, відповідно до виду врегулювання і умов договору. Система також веде облік компенсацій при наявності перестрахувальника.

Облік процесу врегулювання за всіма видами страхування, в т.ч. по добровільному медичному страхуванню, здійснюється в єдиній базі даних.

Автоматичне відновлення договорів

Система автоматично відстежує договору, термін дії яких проходить через певну кількість днів. Система готує листи для клієнтів з пропозиціями для його відновлення.

Комісійна винагорода агентів

InsCom визначає комісійну винагороду. Комісійні можуть розподілятися між кількома посередниками - співробітниками або філіями компанії.

Офіс

Модуль здійснює зв'язок страхового та бухгалтерського блоку, облік бланків полісів, а також автоматизацію документообігу компанії.

Зв'язок з бухгалтерським блоком і залік платежів

InsCom відстежує всі дати, коли має надійти платіж. Генерується звіт про заборгованість і планових платежах за певний період.

InsCom дозволяє здійснювати залік:

Облік бланків полісів

Звіти

InsCom має велику кількість звітів для аналізу інформації. Завдяки їм страхова компанія завжди володіє актуальною інформацією.

У систему можуть бути добавленни нові звіти. Для обробки даних використовуються сучасні технології:

Монітор керівника

Модуль призначений для відображення показників діяльності компанії в цілому:

Переваги InsCom

Додаткові Особливості InsCom

InsCom-life InsCom (life)

Інформаційна система для компаній зі страхування життя InsCom (life)

InsCom (life) реалізована на платформі InsCom і успадковує всі її функції.

У той же час в ній реалізовані особливості страхування життя, враховані вимоги, що пред'являються до страхових компаній зі страхування життя:

InsCom-Integration - модуль інтеграції InsCom з зовнішніми веб сервісами 

InsCom-Integration реалізує отримання та передача інформації по полісам та страховим випадкам за допомогою веб сервісів.

1. Отримання даних з зовнішніх веб сервісів та занесення в базу даних InsCom.

Отримання даних відбувається шляхом запиту з боку страхової компанії до інформаційної системи банка.

Модуль реалізований як консольний додаток на С #, запускається з командного рядка, з конфігураційним файлом.

Розклад запуску програми налаштовується в schtasks.

Даний підхід значно спрощує укладання угоди про співпрацю з банком та мінімізує витрати на ведення справи з на боці банку. 

З боку страхової компанії за розкладом запускається консольна утиліта, яка через веб сервіс системи банку самостійно в пакетному режимі забирає дані та завантажує в базу даних InsCom.

2. Передача даних з InsCom у зовнішні веб сервіси.

Звернення InsCom до зовнішніх веб сервісів для передачі даних по полісах та страхових справах.

Запуск веб сервісів InsCom відбувається за розкладом.

Cтраховий агрегатор електронних полісів на платформі InsCom

InsCom-Agr зручно та швидко працює на комп'ютерах, планшетах та смартфонах.

Сфера використання. 

АРХІТЕКТУРА


Додаткові компоненти


Також реалізований функціонал, закритий в коментарях:


Реалізований продукт - ОСЦПВ

В рішенні закладена можливість додавання інших страхових продуктів (КАСКО, ДГО, тревел, НС)

Медичний асистанс у структурі страхової компанії

Компонент призначений для організації роботи асистанського відділу страхової компанії з обслуговування полісів медичного страхування та обліку витрат на врегулювання збитків за цими полісами.

Код продукта 024 

Функції:

Компонент складається з модулів:

Побудова обліку

Облік інформації з полісів:

Облік збитків:

============= Додаткові відомості ===================

Реєстрація полісів.

Для реєстрації полісів налаштований продукт 24 - Добровільне медичне страхування.

Під час реєстрації поліса система дозволяє вказати такі параметри:


Імпорт полісів за договором

Імпорт полісів за договором здійснюється за формою реєстрації договорів за продуктом 242 – «Договори ДМС». Опис імпорту у розділі Допомога, код розділу imp_M.

Медичний асистанс

Картки (справи з врегулювання) реєструються у розділі «Медичний асистанс»..

Довідник значень резервів

Довідник значень резервів заповнюється в «Медичний асистанс» -> «Розрахунки та тарифи» -> «Довідник резервів». Значення довідника автоматично обробляються під час реєстрації медичних карток.

************ Додаткові описи ***********************

Продукт призначений для роботи асистанського відділу страхової компанії з обслуговування полісів медичного страхування та обліку витрат на врегулювання збитків за цими полісами.

Для роботи потребує встановленої інформаційної системи InsCom.

Функції:

Продукт складається з модулів:

***ФУНКЦІОНАЛЬНІСТЬ***

Модуль страхової компанії

***Облікова інформація***

*** ДЕТАЛЬНА ФУНКЦІОНАЛЬНІСТЬ***

КЛІЄНТИ

Основний принцип - централізований облік клієнтів.

Кожен клієнт у системі має персональний страховий код, який надається системою автоматично при введенні.

Дані щодо нового клієнта реєструються лише у випадку, якщо він відсутній у системі.

Персональний страховий код клієнта є унікальним у рамках Компанії. З метою уникнення дублів, персональний страховий код складається з двох частин: префікс (код філії) + код унікальний у рамках філії. У такій формі код надається автоматично.

Типи клієнтів: юридичні особи, фізичні особи, групи фізичних осіб.

Заходи щодо уникнення дублів у реєстрі клієнтів: реєструвати табельний номер + місце роботи – для фізичних осіб; код ОКПО – для юридичних осіб. Додатково зареєструвати: серію, номер паспорта, ідентифікаційний код.

Введення/редагування інформації щодо клієнтів – лише в офісі Компанії.

Способи введення: ручний оператор, імпорт із зовнішнього файла встановленого формату.

РЕЄСТРАЦІЯ БЛАНКІВ

Номер бланка унікальний у межах типу (серії) бланка.

Тип бланка – символьний (до 5 символів), номер – ціле число.

Рекомендується унікальність типів і номерів бланків визначити в рамках Компанії. Альтернативний варіант – унікальний тип бланка для кожної філії.

Видані бланки реєструються у системі перед введенням полісів.

Контроль типів бланків активується автоматично, якщо занесено хоча б один діапазон даного типу. Після активізації контролю бланків система не дозволяє видати поліс, якщо його номер відсутній у зареєстрованому діапазоні (діапазонах).

АГЕНТИ

Агенти реєструються у системі, заповнюється довідник «Комісія агентів». Код агента вказується у полісі. Розрахунок комісійної винагороди проводиться автоматично.

ПОЛІСИ

Унікальний ідентифікатор поліса визначається типом (серією) бланка та номером бланка. Тип та номер бланка – унікальні у рамках Компанії.

Поліси можуть бути індивідуального та колективного страхування.

По полісу враховується така інформація:

Зарахування платежів здійснюється двома способами: автоматично – шляхом імпорту банківських виписок із зовнішнього джерела, шляхом ручного введення даних оператором.

Додаткова інформація щодо полісу: особливі умови, примітки, ліміти відповідальності, франшизи, знижки/надбавки, адендуми, звітний період.

Введення/редагування інформації щодо полісів (в т.ч. реєстрація банківських виписок та зв'язування платежів) – лише в офісі Компанії.

Способи введення: ручний оператор, автоматична генерація полісів, на підставі даних із зовнішнього файлу, встановленого формату.

АДЕНДУМИ (ПРОДОВЖЕННЯ ТЕРМІНУ ДІЇ ПОЛІСІВ)

Опис моделі та посібник користувача – в «Інструкції з виконання адендуму – продовження терміну дії договорів» (інструкція наведена нижче).

БАНКІВСЬКА ВИПИСКА, ЗВ'ЯЗОК ПЛАТЕЖІВ

Введення банківських виписок та зв'язок платежів здійснюються лише в офісі Компанії.

Способи введення банківських виписок та зв'язку платежів: ручний оператором, автоматичний імпорт та зв'язування на підставі даних із зовнішнього файлу встановленого формату.

Формати файлів та алгоритм імпорту банківських виписок можуть мати особливості залежно від філії. Подробиці – в індивідуальних для філій інструкціях.

МОДЕЛЬ ПЛАНУ ПЛАТЕЖІВ (ОДИН З МОЖЛИВИХ ВАРІАНТІВ ОБЛІКУ, ПРИ УМОВІ ПРОПОРЦІОНАЛЬНОЇ ВІДПОВІДАЛЬНОСТІ)

Виняткові ситуації (інструкція оператора)

Винятковими є ситуації, у яких необхідно зарахувати платіж більше чи менше планового у поточному місяці (звітному періоді). У таки х ситуаціях оператор самостійно приймає рішення про необхідні зміни у плані платежів, керуючись положеннями цієї інструкції.

1. Необхідно зарахувати платіж більше за плановий у поточному місяці.

приклад

Плановий платіж складає 15 грн. Сума платежу, що надійшов - 20 грн. Платіж надійшов у січні місяці, звітний період – січень.

План платежів до зарахування - План платежів після зарахування

01.01.03-Січень-15-План-01.01.03-Січень-15-Факт

01.02.03-Лютий-15-План-01.02.03-Січень-5-Факт

01.03.03-Березень-15-План-01.03.03-Березень-15-План

01.04.03-Квітень-15-План-01.04.03-Квітень-15-План

Доданий запис->-01.02.03-Лютий-10-План

2. Необхідно зарахувати платіж менше планового у поточному місяці.

приклад

Плановий платіж складає 15 грн. Сума платежу, що надійшов - 10 грн. Платіж надійшов у січні місяці, звітний період – січень.

План платежів до зарахування - План платежів після зарахування

01.01.03-Січень-15-План-01.01.03-Січень-10-Факт.

01.02.03-Лютий-15-План-01.02.03-Лютий-15-Факт.

01.03.03-Березень-15-План-01.03.03-Березень-15-План.

01.04.03-Квітень-15-План-01.04.03-Квітень-15-План.

Доданий запис->-01.01.03-Січень-5-План.

Після надходження очікуваної суми боргу 5 грн. (наприклад у лютому), необхідно зарахувати її на відповідний запис, змінивши значення поля “Звітний період”. Значення поля “Дата” залишити без змін.

ОСОБЛИВОСТІ АЛГОРИТМУ ІМПОРТУ БАНКІВСЬКИХ ВИПИСОК

Зарахування платежу на поліс відбувається за дотримання наступного набору умов:

Платіж не зараховується за недотримання хоча б однієї з перелічених умов.

На поліс платежі зараховуються за схемою:

Усі виявлені під час імпорту відхилення виводяться в протокол імпорту платежів.

Аналіз протоколу імпорту платежів повинен проводитись безпосередньо після операції імпорту, до внесення будь-яких змін до даних. Необхідно встановити точну причину, через яку запис потрапив до протоколу, за необхідності вручну внести зміни до даних. Усі зміни, що вносяться, підлягають обов'язковому протоколюванню.

ВРЕГУЛЮВАННЯ ЗБИТКІВ

За фактом звернення застрахованого реєструється справа щодо врегулювання збитків (медична карта/ карта).

Справа врегулювання має номер, унікальний у межах Компанії. Номер справи – символьне поле (20 символів).

Номер справи формується системою автоматично під час реєстрації.

Номер справи складається з: коду філії + коду робочого майданчика + № справи (лічильник у рамках робочого майданчика). Робочий майданчик – окрема група робочих місць, підключених до віддаленого сервера (наприклад, медустанови).

Необхідна умова реєстрації справи – наявність у системі чинного поліса, яким реєструється справа.

Під час реєстрації нової справи враховується залишок страхової суми за рівнем об'єкт – ризик (застрахований – програма) у межах поліса.

У випадку, якщо по застрахованому існують незакриті справи (картки), оператор самостійно визначає як реєструвати чергову оцінку – у новій справі, чи існуючій.

У межах справи враховуються: постраждалий об'єкт (застрахований) – фізична особа; ризик (програма страхування); склад оцінки.

Атрибути справи щодо врегулювання: № справи; дата реєстрації справи; період лікування; дата закриття справи; тип справи (лікарняний, поліклініка, діагностика, відмова); звітний період; місце роботи застрахованого; застрахований; № полісу; бланк; профіль; категорія складності; програма (ризик); діагноз (за довідником МКБ – один основний діагноз та три додаткові) + діагноз у довільній формі; медична установа; лікар; відділення.

В рамках справи можлива реєстрація оцінок за такими типами: послуги, процедури, рецепти.

Атрибути оцінок: найменування (з довідника для послуг та процедур, довільно для рецептів); складність; сума; відділення; кабінет; лікар; додатково для рецептів – дата введення та звітний період.

Кількість оцінок у рамках справи – необмежена.

Заповнення суми за процедурами та послугами можливе як вручну оператором, так шляхом автоматичного розрахунку на підставі даних довідника тарифів.

Розрахунок послуг із закритих карт (справ), а так само розрахунок використаних сум повинен виконуватися:

Первинне введення карток (справ) здійснюється лише у місцях видачі карток (мед. установах).

Уся інформація про карти розбита на 3 групи: «Послуги», «Процедури», «Рецепти». Додавання інформації з кожної групи може виконуватися лише у одному з підрозділів. Наприклад, введення нових рецептів здійснюється лише в офісі, послуги лише в медустанові.

Редагування інформації в існуючих картах (Закриття картки, зміна застрахованого, номера поліса, ризику, зміна існуючих рецептів, послуг тощо) – лише в місцях видачі карток.

Після додавання даних до карт (справи) в офісі – обов'язково виконати експорт даних по картах до місць видачі (на додавання даних).

Після додавання даних до карток у медустанові – виконати експорт даних до офісу (на додавання нових та зміна існуючих даних).

ТАРИФИ

Тарифи зазначаються у довіднику тарифів. Окремо реєструються тарифи за послугами та процедурами. Параметри довідника тарифів: медична установа, категорія складності, період дії, сума.

ОБМІН ДАНИМИ (ЕКСПОРТ/ІМПОРТ)

Послідовність обміну даними: експорт даних за період з точки «А» за вказаним сценарієм експорту, імпорт даних у точці «Б».

Експорт даних завжди провадиться за певний період. Експорту піддаються дані, дата введення (зміни) яких знаходиться в діапазоні дат, зазначених на формі параметрів експорту (Дата закінчення періоду має бути на день більшою за передбачувану дату закінчення періоду для імпорту). Необхідно стежити за перетином діапазонів дат між окремими сеансами експорту.

Обмін даними проводитися за такими схемами:

Філія Компанії - медичний заклад - дані щодо полісів, клієнтів. Періодичність – довільна, після додавання/зміни даних або після розрахунку залишку сум для закритих карток у філії. У медичному закладі - імпорт на додавання, зміну, видалення даних uid.

  Філія Компанії – медичний заклад – дані щодо медичних карт. Періодичність – довільна після додавання даних у карти у філії. У медичній установі – імпорт лише додавання даних по uid.

Медична установа – філія Компанії – дані щодо медичних карт. Періодичність – довільна. У філії Компанії імпорт додавання, зміна, видалення даних по uid.

За результатами імпорту даних формується протокол імпорту. Обов'язковим є аналіз протоколу імпорту та подальше коригування даних оператором, у разі потреби.

ЗВІТНІСТЬ

Перелік спеціалізованих звітів

e_002 Баланс за договорами страхування

e_1 ВІДОМІСТЬ ПО СТРАХУВАЛЬНИКУ (РЕЦЕПТІ)

e_14 ВІДОМІСТЬ ПО ЛІКАРЯХ

e_15 ВІДОМІСТЬ ПО ЛІКАРЯХ (ПО ВІДДІЛЕННЯМ)

e_2 ВІДОМІСТЬ ПО ЛІКАРЮ (РЕЦЕПТІ)

e_21 ВІДОМОСТІ ПРО ОБСТЕЖЕННЯ. ЗАСТРАХУВАННЯ

e_24 Реєстр діючих договорів щодо страхувальника

e_27 Реєстр діючих договорів за програмою

e_3 ВІДОМІСТЬ З МЕД. ЗАКЛАДУ ( РЕЦЕПТІ)

e_4 ВІДОМІСТЬ З ВІДДІЛЕННЯ (РЕЦЕПТИ)

e_5 Відомість за програмами

e_6_u ВІДОМІСТЬ ПО СТРАХУВАЛЬНИКУ (ПОСЛУГИ)

e_7 ВІДОМІСТЬ З МЕД. ЗАКЛАДУ (ПОСЛУГИ)

e_agreem Звіт про укладені договори страхування

e_cl_k Відомості для лікарів експертів

e_ford Фінансовий звіт за розірваними договорами

e_ks Корегування суми страхового внеску

e_ks2 Корегування суми страхового внеску2

e_open_k ВІДОМІСТЬ ДЛЯ ЕКСПЕРТІВ (НЗК)

e_pr Рахунок за процедури

e_stat1 Таблиця витрат

e_stat2 Таблиця страхових випадків

er_1 Невідповідність об'єкту - страхувальник

er_2 Платежі за межами дії поліса

er_3 Нульові платежі

er_4 Розбіжність між премією та платежами (факт+план)

er_5 Дублі полісів

e_agen_p Страхові платежі за агентами

ІНСТРУКЦІЯ З ВИКОНАННЯ АДДЕНДУМУ - ПРОДОВЖЕННЯ ТЕРМІНИ ДІЇ ДОГОВОРІВ

Перед виконанням операції автоматичного продовження терміну дії договорів обов'язково створити резервну копію (back-up) бази даних!

загальні положення

Продовження терміну дії договорів (аддендум) виконується лише автоматичному режимі, за умов, визначеним алгоритмом (схемою) продовження терміну дії договорів (опис схеми нижче).

З метою спрощення обліку, а також уникнення помилок рекомендується відмовитися від операції продовження терміну дії договору на умовах, що суперечать алгоритму автоматичного продовження на користь переоформлення договору.

У системі кожний поліс містить свою останню редакцію. Інформація про старі умови поліса зберігається в спеціальних таблицях, де враховуються: дата, з якої зміни набирають чинності, період дії змін, а також опис змін. Інформацію про всі зміни умов (аддендумів) можна отримати із форми «Зміна умов полісу». Ця форма викликається за кнопкою «Зміна умів», що знаходиться на четвертій вкладці («Додатково») форми поліса.

Продовження строку дії договору на новий період виконується після закінчення поточного періоду дії. Розмірність періоду дії – рік.

Існує особливості в обліку інформації щодо об'єктів та ризиків, в рамках окремих періодів дії договору.

Опис алгоритму (схеми) автоматичного продовження терміну дії договорів

Автоматичне продовження договорів виконується у два етапи:

1.Формування списку договорів, для яких можливе продовження терміну дії, згідно із заздалегідь заданими умовами відбору.

2.Виконання операції продовження терміну дії договорів.

Формування списку договорів виконується автоматично, згідно із заздалегідь заданими умовами відбору:

страховий продукт;

належність страхувальника (поле «належність» у картці клієнта);

період закінчення дії договору (с.- по..).

Додатково перевіряються такі умови:

статус поліса = 0 («зареєстрований»);

премія відповідає фактичним страховим платежам за умови відсутності планових платежів;

відсутність планових страхових платежів;

страхувальник = об'єкту страхування; об'єкт страхування один у рамках полісу;

період дії об'єктів, у межах поліса, не перевищує період дії самого поліса (для виправлення цієї помилки необхідно відкрити форму поліса, перейти в режим перегляду, після чого закрити форму поліса);

Дата закінчення періоду дії активного об'єкта дорівнює даті закінчення періоду дії поліса (для виправлення цієї помилки необхідно відкрити форму поліса, перейти в режим перегляду, після чого закрити форму поліса).

За результатами формування списку договорів формуються протоколи: список договорів, за якими можливе продовження (з можливістю видалення договору зі списку), список договорів за якими продовження неможливе, через невідповідність додаткових параметрів (із зазначенням якого з параметрів не дозволяє виконати продовження терміну дії договору) .

Операція продовження терміну дії виконується всім договорів зі сформованого списку. Для всіх договорів виконуються такі операції:

продовження терміну дії на один рік (збільшення періоду страхування на одиницю, збільшення дати закінчення дії договору на один рік, збільшення дати покриття за полісом на один рік);

переведення в стан «неактивних» всіх об'єктів за полісом та ризиків по об'єктах;

формування «активних» записів щодо об'єктів та ризиків (ті ж об'єкти та ризики за ними, страхові суми та тарифи, тільки з датою дії об'єкта – на новий період);

формування плану платежів на новий період дії договору (12 платежів із розстрочкою на місяць).

План платежів формується виходячи з даних за поточний період дії договору (тобто підсумкова премія за новий період дії = підсумкової премії за поточний період). Дані по об'єкту страхування, програмі в рамках договору (страхова сума, премія, тариф), прийняті на новий період дії, залишаються рівними даними за поточний період.

За результатами операції продовження терміну дії договорів формуються протоколи: список договорів, котрим операція продовження завершилася успішно; список договорів, котрим були помилки у процесі продовження, із зазначенням помилки.

Інструкція оператора (Опис інтерфейсу)

Операція продовження термінів дії договорів здійснюється на робочому місці, встановленому в офісі філії. Передача інформації про продовжені договори на робочі місця, встановлені в медичних установах, здійснюється шляхом імпорту даних. Рекомендується виконувати операцію з періодичністю раз на місяць. Усі дії повинні протоколюватись (див. інструкцію).

1. Обов'язково створити резервну копію (back-up) бази даних!

2. Запустити модуль al_main, у модулі: «Страхові поліси» -> «Адендум (продовження терміну дії)». Буде відкрито форму «Продовження терміну дії договорів».

3.Вказати параметри "Страховий продукт", "Належність страхувальника", "Закінчення дії в період з".

4.Натиснути кнопку «Визначити договори, що відповідають зазначеним умовам».

Після виконання операції виводиться повідомлення:

«Результат формування списку договорів:

договорів, що відповідають зазначеним умовам:

договорів, за якими можливе продовження:

договорів, за якими продовження неможливе:»

«договорів, що відповідають зазначеним умовам:» – кількість договорів, для яких виконуються умови щодо параметрів «Страховий продукт», «Належність страхувальника», «Закінчення дії в період з».

«договорів, за якими можливе продовження:» – кількість договорів, для яких виконуються умови додаткових параметрів (див. пункт Опис схеми автоматичного продовження договорів). Про аналіз вмісту списку договорів див. нижче пункт 5.

«договорів, за якими продовження не можливе:» – кількість договорів, для яких не виконуються умови додаткових параметрів (див. пункт Опис схеми автоматичного продовження договорів). Щодо аналізу вмісту списку договорів - див. нижче пункт 7.

5.Виконати аналіз сформованого списку договорів (кнопка «Перегляд/редагування визначеного списку договорів»). Увага: у формі «Перегляд/редагування визначеного списку договорів» одночасно на екран виводиться не більше 30 записів. Видалити зі списку договору, для яких не потрібно виконувати операцію продовження терміну дії.

6.Зберегти весь перелік договорів у файл (кнопка «Експорт даних у файл»). Якщо не задано додаткових умов відбору на формі «Перегляд/редагування визначеного списку договорів», у файл буде збережено весь список, інакше у файл буде збережено лише договори зі списку, для яких виконуються задані умови.

7.Проаналізувати та зберегти у файл протокол відхилень – список договорів, для яких продовження неможливе (кнопка «Протокол відхилень»).

8. Виконати операцію продовження терміну дії договорів для сформованого списку. Кнопка «Виконати продовження терміну дії обраних договорів»

Увага: перед виконанням операції перевіряється умова відповідності поточних параметрів, зазначених на формі «Продовження терміну дії договорів», значення, зазначені на момент формування списку. За умови невідповідності цих параметрів буде видано повідомлення:

«Список порожній. Операція неможлива.

Також це повідомлення видається за умови відсутності записів у списку.

Необхідно враховувати: у системі постійно зберігається останній із сформованих списків договорів, для яких не було виконано операцію продовження терміну дії. Якщо з моменту формування списку було внесено зміни до договорів, обов'язково сформувати новий список.

У процесі виконання операції продовження термінів дії договорів на формі «Продовження терміну дії договорів» виводиться повідомлення:

Опрацьовано ... записів з ...

Після завершення операції продовження виводиться повідомлення:

«Віконано:

опрацьовано договорів:

опрацьовано без помилок:

опрацьовано з помилками:»

9.Проаналізувати протоколи виконання операції продовження строків дії договорів: кнопка «Протокол виконання» – список договорів оброблених без помилок, «Протокол відхилень» – список договорів, внаслідок обробки яких були помилки. Зберегти протоколи у файлі. Переконається, що кількість оброблених договорів дорівнює кількості договорів у списку.

Дії у разі помилок: зафіксувати код помилки (вміст повідомлення про помилку), зібрати всі протоколи, список договорів, за яким виконувалося продовження, і передати цю інформацію в UIIS. До надходження відповіді від UIIS припинити виконання операції продовження договорів, не здійснювати імпорт даних до медичних установ.

Примітка: до помилок не належить інформація, отримана в протоколі відхилень, - пункт 7. Інструкції оператора.

Результати на формі полісу

1.Збільшення значення поля "Термін страхування" на одиницю.

2.Збільшення значення поля "Дата закінчення" на один рік.

3. Наявність активних та неактивних об'єктів/ ризиків.

4. Додавання 12 нових планових платежів до плану платежів.

5.На вкладці «Додатково», по кнопці «Зміна умів» - інформація про всі адендуми.

* Активні - прийняті новий період, неактивні – прийняті у старому періоді. На вкладці «Об'єкти», натиснути кнопку «Керування об'єктами», на формі «Керування об'єктами» вибрати «всі», натиснути кнопку «Відібрати об'єкти за вказаними умовами та». В результаті буде відображена інформація щодо неактивних об'єктів/ризиків, а також по активних. Для кожного об'єкта в рамках поліса не може бути перетинів у період його дії за активними та неактивними записами про об'єкт.

Для договорів, за якими було виконано операцію продовження терміну дії, при видачі картки виконується додаткова перевірка: наявність фактичних страхових платежів за новий період (період дії договору, встановленого після останньої операції продовження терміну дії), якщо таких платежів немає – виводиться повідомлення:

«Термін дії полісу продовжено з ..., надходження за новий термін відсутні.»

Повідомлення виводиться лише у випадку, якщо картка видається в новому періоді дії договору (визначається по полю «Дата реєстрації» картки).

У цьому випадку, рішення про відмову або видачу картки приймає оператор. Система дозволяє видавати карти для договорів, за якими немає фактичних надходжень у новому періоді дії.

Визначення залишків страхової суми за полісом (при видачі картки), а також перерахунок використаних сум виконуються за таким принципом: за полем «Дата реєстрації» картки визначається активний об'єкт у рамках полісу. Тобто. той для якого дата реєстрації картки знаходиться у період дії об'єкта. Про активні та неактивні об'єкти див. у пунктах «Опис алгоритму (схеми) автоматичного продовження терміну дії договорів», «Результати на формі поліса». Усі розрахунки виконуються для встановленого об'єкта.

**************

Організація обліку договорів медичного страхування

(Поліси, клієнти, врегулювання за договорами медичного страхування) 

Реєстрація клієнтів

Основний принцип - централізований облік клієнтів.

Кожен клієнт у системі має персональний страховий код – присвоюється системою автоматично при введенні або вводиться самостійно. Переважним є перший варіант з метою уникнення дублів кодів клієнтів по філіях.

Заносити дані по новому клієнту, тільки якщо він відсутній в системі.

Персональний страховий код клієнта є унікальним у рамках Компанії. З метою уникнення дублів персональний страховий код складається з двох частин: префікс (код філії) + код унікальний в рамках філії. У такій формі код надається автоматично.

Типи клієнтів: юридичні особи, фізичні особи, групи клієнтів.

Рекомендовані заходи щодо запобігання дублям у реєстрі клієнтів: вводити серію, номер паспорта, ідентифікаційний код, табельний номер + місце роботи – для фізичних осіб; код ОКПО – для юридичних осіб.

Реєстрація бланків полісів

Номер бланка унікальний у межах типу бланка.

Тип бланка – символьний (до п'яти символів), номер – цілий.

Рекомендується унікальність типів і номерів бланків визначити в рамках Компанії. Альтернатива – унікальний бланк для кожної філії. Рекомендується перший варіант.

Видані бланки реєструються у системі перед введенням полісів.

Контроль типів бланків активується автоматично, якщо занесено хоча б один діапазон даного типу. Після активізації контролю бланків система не дозволяє видати поліс, якщо його номер відсутній у зареєстрованому діапазоні (діапазонах).

Операції з бланками:

У режимі обліку бланків фіксуються операції лише з порожніми – незаповненими бланками.

До кожного бланка фіксується як його справжнє місце розташування, а й його попередня історія.

Реєстрація полісів

Рекомендується, для полісів, які оформляються на бланках, вести облік діапазонів бланків.

Унікальність (ідентифікатор) поліса визначається типом бланка та номером бланка (див. попередній пункт).

Можлива реєстрація як полісів індивідуального, і колективного страхування.

По полісу враховується така інформація:

Загальні умови: бланк (код), номер, статус (зареєстрований, зіпсований, втрачений, анульований, не вказано, заброньовано, заявлено), умови набрання чинності (при внесенні платежу, після підписання, після повної оплати), відповідальність (повна пропорційна) , страхувальник, агент, контрагенти (всі учасники полісу, крім страхувальника, агента та посередників), комісія, посередники та треті особи, дата підписання, страхова сума, валюта страхової суми, територія дії, термін дії, період дії, період покриття.

Об'єкти-ризики (програми страхування): перелік об'єктів, ризиків по об'єктах, страхова сума, тариф та премія щодо об'єктів - ризиків.

Платежі: планові та фактичні платежі, з урахуванням дати надходження платежу, звітного періоду (період оподаткування цього платежу), суми платежу. Платіж у межах поліса може бути як одноразовим, і розстроченим з періодичністю: день, місяць, квартал, рік, довільно. План платежів форм ється як автоматично, так і вручну оператором. Переказ платежу у стан «факт» (оплачений) виконується шляхом зв'язку платежу з платіжним документом – банківською випискою. Введення банківської виписки здійснюється окремо.

Додаткова інформація щодо полісу: особливі умови, примітки, ліміти відповідальності, франшизи, знижки/надбавки, адендуми, звітний період.

Франшизи, знижки, ліміти відповідальності можуть бути визначені для будь-якого рівня поліса (об'єкт, ризик і т.д.). Їх облік обов'язковий, якщо вони беруть участь у розрахунку премій.

Реєстрація адендуму (змін умов полісу)

Можливі такі варіанти:

1. Зміна загальних умов полісу:

2. Зміна списку застрахованих та ризиків.

3. Зміна списку агентів, посередників та комісії.

Реєстрація адендумів ускладнює облік, у зв'язку з чим реєструвати адендуми необхідно лише у випадках, коли це доцільно.

Реєстрація банківської виписки, зв'язок платежів

Зв'язок платежів за полісами здійснюється з бухгалтерськими платежами, згідно з даними щодо банківської виписки. Банківська виписка заповнюється за даними бухгалтерської програми, або за даними банку (з файлу системи клієнт-банк), за страховими платежами. У банківській виписці потрібно здійснювати ідентифікацію платника/отримувача та підрозділ, якому призначено платіж, згідно із загальним реєстром системи.

Банківська виписка має чітко та своєчасно вводиться відповідальною особою.

Кожен плановий платіж полісом необхідно пов'язувати з платежем банківської виписки.

Якщо у банківській виписці сума вже з вирахуванням банківської комісії чи комісії агентів, то залишки по полісу завжди необхідно пов'язувати з платежами взаємозаліку для повноти обліку.

Для однозначного формування платежів взаємозаліку необхідно, щоб кожна сума, чи то комісія чи інші утримання, були підкріплені відповідним документом. Цей документ є підставою для формування платежу взаємозаліку.

У операції з бухгалтерією використовується одна валюта – національна.

Зв'язок платежів за полісами з банківською випискою може бути виконаний як вручну, так і автоматично (з файлу попередньо відомого формату).

Схема зв'язку платежів за полісами з бухгалтерськими платежами

За фактом звернення застрахованого реєструється справа щодо врегулювання.

Справа врегулювання має номер, унікальний у рамках Компанії. Номер справи – символьне поле – 20 символів.

Номер може бути наданий системою автоматично, або введений вручну. Рекомендується перший варіант, щоб уникнути дублів по філіях в рамках Компанії.

Номер справи складається з: коду філії + коду робочого майданчика + № справи (лічильник у рамках робочого майданчика). Робочий майданчик – окрема група робочих місць, підключених до віддаленого сервера (наприклад, медустанови).

Справа може бути заведена за фактом звернення застрахованого до медичного закладу (якщо у медичному закладі встановлено робочий майданчик) або за фактом надходження до офісу Компанії інформації про звернення застрахованого.

У разі, якщо по застрахованому існують незакриті справи, оператор самостійно визначає як реєструвати чергову оцінку – у новій справі чи існуючій.

Необхідна умова реєстрації справи – наявність у системі поліса, яким реєструється справа.

В рамках справи враховуються:

Під час реєстрації нової справи враховується залишок страхової суми за рівнем об'єкт – ризик (застрахований – програма) у межах поліса. Справа реєструється лише за наявності чинного поліса для застрахованого. Поліса може бути як індивідуального страхування, і колективного. Об'єкт за полісом не обов'язково дорівнює страхувальнику.

Атрибути справи щодо врегулювання:

В рамках справи можлива реєстрація оцінок за такими типами: послуги, процедури, рецепти.

Атрибути оцінок:

Кількість оцінок у межах справи необмежена.

Заповнення суми за процедурами та послугами можливе як вручну, так і з довідника тарифів. У довіднику тарифів окремо реєструються послуги та процедури, з урахуванням медичного закладу, складності, періоду дії та суми останніх.

Процес обліку відшкодувань закінчується роздруком розпорядження на виплату та закриття справи.

Кожну справу необхідно закривати, як тільки по ній здійснено всі виплати. Рішення про закриття справи приймає фахівець, який веде справу у кожному випадку індивідуально. Рекомендується до кінця календарного місяця закрити всі незакриті справи.

Створення звітів

За даними, внесеними до інформаційної системи Insurance Company, можна створювати необмежену кількість звітів за різними методиками.

Для отримання правильних даних у звітах необхідно, щоб усі дані були безпомилково занесені в інформаційну систему: дані поліси, врегулювання, дані довідників.

Експорт/імпорт (обмін даними)

Детально процедуру обміну даними описано в інструкції адміністратора. Імпорт даних може бути здійснений як із файлів, сформованих іншими програмами, так і з файлів, сформованих системою Insurance Company.

Обмін даними може відбуватися між філіями Компанії, а також у рамках окремої філії між робочими майданчиками. Періодичність обміну даними визначається індивідуально відповідальним за імпорт даних (див. нижче Посібник для робочих місць). Рекомендується проводити обмін даних у рамках філії один раз на добу, між філією: з філії до центрального офісу – не рідше одного разу на місяць; з центрального офісу до філій – при необхідності.

Відстеження помилок та конфліктів у даних здійснюється шляхом аналізу протоколів експорту/імпорту та внесенням змін до даних.

Схема взаємодії центрального офісу та філій Компанії з передачі даних

З філії до центрального офісу передається вся страхова інформація по філії за певний період.

Можлива передача страхової інформації з центрального офісу до філій (індивідуально для кожної філії), наприклад, при пошкодженні даних у філії з метою їх відновлення.

У штатному режимі у філію з центрального офісу передається інформація за довідковими даними, настройками продуктів, тарифами та ін.

Створення звітів

За даними, внесеними до інформаційної системи Insurance Company, можна створювати необмежену кількість звітів за різними методиками.

Для отримання правильних даних у звітах необхідно, щоб усі дані були безпомилково занесені в інформаційну систему: дані поліси, врегулювання, дані довідників.

Посібник для робочих місць

Відповідальний за контрагентів

Здійснює облік агентів страховиків, офісів, брокерів, контрагентів, співробітників, перестраховиків, медичних установ, станцій технічного обслуговування та інших фізичних та юридичних осіб, з якими страховик має договори, крім полісів страхування. Відповідальний за контрагентів не повинен допускати дублювання у реєстрі клієнтів, своєчасно вводити нових контрагентів. Якщо контрагент звільняється або більше не існує – перевести його у статус ”неактивний”. При заповненні Карти клієнта* необхідно вводити всі наявні дані клієнта. При обліку агентів як код можна використовувати прийнятий код агента, якщо він відповідає вимогам системи. Для агента необхідно заповнити форму Агентський договір*, що викликається із форми Карта клієнта*. При обліку офісів – призначити їм номери таким чином: 01 – центральний офіс, інші офіси нумеруються – 02, 03 тощо до 99. Якщо в агента існують індивідуальні відсотки, які відрізняються від прийнятих за продуктами, їх потрібно ввести до Конфігуратора*, звернувшись до адміністратора.

Відповідальний за бланки

Повинен своєчасно реєструвати рух вільних бланків, оскільки під час введення поліса контролюється наявність виданого бланка. Як тільки бланки полісів потрапляють до страховика з друкарні або іншого страховика, відповідальний повинен внести їх у систему, використовуючи режим видачі бланків*. За будь-яких подальших дій з бланками відповідальний повинен використовувати режим передачі бланків*, роздруковувати та підписувати Акт прийому-передачі.

Відповідальний за поліси

Здійснює введення всіх полісів у системі, введення комісійних з полісів, а також зв'язок платежів з полісів з платежами банківської виписки, відстежує умови оплати полісів. Також відповідальний за введення полісів може виконувати додаткові функції обслуговування полісів: здійснювати моніторинг взаємодій з клієнтом за допомогою Щоденника*, визначати умови укладання нових полісів відповідно до страхової інформації по клієнту, формувати листи клієнтам.

Відповідальний за банківську виписку

Повинен підтримувати актуальність банківської виписки, вносити або імпортувати платежі (в т.ч. платежі взаємозаліку) щодня, оскільки ця інформація використовується менеджерами для відстеження умов полісів. Відповідальний за банківську виписку має додатково ідентифікувати платника/отримувача та страховий підрозділ, відокремлювати страхові платежі. Якщо платник/одержувач відсутній у списку клієнтів, він повинен внести його, запобігаючи дублюванню. Відповідальний за банківську виписку також здійснює централізований зв'язок платежів за певними продуктами, агентами або клієнтами.

Відповідальний за врегулювання

Відповідає за те, щоб кожна страхова справа, кожне відшкодування фіксувалося в системі. Потрібно вносити всі необхідні дані щодо врегулювання. При необхідності призначати завдання відповідальному за поліси ввести поліси, якими необхідно здійснювати врегулювання. По кожній страховій виплаті мають бути заповнені всі дані щодо врегулювання, справи, претензій, об'єктів, що постраждали; сформовано, роздруковано та підписано розпорядження на виплату; розпорядженню надано статус "сплачено". Після здійснення всіх робіт у справі його потрібно своєчасно переводити у стан “закрито”, перевіривши завершення всіх дій у цій справі.

Відповідальний за імпорт даних

Відповідає за завантаження даних у систему із зовнішніх файлів. Ці файли можуть бути сформовані іншими програмами або системою Insurance Company, встановленою в інших офісах. Слідкує за протоколами перенесення та протоколами помилок, при необхідності усуває конфлікти даних.

Визначення робочих місць є умовним і одна людина може об'єднувати кілька робочих місць.

В рамках робочого місця можуть працювати кілька спеціалістів.

Кожен фахівець повинен знати роботу з інтерфейсом системи та загальними довідниками та успішно пройти практичне заняття у режимі навчання.

Інтерфейс системи налаштовується в такий спосіб, що це необхідні дані підсвічуються рамками іншого кольору, а доступні дані виводяться на інтерфейс - необхідність заповнення даних визначається інтерфейсом системи.