47

АННОТАЦИЯ

Данная работа посвящена разработке функциональной модели ФОМС. Для этого был проведен сбор и анализ информации, используемой в ФОМС. Так же был произведен анализ программных и аппаратных средств, которые используются при обработке и хранении информации. После анализа изученных материалов были выявлены проблемы, которые имеют место в ФОМС и построена функциональная модель. Так же в данной работе приведена оценка технико-экономической эффективности решения задач, отображен вопрос безопасности жизнедеятельности и экологичности проекта, а также социальный аспект работы.

THE SUMMARY

Given work is dedicated to development to functional model FOMS. For this was organized collection and analysis to information, used in FOMS. In the same way, the analysis programme was made and hardware, which are used when processing and keeping to information. After analysis studied material were revealled problems, which exist in FOMS and is built functional model. In the same way in given work is brought estimation to technical-econmic efficiency of the decision of the problems, is displayed question to safety to vital activity and ecological capacities of the project, as well as social aspect of the work.

Введение

В мировой практике организации медико-санитарного обслуживания сложились основные системы экономического функционирования здравоохранения: государственная, страховая и частная. Государственная система основана на принципе прямого финансирования лечебно-профилактических учреждений и гарантирует бесплатную медицинскую помощь.

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

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

Цель медицинского страхования - гарантировать гражданам при возникновении страхового случая получения медицинской помощи за счет накопленных средств и финансировать профилактические мероприятия. Систему медицинского страхования целесообразно рассматривать в двух аспектах.

В наиболее широком смысле медицинское страхование представляет собой систему общественного здравоохранения, экономическую основу которой составляет финансирование из специальных страховых фондов. При этом охрана здоровья граждан финансируется «снизу». Страховые фонды образуются за счет различных источников финансирования: средств государственного бюджета, взносов предприятий, предпринимателей и работающих.

В узком смысле это процесс поступления финансовых ресурсов и их расходование на лечебно-профилактическую помощь, дающий гарантию получения этой помощи, причем ее объем и характер определяются условиями страхового договора.

Говоря о системе медицинского страхования, необходимо различать добровольное и обязательное медицинское страхование, так последнее является составной частью государственного социального страхования и обеспечивает всем гражданам Российской Федерации равные возможности в получении медицинской и лекарственной помощи, предоставляемой за счет средств обязательного медицинского страхования в объеме и на условиях, соответствующих программам обязательного медицинского страхования.

1. ПОСТАНОВКА ЗАДАЧИ И ОПРЕДЕЛЕНИЕ ОСНОВНЫХ ПРИНЦИПОВ ОРГАНИЗАЦИИ ФОНДА СТРАХОВАНИЯ

1.1 Цели и задачи ФОМС в системе льготного обеспечения граждан

Составной частью системы социального страхования в РФ является ФОМС (фонд обязательного медицинского страхования).

Страховая медицинская организация включает в себя следующее:

проводит расчеты и оплачивает медицинские услуги лечебно-профилактических учреждений,

реализует непосредственный контроль за объемом и качеством медицинского обслуживания,

защищает права и интересы своих клиентов,

обеспечивает выдачу и учет страховых полисов

Взаимоотношения между страхователем и страховой медицинской организацией реализуется через страховые взносы. По обязательному медицинскому страхованию они устанавливаются как ставки платежей в размерах, покрывающих затраты на выполнение программ ОМС и обеспечивающих рентабельную деятельность СМО.

Фонды обязательного медицинского страхования - это самостоятельные государственные некоммерческие финансово-кредитные учреждения. Согласно Закону «О медицинском страховании граждан в Российской Федерации» основными задачами фондов являются:

аккумулирование финансовых средств на обязательное медицинское страхование,

обеспечение финансовой стабильности государственной системы обязательного медицинского страхования и выравнивание финансовых ресурсов на его проведение,

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

Территориальные фонды ОМС выполняют роль центральной финансирующей организации страховой медицине. Они вступают в правовые и финансовые отношения либо с гражданами (физическими лицами), либо с предприятиями, учреждениями, организациями (юридическими лицами, страхователями), страховыми организациями, а так же объектами здравоохранения. При этом территориальные фонды контролируют объем и качество предоставляемой медицинской помощи.

