Інформаційна система InsCom
Короткий опис функціональності InsCom
Єдина база даних
Бланки
Поліси прямого страхування і перестрахування.
Врегулювання та відшкодування збитків.
Клієнти і об'єкти страхування.
Зв'язок бухгалтерського та страхового блоку.
Агенти і комісійні.
Всі види страхування
Медичне.
Майна.
Від нещасного випадку.
Транспортних засобів.
Відповідальності.
Життя.
Розрахунки і контроль даних
Розрахунок премій з урахуванням знижок і надбавок.
Менеджмент ризиків і актуарні розрахунки.
Необмежене використання аналітичних методів.
Зручне користування
Оформлення інтерфейсу в єдиному стандарті.
Сучасні екранні форми.
Професійно оформлені звіти з використанням параметрів.
Допомога по системі.
Захист даних
Для кожного користувача визначаються права доступу:
На рівні Active Directory MS Windows.
На рівні системи управління базами даних MS SQL Server.
На рівні інтерфейсу.
На рівні параметрів системи.
Internet
Робота з Internet за допомогою Web-браузера на різних пристроях.
Веб сервіси отримання даних.
Веб сервіси відправки даних.
Багатомовна реалізація
Форм.
Звітів.
Довідкових даних.
Страхові продукти
Страховий продукт є основою обліку InsCom. Всі характеристики кожного страхового продукту визначаються при налаштуванні. InsCom дозволяє оперативно створювати різноманітні продукти і пропонувати страхові поліси з багатьма ризиками і об'єктами страхування.
Клієнти
У InsCom реалізований єдиний реєстр клієнтів. Він містить фізичні та юридичні особи, які є реальними або потенційними клієнтами страхової компанії, а також будь-яких інших учасників страхового процесу.
Персональні дані фізичної або юридичної особи зберігаються в одному місці. InsCom забезпечує можливість звіту про зв'язок між будь-яким застрахованою особою і його договорами, платежами, виплатами, застрахованими об'єктами. Це дає можливість здійснити ефективний контроль взаємодій з клієнтом, знизити ймовірність помилок або фальсифікацій. Таким чином в системі зберігається повна інформація про кожного клієнта.
Об'єкти
У InsCom реалізований єдиний реєстр об'єктів. Об'єкти мають широкий спектр атрибутів, необхідних для подальшого аналізу. Наявність інформації про застрахованих об'єктах і їх власників, фіксація зв'язків між ними і можливість оперативного пошуку є ефективними засобами контролю і боротьби з шахрайством.
Модулі
Конфігуратор
Параметрів системи.
Страхових продуктів.
Параметрів філії.
Документи
Основний модуль InsCom, здійснює облік полісів і збитків. InsCom здійснює контроль над введеними даними: відповідність їх правилам страхування і умов конкретного продукту. InsCom може автоматично обчислювати страхову премію та інші складові за полісом.
Поліси прямого страхування
У InsCom реалізований облік полісів прямого страхування з будь-яким правилам страхування. Інформація про планові платежі за полісом передається в бухгалтерію. Поліс можна друкувати на принтері.
Перестрахування
У InsCom реалізований облік вхідного і вихідного перестрахування.
У InsCom обробляються всі типи договорів між компанією і перестраховиками. Сюди належать пропорційні і непропорційні договори перестрахування. Договори перестрахування можуть ставитися до конкретного страхового договору, до конкретного об'єкта або ризику. Може здійснюватися автоматична передача договорів до перестрахування.
У InsCom є можливість автоматичного розрахунку страхової суми, переданої до перестрахування. Цей процес може здійснюватися за кожним договором або автоматично по групі договорів.
Врегулювання збитків
InsCom підтримує повний цикл врегулювання збитків:
Повідомлення про страхові випадки.
Претензії на відшкодування.
Постраждалі об'єкти.
Оцінки збитку.
Регрес.
Витрати, гонорари.
Страхові виплати.
InsCom забезпечує ефективний облік врегулювання, відповідно до виду врегулювання і умов договору. Система також веде облік компенсацій при наявності перестрахувальника.
Облік процесу врегулювання за всіма видами страхування, в т.ч. по добровільному медичному страхуванню, здійснюється в єдиній базі даних.
Автоматичне відновлення договорів
Система автоматично відстежує договору, термін дії яких проходить через певну кількість днів. Система готує листи для клієнтів з пропозиціями для його відновлення.
Комісійна винагорода агентів
InsCom визначає комісійну винагороду. Комісійні можуть розподілятися між кількома посередниками - співробітниками або філіями компанії.
Офіс
Модуль здійснює зв'язок страхового та бухгалтерського блоку, облік бланків полісів, а також автоматизацію документообігу компанії.
Зв'язок з бухгалтерським блоком і залік платежів
InsCom відстежує всі дати, коли має надійти платіж. Генерується звіт про заборгованість і планових платежах за певний період.
InsCom дозволяє здійснювати залік:
Одного банківського переказу по групі полісів.
Кількох банківських переказів по одному полісі.
Облік бланків полісів
Облік всіх операцій з бланками:
Прийом бланків компанією.
Передача в підвідділ.
Передача до філії.
Передача агентам.
Повернення бланків. При обліку полісів автоматично здійснюється списання бланків.
Звіти
InsCom має велику кількість звітів для аналізу інформації. Завдяки їм страхова компанія завжди володіє актуальною інформацією.
У систему можуть бути добавленни нові звіти. Для обробки даних використовуються сучасні технології:
Вбудований генератор звітів.
Експорт в MS Word, в MS Excel або в HTML.
Засіб аналітичної обробки OLAP.
Монітор керівника
Модуль призначений для відображення показників діяльності компанії в цілому:
В режимі реального часу.
У будь-якому розрізі.
У наочній і зручній формі.
Переваги InsCom
Облік всіх страхових даних у загальній базі.
Приведення в порядок всіх даних відповідно до страхової бізнес-логікою.
Зручний сучасний уніфікований інтерфейс.
Можливість використання стандартної бухгалтерської програми.
Технології тільки від Microsoft - мінімальна вартість необхідних ліцензій.
Не має обмежень за обсягами даних і кількості користувачів.
Робота в мережі або на окремому комп'ютері.
Зв'язок з філіями за допомогою телефонних з'єднань або Internet.
Якісне обслуговування клієнтів за рахунок гнучкого підбору умов страхового захисту.
Додаткові Особливості InsCom
Подання даних, правил обліку і термінології відповідно до міжнародних стандартів.
Однозначну механізм розбивки за ризиками, видами страхування і лініях бізнесу страхових даних: премій, виплат, заявлених збитків, резервів виплат, витрат на ведення справи, адміністративних витрат.
Ведення історії змін заявлених збитків і резервів виплат.
Формалізоване відображення суті змін по адендуму.
Облік періодів страхового покриття по кожній частині внесеного платежу.
Закриття звітних періодів у розрахункових даних.
Ведення плану виплат.
Формалізований механізм зв'язку з бухгалтерією.
InsCom-life InsCom (life)
Інформаційна система для компаній зі страхування життя InsCom (life)
InsCom (life) реалізована на платформі InsCom і успадковує всі її функції.
У той же час в ній реалізовані особливості страхування життя, враховані вимоги, що пред'являються до страхових компаній зі страхування життя:
Перехід на інші програми страхування із збереженням історії.
Довготривалі графіки внесення платежів.
Бенефіціарії з прив'язкою до ризиків.
Різні валюти поліса, відстеження курсу.
Зміна умов полісів (списку застрахованих, страхових сум, премій) зі збереженням історії.
Таблиці смертності.
Ануїтет, періодичні виплати.
Актуарні розрахунки для страхування життя.
Облік інвестиційного доходу, бонусів.
Облік викупних сум.
Редукування страхової суми.
Розрахунок резервів.
Розрахунок податку на прибуток.
Складання обов'язкової звітності.
InsCom-Integration - модуль інтеграції InsCom з зовнішніми веб сервісами
InsCom-Integration реалізує отримання та передача інформації по полісам та страховим випадкам за допомогою веб сервісів.
1. Отримання даних з зовнішніх веб сервісів та занесення в базу даних InsCom.
Отримання даних відбувається шляхом запиту з боку страхової компанії до інформаційної системи банка.
Модуль реалізований як консольний додаток на С #, запускається з командного рядка, з конфігураційним файлом.
Розклад запуску програми налаштовується в schtasks.
Імпорт даних шляхом виклику веб сервісів з використанням API зовнішніх програм.
Логування прийнятих з веб сервісу даних у зовнішніх лог-файлах.
Контроль даних і помилок при імпорті.
Запуск опитування веб сервісу та імпорту даних за розкладом.
Даний підхід значно спрощує укладання угоди про співпрацю з банком та мінімізує витрати на ведення справи з на боці банку.
З боку страхової компанії за розкладом запускається консольна утиліта, яка через веб сервіс системи банку самостійно в пакетному режимі забирає дані та завантажує в базу даних InsCom.
2. Передача даних з InsCom у зовнішні веб сервіси.
Звернення InsCom до зовнішніх веб сервісів для передачі даних по полісах та страхових справах.
Запуск веб сервісів InsCom відбувається за розкладом.
При запуску програма запускає підготовлений веб сервіс InsCom.
Веб сервіс перебирає по черзі всі поліси та справи в стані "очікує обробки" і по кожному виконує визначену функцію.
Дії і результати пишуться в зовнішній протокол.
По обробленим (успішно переданим) даним знімається позначка в протоколі переносу "очікує обробки".
Cтраховий агрегатор електронних полісів на платформі InsCom
InsCom-Agr зручно та швидко працює на комп'ютерах, планшетах та смартфонах.
Сфера використання.
Продаж електронних полісів
АРХІТЕКТУРА
Платформа - Microsoft .NET Framework.
Мова програмування - C#.
Razor - механізм візуалізації (view engine).
Система логування запитів клієнтів та продажів полісів к зовнішніх файлах.
Середовище розробки - Microsoft Visual Studio.
Фреймворк bootstrap з реалізований шаблоном для оформлення веб інтерфейсів.
Додаткові компоненти
Отримання параметрів ТЗ по держ номеру - використовується API Штрафи.юа. Необхідно підписати договір.
Отримання пропозицій від страхових компаній, укладення договору, оплата через LiqPay - використовується API Поліс.юа. Необхідно підписати договір.
Відправка полісу електронною поштою. Необхідно налагодження smtp gmail.
Використання захищеного протоколу https. Необхідне придбання та встановлення ssl-сертифікату.
Використання доменного імені - необхідне придбання та налагодження доменного імені.
Дві мови інтерфейса - українська та російська.
Код для SEO-просування сайту в пошукових системах (Google ld+json).
Код для відслідковування вдалих покупок (Conversion).
Також реалізований функціонал, закритий в коментарях:
Crisp: Платформа обміну повідомленнями клієнтів (реалізовано, протестовано, та закрито в коментарі. Необхідна реєстрація).
SMS-повідомлення, перевірка коду (підпис клієнта), можливість зміни номеру та повторна відправка (реалізовано, протестовано, та закрито в коментарі. Необхідно підписати договір з надавачем послуг SMS-відправки).
Bank ID з автоматичним заповненням полів Заявки (реалізовано, протестовано, та закрито в коментарі. Необхідно підписати договір).
Аналітика, контроль вдалих покупок, просування (Google Tag Manager).
Реалізований продукт - ОСЦПВ
В рішенні закладена можливість додавання інших страхових продуктів (КАСКО, ДГО, тревел, НС)
Медичний асистанс у структурі страхової компанії
Компонент призначений для організації роботи асистанського відділу страхової компанії з обслуговування полісів медичного страхування та обліку витрат на врегулювання збитків за цими полісами.
Код продукта 024
Функції:
Облік звернень клієнтів.
Облік полісів.
облік застрахованих.
облік витрат на лікування.
облік рахунків медичних установ.
Автоматична обробка платежів – сума зв'язку рахунків від медичних установ з плановими витратами по клієнту.
Компонент складається з модулів:
модуль страхової компанії.
модуль медичного закладу.
модуль обміну даними.
Побудова обліку
Облік інформації з полісів:
поліси можуть бути двох типів: індивідуального страхування, колективного страхування;
страхувальник у полісі – фізична чи юридична особа;
об'єкт страхування в полісі (застрахований за полісом) – фізична особа;
в одного застрахованого не повинно бути більше одного поліса, що діє;
кількість ризиків одного застрахованого у межах поліса необмежено;
ліміт відповідальності враховується за рівнями: поліс, об'єкт (застрахований), ризик;
продовження полісів – ні, після закінчення терміну дії виписується новий поліс;
внесення змін до умов страхування поліса – ні, старий поліс анулюється, виписується новий поліс;
Облік збитків:
з метою обліку витрат реєструється справа (картка) щодо врегулювання збитків;
під час реєстрації справи здійснюється контроль наявності чинного поліса, залишку страхової суми за рівнем поліс-об'єкт-ризик;
під час реєстрації справи здійснюється перевірка на наявність незакритих справ щодо застрахованого. Система дозволяє зареєструвати кілька незакритих справ за одним застрахованим;
облік використаних сум та залишків страхових сум – за рівнем поліс-об'єкт-ризик;
основні параметри справи: номер, дата реєстрації, період лікування, тип (лікарняний поліклініка, діагностика, відмова), застрахований, профіль, діагноз (довідник МКБ – один основний діагноз і три додаткові, та у довільній формі), поліс, ризик, звітний період оцінки витрат;
склад оцінки витрат у справі – витрати на послуги, процедури, медикаменти;
сума витрат на послуги та процедури може вводитися користувачем, або розраховуватися виходячи з даних сітки тарифів для зазначеного у справі медичного закладу;
розрахунок витрат на послуги та процедури по тарифній сітці здійснюється тільки для закритих справ, в результаті запуску спеціального режиму. Параметри тарифної сітки: медична установа, тип «послуга»/«процедура», найменування послуги/процедури, складність, період дії тарифу, сума тарифу;
розрахунок залишків страхових сум здійснюється в результаті запуску спеціального режиму.
============= Додаткові відомості ===================
Реєстрація полісів.
Для реєстрації полісів налаштований продукт 24 - Добровільне медичне страхування.
Під час реєстрації поліса система дозволяє вказати такі параметри:
загальні умови полісу;
список застрахованих осіб, ліміти щодо застрахованих осіб;
перелік програм із застрахованих осіб, ліміти за програмами;
план платежів;
Додаткові умови.
Імпорт полісів за договором
Імпорт полісів за договором здійснюється за формою реєстрації договорів за продуктом 242 – «Договори ДМС». Опис імпорту у розділі Допомога, код розділу imp_M.
Медичний асистанс
Картки (справи з врегулювання) реєструються у розділі «Медичний асистанс»..
Довідник значень резервів
Довідник значень резервів заповнюється в «Медичний асистанс» -> «Розрахунки та тарифи» -> «Довідник резервів». Значення довідника автоматично обробляються під час реєстрації медичних карток.
************ Додаткові описи ***********************
Продукт призначений для роботи асистанського відділу страхової компанії з обслуговування полісів медичного страхування та обліку витрат на врегулювання збитків за цими полісами.
Для роботи потребує встановленої інформаційної системи InsCom.
Функції:
Облік полісів.
Облік застрахованих.
Облік витрат.
Автоматична обробка полісів та платежів.
Інформаційний обмін із медичними установами, підприємствами, центральним офісом страхової компанії.
Продукт складається з модулів:
Модуль страхової компанії.
Модуль медичного закладу.
Модуль обміну даними.
***ФУНКЦІОНАЛЬНІСТЬ***
Модуль страхової компанії
***Облікова інформація***
Облік полісів.
Облік інформації, що надходить від медичних установ.
Поліси можуть бути як індивідуального страхування, так і колективного.
Тип справи – лікарняний, поліклініка, діагностика, відмова. Можливе додавання нових типів.
Діагноз (за довідником МКБ – один основний діагноз та три додаткові) та діагноз у довільній формі.
Лікар (довідник).
Відділення (довідник).
У рамках справи можлива реєстрація оцінок за такими типами: послуги, процедури, рецепти.
*** ДЕТАЛЬНА ФУНКЦІОНАЛЬНІСТЬ***
КЛІЄНТИ
Основний принцип - централізований облік клієнтів.
Кожен клієнт у системі має персональний страховий код, який надається системою автоматично при введенні.
Дані щодо нового клієнта реєструються лише у випадку, якщо він відсутній у системі.
Персональний страховий код клієнта є унікальним у рамках Компанії. З метою уникнення дублів, персональний страховий код складається з двох частин: префікс (код філії) + код унікальний у рамках філії. У такій формі код надається автоматично.
Типи клієнтів: юридичні особи, фізичні особи, групи фізичних осіб.
Заходи щодо уникнення дублів у реєстрі клієнтів: реєструвати табельний номер + місце роботи – для фізичних осіб; код ОКПО – для юридичних осіб. Додатково зареєструвати: серію, номер паспорта, ідентифікаційний код.
Введення/редагування інформації щодо клієнтів – лише в офісі Компанії.
Способи введення: ручний оператор, імпорт із зовнішнього файла встановленого формату.
РЕЄСТРАЦІЯ БЛАНКІВ
Номер бланка унікальний у межах типу (серії) бланка.
Тип бланка – символьний (до 5 символів), номер – ціле число.
Рекомендується унікальність типів і номерів бланків визначити в рамках Компанії. Альтернативний варіант – унікальний тип бланка для кожної філії.
Видані бланки реєструються у системі перед введенням полісів.
Контроль типів бланків активується автоматично, якщо занесено хоча б один діапазон даного типу. Після активізації контролю бланків система не дозволяє видати поліс, якщо його номер відсутній у зареєстрованому діапазоні (діапазонах).
АГЕНТИ
Агенти реєструються у системі, заповнюється довідник «Комісія агентів». Код агента вказується у полісі. Розрахунок комісійної винагороди проводиться автоматично.
ПОЛІСИ
Унікальний ідентифікатор поліса визначається типом (серією) бланка та номером бланка. Тип та номер бланка – унікальні у рамках Компанії.
Поліси можуть бути індивідуального та колективного страхування.
По полісу враховується така інформація:
Загальні умови: бланк (код), номер, статус, умови набуття чинності, тип відповідальності, страхувальник, агент, контрагенти (всі учасники полісу, крім страхувальника, агента та посередників), комісія, дата підписання, страхова сума, термін дії, період покриття.
Об'єкти-ризики (програми страхування): перелік застрахованих об'єктів, ризиків по об'єктах, страхова сума, тариф та премія щодо об'єктів - ризиків.
Платежі: планові та фактичні платежі, з урахуванням планової дати надходження платежу, звітного періоду (період оподаткування цього платежу), суми платежу. Фактична дата надходження платежу – зазначається у банківській виписці. Платіж у межах поліса може бути як одноразовим, і розстроченим. Переказ платежу у стан «факт» (оплачений) виконується шляхом зв'язку платежу з платіжним документом – банківською випискою.
Зарахування платежів здійснюється двома способами: автоматично – шляхом імпорту банківських виписок із зовнішнього джерела, шляхом ручного введення даних оператором.
Додаткова інформація щодо полісу: особливі умови, примітки, ліміти відповідальності, франшизи, знижки/надбавки, адендуми, звітний період.
Введення/редагування інформації щодо полісів (в т.ч. реєстрація банківських виписок та зв'язування платежів) – лише в офісі Компанії.
Способи введення: ручний оператор, автоматична генерація полісів, на підставі даних із зовнішнього файлу, встановленого формату.
АДЕНДУМИ (ПРОДОВЖЕННЯ ТЕРМІНУ ДІЇ ПОЛІСІВ)
Опис моделі та посібник користувача – в «Інструкції з виконання адендуму – продовження терміну дії договорів» (інструкція наведена нижче).
БАНКІВСЬКА ВИПИСКА, ЗВ'ЯЗОК ПЛАТЕЖІВ
Введення банківських виписок та зв'язок платежів здійснюються лише в офісі Компанії.
Способи введення банківських виписок та зв'язку платежів: ручний оператором, автоматичний імпорт та зв'язування на підставі даних із зовнішнього файлу встановленого формату.
Формати файлів та алгоритм імпорту банківських виписок можуть мати особливості залежно від філії. Подробиці – в індивідуальних для філій інструкціях.
МОДЕЛЬ ПЛАНУ ПЛАТЕЖІВ (ОДИН З МОЖЛИВИХ ВАРІАНТІВ ОБЛІКУ, ПРИ УМОВІ ПРОПОРЦІОНАЛЬНОЇ ВІДПОВІДАЛЬНОСТІ)
Сумарний платіж (факт + план) за полісом завжди повинен дорівнювати премії з полісу.
Сумарний платіж (факт+план) за умовою “місяц.год” (поле “Дата”) завжди має дорівнювати 1/12 премії.
Кожен плановий платіж має бути пов'язаний із платежем банківської виписки (переведений у факт).
При зв'язуванні платежів потрібно правильно вказувати звітний період, яким визначається, у якому періоді платіж буде зарахований у валовий доход.
У плані платежів має бути лише один плановий платіж за конкретний звітний період.
Виняткові ситуації (інструкція оператора)
Винятковими є ситуації, у яких необхідно зарахувати платіж більше чи менше планового у поточному місяці (звітному періоді). У таки х ситуаціях оператор самостійно приймає рішення про необхідні зміни у плані платежів, керуючись положеннями цієї інструкції.
1. Необхідно зарахувати платіж більше за плановий у поточному місяці.
Зарахувати частину платежу (рівну планової), що надійшов, у відповідному місяці (виходячи зі значення поля “Дата”). Переконається у правильності зазначеного звітного періоду.
Залишок платежу, що надійшов, зарахувати на наступний по полю “Дата” запис у плані платежів, попередньо змінивши значення полів “Сума (вал)” та “Платеж” на суму залишку. Якщо платіж більший за плановий більш ніж на 2/12 премії, його слід розподілити на необхідну кількість записів, до виконання умови: сума залишку <=1/12 премії, після чого зв'язати залишок. Примітка: коефіцієнт 1/12 взято з того розрахунку, що загальний платіж за полісом розстрочений на 12 місяців.
Змінити значення поля “Звітний період” на потрібне (для записів на які були зараховані залишки (залишок)).
Якщо залишок менше 1/12 від премії, необхідно сформувати новий запис у плані платежів, зі значенням поля “Дата” рівним даті запису яку зарахований залишок. Сума платежу за цим записом має дорівнювати 1/12 мінус зарахований залишок.
Увага. Якщо щодо платежів є запис про простроченном платежі, тобто. значення поля "Дата" менше поточної, то розподіл залишку слід виконати на цей запис, змінивши значення поля "Звітний період". Значення поля "Дата" залишити незмінним.
Якщо платіж, що надійшов, дорівнює премії, зарахування слід виконати аналогічним чином – по 1/12 на кожний запис, залишивши незмінним значення поля “Дата”, змінивши значення поля “Звітний період” у всіх записах, де це необхідно.
приклад
Плановий платіж складає 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 грн. (наприклад у лютому), необхідно зарахувати її на відповідний запис, змінивши значення поля “Звітний період”. Значення поля “Дата” залишити без змін.
ОСОБЛИВОСТІ АЛГОРИТМУ ІМПОРТУ БАНКІВСЬКИХ ВИПИСОК
Зарахування платежу на поліс відбувається за дотримання наступного набору умов:
У базі даних системи Insurance Company існує поліс, у якого об'єктом є клієнт з табельним номером, рівним зазначеному у файлі-джерелі даних по платежах;
місце роботи об'єкта – відповідає заданому;
у плані платежів за вказаним полісом є плановий страховий платіж з звітним періодом, зазначеним у файлі-джерелі даних з платежів;
у плані платежів відсутні фактичні страхові платежі за зазначений у файлі-джерелі даних з платежів звітний період;
Платіж не зараховується за недотримання хоча б однієї з перелічених умов.
На поліс платежі зараховуються за схемою:
Якщо платіж, що надійшов, дорівнює плановому, то сума зарахованого платежу дорівнює що надійшла;
якщо платіж, що надійшов менше планового, то сума зарахованого платежу дорівнює що надійшла, при цьому автоматично формується новий плановий платіж, за той же звітний період, рівний різниці між плановим і надійшли;
якщо платіж, що надійшов, більше планового, то сума зарахованого платежу дорівнює плановій.
Усі виявлені під час імпорту відхилення виводяться в протокол імпорту платежів.
Аналіз протоколу імпорту платежів повинен проводитись безпосередньо після операції імпорту, до внесення будь-яких змін до даних. Необхідно встановити точну причину, через яку запис потрапив до протоколу, за необхідності вручну внести зміни до даних. Усі зміни, що вносяться, підлягають обов'язковому протоколюванню.
ВРЕГУЛЮВАННЯ ЗБИТКІВ
За фактом звернення застрахованого реєструється справа щодо врегулювання збитків (медична карта/ карта).
Справа врегулювання має номер, унікальний у межах Компанії. Номер справи – символьне поле (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, встановленою в інших офісах. Слідкує за протоколами перенесення та протоколами помилок, при необхідності усуває конфлікти даних.
Визначення робочих місць є умовним і одна людина може об'єднувати кілька робочих місць.
В рамках робочого місця можуть працювати кілька спеціалістів.
Кожен фахівець повинен знати роботу з інтерфейсом системи та загальними довідниками та успішно пройти практичне заняття у режимі навчання.
Інтерфейс системи налаштовується в такий спосіб, що це необхідні дані підсвічуються рамками іншого кольору, а доступні дані виводяться на інтерфейс - необхідність заповнення даних визначається інтерфейсом системи.