Немаловажным фактором является создание основы системы ОМС на уровне субъекта РФ, что позволит урегулировать взаимоотношения «центра» и « регионов» в отношении разделения полномочий в системе здравоохранения, а не территориальном уровне осуществлять выравнивание финансовых средств территорий, необходимых для реализации программ ОМС.

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

1.2 Проблема информационного обмена

В настоявшее время существует множество проблем в системе здравоохранения на различных уровнях взаимодействия.

Общие проблемы участников системы здравоохранения:

программы для автоматизации учета в ДЛО не интегрированы по всему набору необходимых функций и не отработаны на практике, обновление информации справочного характера и Федерального регистра затратное по времени (используются магнитные носители информации, доставка курьерами) и ресурсам, не достаточно оперативны и не успевают за изменениями и поэтому приводят к многочисленным нестыковкам в информации в последующем информационном обмене;

организация информационного обмена на уровне транспортировки информации от отправителя к получателю между соответствующими прикладными программными средствами не автоматизирована и не использует современные возможности телекоммуникационной связи;

Проблемы взаимодействия ТФОМС и внешних организаций:

отсутствие единого ответственного за ведение всей НСИ на федеральном уровне в виде электронных баз данных со всей историей внесенных изменений (например, лекарства и их цены с учетом, когда оно внесено или изменилась цена) приводит к самостоятельному формированию справочников ТФОМС и ФО и техническим нестыковкам двух версий справочников;

некоторые граждане, имеющие право на набор социальных услуг, не учтены в Федеральном регистре, а также информация по вновь внесенным сведениям в Федеральный регистр передается в ТФОМС, а значит - поликлиник и аптек с существенным опозданием, с различной задержкой по разным гражданам;

отсутствие постоянного идентификатора гражданина в данных, передаваемых ПФР по Федеральному регистру, затрудняет ведение регистра в ТФОМС с учетом истории изменения информации по каждому гражданину (СНИЛС может измениться);

недостаточно оперативная передача новых сведений, внесенных в Федеральный регистр, по утвержденному регламенту (в течение 10 дней с момента внесения) приводит к случаям отсутствия сведений о гражданах в регистре при выписке рецепта и отпуске лекарств.

Проблемы расчетов за отпущенные лекарства между ТФОМС и ФО:

большое количество неоплаченных случаев выдачи лекарств гражданам, имеющим право на ГСП, по причине несоответствия формальным требованиям медико-экономической экспертизы: отсутствие гражданина в Федеральном регистре, неправильного кода врача или других проблем оформления персонифицированных реестров отпущенных лекарственных средств;

задержки в формировании счетов фарморганизациями;

отсутствие функций учета расчетов с фарморганизациями;

недостаточная регламентация взаимодействия ТФОМС и ФО при осуществлении расчетов за отпущенные ЛС и предоставлению персонифицированных реестров.

1.3 Анализ требований к системе обмена информацией

Для обмена данными используются DBF-файлы.

Порядок, состав и форматы файлов обмена данными между отделениями Пенсионного фонда Российской Федерации и территориальными фондами ОМС определены в следующих документах:

Соглашение между Пенсионным фондом Российской Федерации и Федеральным фондом обязательного медицинского страхования об использовании средств защиты при организации информационного взаимодействия (утверждено Председателем Правления Пенсионного фонда Российской Федерации и директором Федерального фонда обязательного медицинского страхования от 05.11.2004 N ГБ-18-32/98СОГ/N 211-91-2004).

Порядок обмена информацией между отделениями Пенсионного фонда Российской Федерации и территориальными фондами ОМС в ходе реализации Федерального закона N 122-ФЗ от 22.08.2004 с изменениями и дополнениями (утвержден Председателем Правления Пенсионного фонда Российской Федерации и директором Федерального фонда обязательного медицинского страхования 11.07.2005 N 3и/3166/91-и).

Порядок обмена информацией между отделениями Пенсионного фонда Российской Федерации и территориальными фондами обязательного медицинского страхования об отдельных категориях граждан, имеющих право на государственную социальную помощь, в случаях отсутствия сведений о гражданах в региональном сегменте федерального регистра, в том числе о гражданах, временно прибывших с территории других субъектов Российской Федерации (утвержден Председателем Правления Пенсионного фонда Российской Федерации и директором Федерального фонда обязательного медицинского страхования 26.12.2005 N 6И/6495/91-и).

2. ОБЗОР И ВЫБОР АРХИТЕКТУРЫ БАЗЫ ДАННЫХ

От структуры баз данных зависит производительность и быстродействие разрабатываемых информационных систем. При увеличении доли электронной информации на предприятиях возникает необходимость её хранить и обрабатывать таким образом, чтобы пользователь получал нужную ему информацию быстро и в полном объёме. В процессе приёма дистанционных данных со спутников, происходит их преобразование, дешифрирование, корректировка, и подготовка к анализу. Возникает ряд трудностей с методами и способами хранения и представления данных, чтобы в последующем обеспечить проведение широкомасштабного анализа полученных изображений. Для разработки информационной системы в дипломном проекте необходимо выбрать оптимальную структуру базы данных, способной оперировать большими массивами информации за минимальное количество времени. Таким образом, при создании информационных систем для управления данными, успех разработки в большой степени зависит от правильного выбора системы управления базами данных (СУБД) и её архитектуры - платформы любой информационной системы [2,3,4].

2.1 Общие сведения. Обзор структур баз данных

В наше время без систем управления базами данных не обходится практически ни одна организация, они применяются для различных целей. Только небольшие организации могут обобществить данные в одной полностью интегрированной базе данных. Чаще всего администратор баз данных (даже если это группа лиц) практически не в состоянии охватить и осмыслить все информационные требования сотрудников организации. Поэтому информационные системы больших организаций содержат несколько десятков БД, нередко распределенных между несколькими взаимосвязанными ЭВМ различных подразделений.

Отдельные БД могут объединять все данные, необходимые для решения одной или нескольких прикладных задач, или данные, относящиеся к какой-либо предметной области (например, финансам, бюджетированию и т. д.). Первые обычно называют прикладными БД, а вторые - предметными БД (соотносящимся с предметами организации, а не с ее информационными приложениями).

Предметные БД позволяют обеспечить поддержку любых текущих и будущих приложений, поскольку набор их элементов данных включает в себя наборы элементов данных прикладных БД. Вследствие этого предметные БД создают основу для обработки неформализованных, изменяющихся и неизвестных запросов и приложений (приложений, для которых невозможно заранее определить требования к данным). Такая гибкость и приспосабливаемость позволяет создавать на основе предметных БД достаточно стабильные информационные системы, т.е. системы, в которых большинство изменений можно осуществить без вынужденного переписывания старых приложений.

Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, разработчик дает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных (См. рис. 1.1.).

Рис. 1.1. Уровни моделей данных

Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов, этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.

Остальные модели, показанные на рис. 1.1., являются компьютеро-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.

Такие базы данных называют операционными или транзакционными, поскольку они характеризуются огромным количеством небольших транзакций, или операций записи-чтения. Компьютерные системы, осуществляющие учет операций и собственно доступ к базам транзакций, принято называть системами оперативной обработки транзакций (OLTP - On-Line Transactional Processing) или учетными системами.

Учетные системы настраиваются и оптимизируются для выполнения максимального количества транзакций за короткие промежутки времени. Как правило, большой гибкости здесь не требуется, и чаще всего используется фиксированный набор надежных и безопасных методов сбора данных и отчетности. Показателем эффективности является количество транзакций, выполняемых за секунду. Обычно отдельные операции очень малы и не связаны друг с другом. Однако каждую запись данных, характеризующую взаимодействие с клиентом (звонок в службу поддержки, кассовую операцию, заказ по каталогу, посещение Web-сайта компании и т.п.) можно использовать для получения качественно новой информации, а именно для создания отчетов и анализа деятельности фирмы.

Реляционная архитектура. С появлением персональных компьютеров получил распространение способ обработки данных, ориентированный на пользователя. Наиболее простыми в реализации оказались системы управления реляционными базами данных (DB2, Oracle, Sybase, Interbase, Access, Microsoft SQL Server и т.д.), использующие наглядные двумерные модели данных (таблицы). Кажущаяся легкость разработки породило серьезное заблуждение, что с помощью непроцедурного языка запросов (SQL) можно реализовать практически все. И если информационный объект простой (например справочник), то проблем нет. Но проблема возникает, когда разработчик приложений пытается втиснуть отношения внутри сложного информационного объекта (реального мира) в рамки, ограниченные простыми реляционными технологиями. Результатом становится нагромождение таблиц, сложным образом взаимодействующих между собой и плохо отражающих реальные отношения между данными. Также связи между этими таблицами часто находятся не в базах данных, где ими можно управлять более эффективно, а скрыты в прикладных программах. И, конечно, все это требует значительных вычислительных ресурсов. Не секрет, что реляционная модель данных - одно из самых серьезных препятствий для эффективной работы приложений. Поэтому закономерно появление постреляционных СУБД, в которых быстродействие и масштабируемость транзакционной многомерной модели данных сочетаются с мощностью и гибкостью объектной технологии. Многомерные модели данных значительно упрощают задачи моделирования данных, поскольку сложные структуры реального мира можно отображать, не игнорируя реальность с учетом доступности для технологии. Кроме того, такие модели обеспечивают значительный выигрыш в скорости при выполнении сложных задач обработки данных. В качестве примера можно привести полетное задание как информационный объект. Если в реляционной СУБД это набор таблиц (файлов) с реквизитами, то в многомерной базе данных все реквизиты полетного задания находятся в как бы одном файле со всеми необходимыми связями. И доступ к ним осуществляется напрямую методом навигации. Поэтому скорость доступа не зависит от объема базы данных.

В настоящее время реляционные СУБД (РСУБД) ищут ответ на этот вопрос на путях модернизации и внешних архитектурных изменений. Это, так называемый, “объектно-реляционный” подход. Существо подхода в сохранении реляционного ядра системы и дополнении его более или менее удачными объектными надстройками. На этом пути изготовители РСУБД сталкиваются с двумя проблемами: снижение производительности даже по сравнению с исходной РСУБД (появляется еще один слой интерпретации объектов модели предметной области) и затруднения с реализацией в полном объеме концепций объектного программирования средствами SQL. Возникает противоречивая ситуация и при проектировании. Логически связанный проект распадается на две различные части: объектно-ориентированное проектирование и разработка схемы базы данных и, фактически, традиционный реляционный подход к разработке программного кода приложения. Технически, в рамках существующих стандартов проблема не находит своего решения, поэтому уже довольно длительное время прилагаются усилия по выработке нового стандарта SQL.

OLAP архитектура. Набор аналитических функций в учетных системах обычно весьма ограничен. Схемы, используемые в OLTP-приложениях, осложняют создание даже простых отчетов, так как данные чаще всего распределены по множеству таблиц, и для их агрегирования необходимо выполнять сложные операции объединения. Как правило, попытки создания комплексных отчетов требуют больших вычислительных мощностей и приводят к потере производительности.

Кроме того, в учетных системах хранятся постоянно изменяющиеся данные. По мере сбора транзакций суммарные значения меняются очень быстро, поэтому два анализа, проведенные с интервалом в несколько минут, могут дать разные результаты. Чаще всего, анализ выполнятся по окончании отчетного периода, иначе картина может оказаться искаженной. Кроме того, необходимые для анализа данные могут храниться в нескольких системах.

Некоторые виды анализа требуют таких структурных изменений, которые недопустимы в текущей оперативной среде. Например, нужно выяснить, что произойдет, если у компании появятся новые продукты. На "живой" базе такое исследование провести нельзя. Следовательно, эффективный анализ редко удается выполнить непосредственно в учетной системе.

Этим объясняется интерес к объединению и анализу данных учетной системы с помощью технологии OLAP (On-Line Analytical Processing - оперативная аналитическая обработка). Этот метод позволяет аналитикам, менеджерам и руководителям "проникнуть в суть" накопленных данных за счет быстрого и согласованного доступа к широкому спектру представлений информации. Исходные данные преобразуются таким образом, чтобы наглядно отразить структуру деятельности предприятия.

При этом конечному пользователю предоставляется ряд аналитических и навигационных функций:

расчеты и вычисления по нескольким измерениям, иерархиям и/или членам;

анализ трендов;

выборка подмножеств данных для просмотра на экране;

углубление в данные (drill down), для просмотра информации на более детализированном уровне;

переход к детальным данным, лежащим в основе анализа;

поворот таблицы отображаемых данных.

2.2 Сравнение архитектур

Как правило, учетные системы работают с реляционными базами данных. Для OLAP-приложений же разработана специальная многомерная модель, которая позволяет более эффективно использовать данные, накопленные в оперативных системах. Технология оперативной аналитической обработки ориентирована на представление данных в виде массивов. Под массивом понимается последовательность элементов, например продажи продукта по рынкам/временным периодам, или доход по времени/региону [3].

В концепции и терминологии OLAP есть много аналогий с реляционной моделью. В табл. 2.1 приведено сравнение реляционных терминов и понятий и соответствующих эквивалентов в OLAP.

Табл. 2.1 Сравнение реляционных и OLAP терминов и понятий

Необходимо отметить, что различия этих технологий существенны. В табл. 2.2 приведено сравнение системных характеристик OLTP и OLAP.

Табл. 2.2 Cравнение системных характеристик OLTP и OLAP

Совместное использование OLAP и учетной системы, в частности прямая настройка аналитических функций на OLTP-базу, осложняется несколькими факторами:

OLAP запросы к базам данных чаще всего бывают сложными и требуют много времени. Прямой доступ к OLTP-базе существенно снижает общую производительность оперативной системы.

Разнообразные учетные системы неоднородны по типу используемых синтаксических соглашений и концептуальных допущений (единицы измерений, онтологии, наименование, кодирование и т.п.), поэтому их интеграция затруднена.

Данные в учетных системах часто "зашумленные", неполные и несогласованные.

Как правило, нет единой модели данных масштаба предприятия. Кроме того, при проектировании баз учетной системы могут использоваться разные модели данных (иерархическая, реляционная, объектно-ориентированная, плоские файлы, "фирменные" модели).

В оперативных системах отсутствует метод предоставления данных для конкретных групп пользователей в нужной для них форме.

Информация за прошлые периоды теряется при обновлении OLTP- базы (при записи в нее новых, актуальных данных). Это препятствует выполнению анализа временных тенденций, который так важен для многих сфер бизнеса.

В OLTP-базе не хранятся данные в агрегированном, денормализованном, виде, что необходимо для оперативной аналитической обработки. А преобразование данных в процессе выполнения запросов оказывается слишком трудоемким.

Кроме всех перечисленных выше концептуальных различий, существуют еще и технологические проблемы, которые необходимо преодолеть для внедрения аналитических возможностей в учетные системы. Среди них можно назвать следующие сложности: различие в аппаратных платформах (компьютерах, сетях и периферийных устройствах), использование разного программного обеспечения (разнообразных операционных систем, СУБД, языков программирования, протоколов, связующего ПО и т.п.), а также географическое распределение баз данных по всей организации и вне ее.

2.3 Обоснование выбранной архитектуры

Процесс интегрирования OLAP-технологии с учетными системами может осуществляться по-разному. Все подходы имеют свои преимущества и недостатки. Как уже было сказано выше, прямая настройка аналитических средств (Direct BI) затруднена. Возможно также создание дублированных баз данных, витрин и Хранилищ данных. Практически всегда возникает необходимость в преобразовании операционных данных в аналитические. Для создания многомерного представления, нужно настроить данные так, чтобы они соответствовали логической многомерной структуре, далекой от структуры учетной системы. Например, многие измерения, используемые для анализа, могут вообще не иметь соответствий в учетных системах и извлекаться из других источников [4].

Требования к современным приложениям для обработки транзакций - работа в разветвленных сетях. Обслуживание тысяч клиентов при обеспечении высокой производительности выполнения операций, совместимость с Интернет - превосходят возможности реляционной технологии баз данных. Приложения, смоделированные как объекты, не могут без дополнительных преобразований храниться в реляционных СУБД, так как последние оперируют лишь плоскими нормализованными таблицами. Зачастую эти издержки берет на себя сама СУБД, если она является объектно-реляционной. Но проблема реляционной декомпозиции сложных объектов на их составляющие остается.

Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства:

В случае использования многомерных СУБД поиск и выборка данных осуществляется значительно быстрее, чем при многомерном концептуальном взгляде на реляционную базу данных, так как многомерная база данных денормализована, содержит заранее агрегированные показатели и обеспечивает оптимизированный доступ к запрашиваемым ячейкам.

Многомерные СУБД легко справляются с задачами включения в информационную модель разнообразных встроенных функций, тогда как объективно существующие ограничения языка SQL делают выполнение этих задач на основе реляционных СУБД достаточно сложным, а иногда и невозможным.

Таким образом, объектно-ориентированной подход позволяет упрощать системы сбора данных, и определяя объекты, подчинять им определённые типы информации. Разработка системы сбора и систематизация хранимой информации позволяет использовать различные современные технологии обработки и анализа данных.

3. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ БД И ОРГАНИЗАЦИИ ИНФОРМАЦИОННОГО ОБМЕНА

3.1 Технологические возможности сбора и хранения данных в ФОМС

Общие правила обмена информацией между отделениями Пенсионного фонда Российской Федерации (далее - ОПФР) и территориальными фондами обязательного медицинского страхования (далее - ТФОМС) в целях реализации конституционных прав граждан отдельных категорий, имеющих право на получение государственной социальной помощи (далее - ГСП) в виде набора социальных услуг и предоставление дополнительного лекарственного обеспечения, в случаях отсутствия сведений о гражданах в региональном сегменте Федерального регистра, в том числе о гражданах, временно прибывших с территории других субъектов Российской Федерации, где они зарегистрированы как получатели ГСП.

1. Основные процедуры обмена информацией осуществляются с учетом федерального регистра лиц, имеющих право на ГСП (далее - Федеральный регистр), на уровне ОПФР и ТФОМС с подключением, в случае необходимости, районных управлений ПФР и филиалов территориальных фондов ОМС.

2. Территориальные фонды ОМС по результатам проведения медико-экономической экспертизы счетов и реестров, переданных фармацевтическими организациями, направляют запрос в ОПФР по установленной форме на бумажном носителе и файл с перечнем лиц, указанных в запросе, в формате, утвержденном в действующей редакции настоящего Порядка, с целью подтверждения факта права на получение гражданами ГСП в виде набора социальных услуг в соответствии со ст. 6.2. п. 1 пп. 1 Федерального закона от 22.08.2004 N 122-ФЗ, в следующих случаях:

- полного отсутствия сведений о гражданине, зарегистрированном на территории данного субъекта в региональном сегменте Федерального регистра;

- полного отсутствия сведений о СНИЛС гражданина;

- прибытие гражданина с территории другого субъекта Российской Федерации.

Срок оформления запроса по установленной форме - не более 10 календарных дней с момента завершения медико-экономической экспертизы. Форма запроса и формат файла приведены в Приложении N 1.

3. Отделения Пенсионного фонда Российской Федерации:

- проводят идентификацию сведений о гражданах, указанных в запросах с данными Федерального регистра;

- направляют в ТФОМС ответ на запрос, подписанный уполномоченным сотрудником ОПФР, и файл с данными на граждан, указанных в запросе по установленной форме, в формате, утвержденном в действующей редакции "Порядка обмена информацией между отделениями Пенсионного фонда Российской Федерации и территориальными фондами обязательного медицинского страхования в ходе реализации Федерального закона от 22.08.2004 N 122-ФЗ "О внесении изменений в законодательные акты Российской Федерации и признании утратившими силу некоторых законодательных актов Российской Федерации в связи с принятием Федеральных законов "О внесении изменений и дополнений в Федеральный закон "Об общих принципах организации законодательных (представительных) и исполнительных органов государственной власти субъектов Российской Федерации" и "Об общих принципах организации местного самоуправления в Российской Федерации" (Приложение N 2). Срок обработки запроса и передачи в ТФОМС ответа не более 10 дней с момента поступления запроса.

4. После получения ответа на запрос от ОПФР территориальные фонды ОМС:

- проводят повторную медико-экономическую экспертизу данных счетов и реестров и возмещают фармацевтическим организациям затраченные средства;

- готовят и передают (отдельными файлами) сведения о суммарных фактических показателях объемов и стоимости медицинской помощи по программе ОМС и дополнительном лекарственном обеспечении, предоставленных указанным гражданам, в ОПФР, в соответствии с форматами, указанными в действующей редакции "Порядка обмена информацией между отделениями Пенсионного фонда Российской Федерации и территориальными фондами обязательного медицинского страхования в ходе реализации Федерального закона от 22.08.2004 N 122-ФЗ "О внесении изменений в законодательные акты Российской Федерации и признании утратившими силу некоторых законодательных актов Российской Федерации в связи с принятием Федеральных законов "О внесении изменений и дополнений в Федеральный закон "Об общих принципах организации законодательных (представительных) и исполнительных органов государственной власти субъектов Российской Федерации" и "Об общих принципах организации местного самоуправления в Российской Федерации".

5. В случае необходимости процедуры, изложенные в п.п. 2 и 3, повторяются до полного уточнения сведений о гражданах.

6. Обеспечение защиты информации при обмене данными между органами ПФР и территориальными фондами ОМС осуществляется с использованием средств защиты и электронной цифровой подписи, принятых в ПФР.

3.2 Использование каналов связи

Передача данных регистров и реестров осуществляется одним пакетом в виде архивированного ZIP-, RAR- или ARJ-файла. Состав файлов в пакете соответствует виду регистра или реестра.

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

При передаче пакета данных без использования средств электронной цифровой подписи (ЭЦП) передача пакета файлов сопровождается бумажным документом - паспортом пакета файлов, - заверенным печатью и подписью должностного лица. В паспорте указывается контрольная сумма пакета, рассчитанная по алгоритму CRC32.

ЛПУ передает в ТФОМС информационную посылку, содержащую три файла (П, М, Р). ФО передает в ТФОМС информационную посылку, содержащую два файла (П и Л), отдельно - по гражданам, зарегистрированным на территории данного субъекта Российской Федерации, и отдельно - по гражданам, временно прибывшим с территорий других субъектов Российской Федерации. ТФОМС передает в ФО информационную посылку, содержащую два файла (П и ОЛ), отдельно - по гражданам, зарегистрированным на территории данного субъекта Российской Федерации, и отдельно - по гражданам, временно прибывшим с территорий других субъектов Российской Федерации.

По результатам приема-передачи пакета данных формируется протокол синтаксического контроля, представляемый в виде DBF-файла следующего формата:

Таблица ПРОТОКОЛ СИНТАКСИЧЕСКОГО КОНТРОЛЯ

Протокол синтаксического контроля пересылается субъекту, представившему пакет данных. После исправления ошибок допускается повторное представление соответствующей части пакета данных. Сроки обработки определяются графиком обмена данными.

4. БЕЗОПАСНОСТЬ И ЭКОЛОГИЧНОСТЬ ПРОЕКТА

При ведении различных видов разработок должны рассматриваться вопросы безопасности и безвредности труда, оцениваться степень риска, связанная с вероятностью появления крупных ошибок, которые могут привести к краху всего проекта [10, 11].

В данном дипломном проекте разрабатывается функциональная модель ФОМС. Разработанная модель в последствии будет являться основой для создания базы данных путем автоматической генерации кода базы данных и вынесения рекомендаций по использованию модели обработки и хранения данных используемых в ФОМС.

4.1 Анализ трудового процесса создания функциональной модели ФОМС

При разработке информационная система сбора и обработки данных дистанционного зондирования Земли были пройдены следующие этапы:

· Подготовка к предпроектному обследованию ФОМС;

· Проведение сбора материалов;

· Обработка и систематизация полученной информации;

· Построение организационной модели;

· Анализ информационных и функциональных связей в модели.

Особенностью первого этапа является подготовка материалов для опросов: составление анкет, реестров фиксирующих документооборот, рекомендаций по заполнению и правила сдачи заполненных документов. Таким образом, от разработчиков это потребует сосредоточенности и тщательного обдумывания своей деятельности. На втором этапе потребуется внимание, терпение для общения со специалистами предметной области, объяснению целей опросов и правил заполнения опросных материалов. Приложив физические силы на третьем этапе, собирается вся заполненная документация и систематизируется путем занесения в базу данных всей полученной информации. Четвертый этап потребует аналитического мышления и умственной нагрузки для построения модели, используя инструментарий автоматизированного проектирования и принятия неординарных технических решений, требующих творческого подхода. Автоматизация проектирования имеет свои огромные преимущества, однако здесь не следует упускать вредные факторы, воздействующие на разработчика. Особая концентрация внимания необходима для анализа и вынесения рекомендаций по автоматизации на предприятии. На каждом этапе для ускорения выполняемых работ используются вычислительные машины (ЭВМ, ПЭВМ), в состав которых входят видеодисплейные терминалы (ВДТ). Таким образом, с одной стороны необходимо минимизировать отрицательное влияние проектной деятельности на разработчика, и с другой стороны обеспечить безопасную работу с вычислительными устройствами.

Несоблюдение гигиенических норм и правил на рабочем месте может привести к возникновению умственного переутомления, нервного возбуждения и как следствие снижения работоспособности. К этому могут привести такие характеристики трудового процесса, как значимость работы, ответственность за конечный результат, а также факторы монотонности труда: число элементов и продолжительность простых заданий и повторяющихся операций, число объектов наблюдения и другие. Для продуктивной работы разработчику необходимы: правильный режим питания, режим дня, режим труда и отдыха, правильная организация рабочего места.

4.2 Анализ этапов разработки и получение некоторых количественных характеристик трудового процесса

Оценим те вредные факторы, которым подвергается разработчик в процессе разработки модели и эксплуатации комплекса программно-аппаратных средств [10].

В процессе анализа мы будем опираться на руководство - «Гигиенические критерии оценки условий труда по показателям вредности и опасности факторов производственной среды, тяжести и напряженности трудового процесса», утвержденные Госкомсанэпиднадзором РФ Руководство- Р 2.2.755-99. По нему труд классифицируется по четырем классам: оптимальные условия труда (класс 1.0); допустимые условия труда (класс 2.0); вредные условия труда (класс 3). Вредные условия труда по степени превышения гигиенических нормативов и выраженности изменении в организме работающих, подразделяются на 4 степени вредности: 1 степень 3 класса (3.1); 2 степень 3 класса (3.2); 3 степень 3 класса (3.3); 4 степень 3 класса (3.4). Опасные (экстремальные) условия труда (класс 4.0).

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

Оценивать напряженность труда предлагается по двадцати одному предложенному фактору, каждому выбранному фактору даётся оценка от 1.0 до 3.2, а затем по предложенному алгоритму производится расчёт общей напряжённости труда. Результаты оценок 3 класса воздействующих факторов приведены в табл. 5.1.

Табл. 5.1. Воздействующие факторы

4.3 Разработка мероприятий, снижающих воздействие выявленных вредных факторов. Анализ опасности на этапе проектирования, п остроение «дерева опасностей»

В результате подсчёта общей напряжённости труда она равняется 3.1 единиц. Число факторов с оценкой 1.0 составило 7, с оценкой 2.0 составило 5, с оценкой 3.1 составило 8 и с оценкой 3.2 составило 1. Данный показатель характеризует в целом уровень вредности условий труда и указывает на то, что если не прибегать к организационным мероприятиям по снижению влияния вредных факторов на организм разработчика, у него могут развиться профзаболевания [11].