Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Разработка программной системы для автоматизации информационного обмена между страховыми медицинскими организациями

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

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 20.07.2014
Размер файла 1,4 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Страница:

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Содержание

  • Сокращения и обозначения
  • Введение
  • 1. Анализ предметной области и постановка задачи
  • 1.1 Описание структуры и направление деятельности организации
  • 1.2 Описание объекта автоматизации
  • 1.3 Обзор существующих аналогов
  • 1.4 Изучение правил информационного взаимодействия
  • 1.4.1 Принципы построения и правила модификации информации в ОБ
  • 1.4.2 Информационные пакеты для работы с ОБД
  • 1.4.3 Транспортная таблица TRANS
  • 1.5 Формулировка общих и специальных требований к системе
  • 1.6 Выбор инструментальных средств разработки
  • 1.7 Декомпозиция системы
  • 1.8 Построение концептуальной модели данных
  • 2. Разработка структур данных и программного обеспечения
  • 2.1 Построение физической модели данных
  • 2.2 Разработка алгоритмов
  • 2.3 Разработка интерфейса пользователя, экранных форм и отчетов
  • 2.4 Разработка процедур и функций приложения
  • 3. Технико-экономическое обоснование разработки ПО
  • 3.1 Расчет затрат на разработку ПО
  • 3.2 Расчет цена разработанной программы
  • 3.3 Расчет капитальных вложений
  • 3.4 Расчет эксплуатационных расходов
  • 3.5 Расчет денежного годового экономического эффекта
  • 3.6 Определение показателей эффективности инвестиций
  • 3.7 Выводы
  • 4. Охрана труда
  • 4.1 Выявление явных и потенциально опасных вредных производственных факторов
  • 4.1.1 Излучение электромагнитных полей
  • 4.1.2 Шум
  • 4.1.3 Микроклимат
  • 4.1.4 Электробезопасность
  • 4.1.5 Освещенность
  • 4.1.6 Пожарная безопасность
  • 4.1.7 Организация рабочего места
  • 4.2 Мероприятия по устранению опасных и вредных производственных факторов
  • Заключение
  • Приложения
  • Сокращения и обозначения
  • БД - база данных.
  • ЕМСР - единый медико-социальный регистр.
  • ЛПУ - лечебно-профилактическое учреждение.
  • ЛПУ ПМСП - лечебно-профилактическое учреждение первичной медико-санитарной помощи.
  • ОМС - обязательное медицинское страхование.
  • ПО - программное обеспечение.
  • СМО - страховая медицинская организация.
  • ТФОМС - территориальный фонд обязательного медицинского страхования.
  • ФИО - фамилия имя отчество.
  • ЛБД - локальная база данных.
  • ОБД - областная база данных.
  • АИС - автоматизированная информационная система.
  • программа страховой медицинский интерфейс
  • Введение
  • С 1993 года в Самарской области было введено обязательное медицинское страхование и создан Территориальный фонд обязательного медицинского страхования, который является основной государственной структурой области, аккумулирующей финансовые средства ОМС, выделяемые на оказание бесплатных медицинских услуг.
  • Финансирование лечебно-профилактических учреждений, оказывающих медицинские услуги в рамках ОМС, осуществляется ТФОМС через страховые медицинские организации.
  • В соответствии с Законом о медицинском страховании и Правилами ОМС населения Самарской области застрахованным считается гражданин, в отношении которого заключен договор между работодателем (страхователем) и страховой компанией (страховщиком), а самому гражданину выдан полис ОМС.
  • Все население Самарской области делится на две категории:
  • - работающие, страхователем является работодатель;
  • - неработающие, страхователем является Администрация Самарской области.
  • Лечебно-профилактическое учреждение при обращении застрахованного за медицинской помощью обязано оказать бесплатно данную помощь в рамках программы ОМС при предъявлении полиса ОМС. При этом в обязанности ЛПУ не входит проверка достоверности данного полиса или действия договора страхования.
  • Таким образом, проблемы, возникающие с действием договора страхования или полиса гражданина, не касаются ни медицинской организации, ни самого гражданина, а являются предметом разбирательства только трех субъектов: страхователя, страховщика и, в крайнем случае, фонда ОМС как контролирующей организации.
  • К данному вопросу тесно примыкает процесс формирования и ведения областной базы данных застрахованных - Единый Медико-Страховой Регистр. ОБД предназначена для формирования плана финансирования страховой медицинской организации и для определения плательщика за оказанные медицинские услуги.
  • Формирование ОБД является результатом информационного взаимодействия между СМО и ТФОМС, которое призвано обеспечить актуальное состояние ЕМСР, то есть достоверность сведений о застрахованном, без какого-либо ущемления прав граждан в системе ОМС.
  • От того насколько оперативно и эффективно осуществляется этот процесс, зависит главный показатель работы СМО - количество финансируемых застрахованных в текущем квартале, а, следовательно, и сумма выделяемых денежных средств.
  • Поэтому целью разработки данной системы является создание инструмента информационного взаимодействия между СМО и ТФОМС, который позволит добиться высоких результатов в данном вопросе.
  • 1 Анализ предметной области и постановка задачи
  • 1.1 Описание структуры и направление деятельности организации
  • Страховые медицинские организации - юридические лица, осуществляющие медицинское страхование и имеющие государственное разрешение (лицензию) на право заниматься медицинским страхованием.
  • В настоящее время на территории Самарской области медицинским страхованием занимается 7 компаний. Каждая СМО осуществляет свою деятельность на закрепленной территории и обслуживает конкретную категорию граждан.
  • Организационная структура страховой компании представлена на рисунке 1.1.
  • Рисунок 1.1 - Организационная структура страховой медицинской организации
  • Деятельность страховой медицинской организации направлена на решение следующих задач:
  • выдача полисов ОМС;
  • прием и обработка счетов за оказанные медицинские услуги;
  • защита прав застрахованных;
  • проведение экспертизы медицинской помощи;
  • оказание консультационной помощи по бесплатной горячей телефонной линии;
  • поддержание в актуальном и корректном состоянии информации о застрахованных в ЕМСР и другие.
  • Из вышеперечисленных задач, приоритетной является выдача полиса ОМС. Эта процедура осуществляется следующим образом.
  • Если гражданин имеет категорию неработающего, то есть страхователем является Администрация Самарской области, то в соответствии со своей территорией проживания, он обращается в страховую компанию с определенным набором документов. Как правило, это документ, удостоверяющий личность (паспорт, свидетельство о рождении, временное удостоверение личности и др.), трудовая книжка или справка с центра занятости.
  • Если категория - работающий, то в данном случае, страхователем является работодатель, который заключает договор страхования со страховой компанией и предоставляет ей списки сотрудников, в которых указаны необходимые данные для выдачи полиса ОМС. Полис действует в рамках срока действия договора или до момента увольнения сотрудника.
  • Оператор после предъявления необходимой информации проверяет наличие потенциального застрахованного в ЕМСР. Затем в случае положительного принятия решения, информация вносится в базу данных, а застрахованному выдается полис ОМС, под роспись в журнале выдачи полисов.
  • Итак, полис ОМС выдан, но кроме его наличия, не менее важным является, то какое ЛПУ будет оказывать медицинскую помощь застрахованному и соответственно, куда будет перечисляться оплата по выставленным счетам. По умолчанию, при выдаче полиса, застрахованного прикрепляют к лечебному учреждению, по его территории проживания. Если же гражданин хочет обслуживаться другим ЛПУ, то для этого ему необходимо написать там заявление на прикрепление, после чего данное лечебное учреждение передает это заявление в страховую компанию, которая изменяет прикрепление в БД по умолчанию, на основании заявления.
  • Таким образом, формируется накопительная локальная база данных застрахованных страховой медицинской компании.
  • За оказание медицинских услуг, ЛПУ направляют в СМО счета на оплату. Страховая компания на основе ЛБД застрахованных определяет плательщика и принимает счет на оплату.
  • 1.2 Описание объекта автоматизации
  • Каждая страховая медицинская организация, как уже отмечалось выше, ведет локальную базу данных своих застрахованных.
  • Сведения о застрахованном в БД описываются следующими информационными сегментами:
  • ЕИН - единый идентификационный номер в ОБД;
  • персональные данные (ФИО, пол, дата рождения, документ, адрес);
  • данные о страховании (полис, договор, страхователь, СМО);
  • данные о прикреплении (базовое ЛПУ, стоматологическое ЛПУ).
  • Эта информация по мере изменения должна соответственно обновляться и в ЕМСР, то есть должна существовать синхронизация ЛБД с ОБД. Этот процесс называется информационным обменом и показан на рисунке 1.2.
  • Рисунок 1.2 - Схема информационного обмена
  • Для выполнения этой задачи, СМО реализуется следующая последовательность действий:
  • из ЛБД выбираются данные о застрахованных, по которым произошли изменения, в каком-либо информационном сегменте;
  • выборка анализируется и на основании ее формируется запрос, отсылаемый по электронной почте. Запрос оформляется в виде таблицы формата DBF III, которая заполняется в соответствии с правилами информационного взаимодействия, и упаковывается архиватором в информационный пакет с паролем;
  • затем в течение двух дней, в зависимости от вида запроса, приходит ответ, также в виде информационного пакета по электронной почте;
  • ответ обрабатывается, и далее в зависимости от полученного результата, выбирается дальнейшая стратегия действий:
  • - ошибки передаются на выверку и исправление в отдел страховой деятельности (ОМС);
  • - посылаются на другие виды запросов;
  • - на основе результата, обновляется информация в ЛБД.
  • Этот процесс является достаточно трудоемким и должен осуществляться непрерывно. Именно от оперативности и качественного анализа данных, зависит актуальность и корректность сведений о застрахованном в ЕМСР, а соответственно финансирование его полиса в следующем квартале и гарантированное получение им медицинской помощи, по месту прикрепления.
  • Поэтому необходимо разработать систему информационного обмена, которая осуществляла бы следующие основные функции:
  • - своевременное отслеживание изменений в ЛБД;
  • - отсылку их на соответствующий запрос;
  • - получение ответа и его обработка;
  • - обновление ЛБД, в соответствии с результатом обработки.
  • 1.3 Обзор существующих аналогов
  • В настоящее время на территории Самарской области можно выделить два наиболее крупных разработчика программного обеспечения для медицинских учреждений:
  • МИАЦ - медицинский информационно-аналитический центр;
  • ИМЦ - информационный медицинский центр.
  • МИАЦ - государственное учреждение, подчиняющееся министерству здравоохранения и социального развития Самарской области. Помимо разработки ПО МИАЦ координирует информационное взаимодействие медицинских организаций.
  • ООО ИМЦ создано в 2000 году на базе отдела информационных систем самарской компании «ПАРУС». Специалисты, работающие в компании, с 1991 года специализируются на разработке и внедрении программного обеспечения и информационном обслуживании медицинских учреждений, включая развитие всей сопутствующей технической инфраструктуры, сопровождение, модернизацию и распространение программ, обучение и консалтинг пользователей.
  • Программные средства, разрабатываемые сотрудниками МИАЦ, направлены в основном на автоматизацию службы медицинской статистики Самарской области, но дополнительно решают и другие проблемы как лечебно - профилактических учреждений, так и органов управления ими.
  • Информационный медицинский центр занимается также созданием ПО для страховых медицинских организаций, являясь фактически монополистом в этой сфере. В частности в 2004 году ими была разработана информационная система АИС «ОМС», которая в настоящее время используется некоторыми СМО.
  • Данный программный продукт предназначен для автоматизации страховой деятельности СМО в системе ОМС, который позволяет вести базу данных застрахованных и заключенных договоров страхования, использовать эту информацию для определения плательщика за оказанные медицинские услуги, выдавать застрахованному гражданину полис ОМС.
  • Функциональные возможности системы:
  • организация комплексного учета основных этапов медицинского страхования гражданина;
  • пакетная обработка информации о застрахованных, получаемая в процессе информационного обмена;
  • учет заключенных договоров страхования;
  • ведение истории изменений данных по каждому застрахованному.
  • Пакетная обработка является одной из наиболее важных функций, обеспечивающих информационное взаимодействие с ОБД. Она имеет преимущества и ряд существенных недостатков.
  • Преимуществом системы является то, что функционально она входит в состав программного комплекса АИС «ОМС» как один из его модулей. Это позволяет использовать единый программный продукт для реализации всех функций в отношении информации о застрахованных в рамках ЕМСР.
  • Недостатки:
  • блокировка записи на срок до момента получения ответа на запрос;
  • отсутствие анализа полученных ответов;
  • отсутствие возможности автоматического отслеживания изменения информации о застрахованных и отсылки соответствующих данных в ОБД;
  • несоответствие текущим требованиям нормативных документов.
  • Таким образом, очевидно, что функционал АИС «ОМС» по обмену информации с ОБД является недостаточным для эффективной организации деятельности СМО. Из этого следует необходимость в разработке новой системы, которая будет лишена указанных выше недостатков.
  • 1.4 Изучение правил информационного взаимодействия
  • Страховые медицинские организации, также как и Территориальный фонд обязательного медицинского страхования, являются субъектами информационного взаимодействия, которое регулируется нормативным документом - «Положение о порядке информационного взаимодействия в системе обязательного медицинского страхования на территории Самарской области (Версия 8.0)».
  • Информационное взаимодействие заключается в обмене данными о застрахованном, с накопительной областной базой.
  • Для описания информации о застрахованных в системе ОМС, используются следующие понятия.
  • Объект учета - человек, проживающий на территории Самарской области.
  • Запись - сведения об объекте учета за определённый временной интервал, содержащиеся в накопительной таблице ОБД.
  • Владелец объекта - субъект ОМС, с которым у человека имеются юридические взаимоотношения (СМО, которой застрахован человек).

1.4.1 Принципы построения и правила модификации информации в ОБД

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

Каждая запись в накопительной базе данных ЕМСР имеет единый уникальный идентификационный номер - ЕИН.

Работа с ОБД строится по следующему сценарию: субъект информационного взаимодействия отправляет запрос в ЕМСР. ЕМСР после обработки запроса возвращает его результат. Запросом является требование на просмотр, добавление или модификацию информации в ОБД, построенное по определенному формату.

Операции, проводимые в ОБД следующие:

модификация данных.

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

регистрация нового объекта.

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

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

удаление объекта.

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

- по запросу от «владельца» объекта;

- по запросу ТФОМС;

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

процедура согласования.

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

Согласование может быть двух типов:

- «явное» согласование обуславливается ситуацией, когда вносимые изменения приводят к смене владельца объекта (т.е. меняются значения полей «код СМО» или «код ЛПУ ПМСП прикрепления») и при этом входящая информация однозначно находится в ОБД и не входит в конфликты с другими записями по дополнительным уникальным ключам;

- «неявное» согласование вызывается ситуацией, когда владелец объекта учета не меняется, но внесение изменений вызывает нарушение уникальности хотя бы одного уникального ключа ОБД.

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

1.4.2 Информационные пакеты для работы с ОБД

Информационный пакет - это защищенный паролем, архивный файл типа ZIP, в котором содержится фрагмент базы данных в виде набора взаимосвязанных таблиц формата DBF III (dBASE RUS cp866).

Формат имени информационного пакета имеет следующий вид:

NNNNNSSK.YMD, где:

NNNNN - код учреждения - отправителя информационного пакета;

SS - суффикс информационного пакета, (код пакета), определяет тип информационного пакета.

K - Символ, являющийся числом в системе счисления по основанию 32, означающий порядковый номер информационного пакета от данного учреждения за текущие сутки; Расширение файла YMD представляет собой дату формирования пакета в свернутом формате. Здесь Y - последняя цифра номера года; M - месяц в шестнадцатеричной системе счисления (для месяцев с января по декабрь - соответственно 1, 2, 3, 4, 5, 6, 7, 8, 9, A(10), B(11), C(12)); D - число месяца в системе счисления по основанию 32 (для чисел с 1 по 31 - соответственно 1, 2, 3, 4, 5, 6, 7, 8, 9, A(10), B(11), C(12), D(13), E(14), F(15), G(16), H(17), I(18), J(19), K(20), L(21), M(22), N(23), O(24), P(25), Q(26), R(27), S(28), T(29), U(30), V(31)).

За один день учреждением в адрес одного получателя может быть сформирован только 1 пакет с одним именем.

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

Таблица 1.1 - Типы информационных пакетов

№ п/п

Код

Комментарий

Отправитель

Получатель

Сроки передачи

1.

QR

Данные по страхованию

СМО

ТФОМС

По мере необходимости

2.

RQ

Результат обработки данных по страхованию в ТФОМС

ТФОМС

СМО

Через 2 дня с момента получения пакета, содержащего данные по страхованию

При пересылке пакета по электронной почте в теме письма необходимо указать строку «Data_for_UMSR».

Информационный пакет внутри себя содержит таблицу TRANS.

1.4.3 Транспортная таблица TRANS

Описание передаваемого запроса представляет собой запись в таблице TRANS, ее структура представлена в таблице 1.2.

Таблица 1.2 - Структура транспортной таблицы TRANS

№ п/п

Имя поля

Расшифровка

Тип

Длина

1

ЕIN

Единый идентификационный номер (ЕИН)

Character

16

2

SURNAME

Фамилия

Character

24

3

NAME

Имя

Character

16

4

SECNAME

Отчество

Character

16

5

NDOC

Номер документа

Numeric

7

6

NSDOC

Номер серии документа

Numeric

2

7

SDOC

Серия документа

Character

2

8

DOCTYPE

Тип документа

Numeric

1

9

DOCDATE

Дата выдачи документа

Date

8

10

DOCEMISS

Код подразделения УВД, выдавшего документ

Character

10

11

NPOLIS

Номер бланка страхового полиса ОМС

Numeric

8

12

SPOLIS

Серия бланка страхового полиса ОМС

Character

5

13

INSURER

Код СМО

Numeric

5

14

AGRNUM

Номер договора (ссылка на договор страхования PRED)

Numeric

6

15

BIRTHDAY

Дата рождения

Date

8

16

RGN1

Код города или сельского района

Numeric

3

17

RGN2

Гор.,район,поселок или сельсовет

Numeric

3

18

RGN3

Населенный пункт

Numeric

3

19

STREET

Улица (заполняется из Streets)

Numeric

4

20

HOUSE

Номер дома

Numeric

4

21

HOUSEEDGE

Второй № дома, если дом - угловой

Numeric

4

22

HOUSELITER

Литера дома

Character

1

23

CORPUS

Корпус

Numeric

2

24

FLAT

Квартира

Numeric

4

25

FLATLITER

Литера квартиры

Character

1

26

LPUBASE

Код ЛПУ ПМСП прикрепления (заполняется из LPU)

Numeric

5

27

LPUBASE_U

Номер участка в LPUBASE

Numeric

3

28

LPUDENT

Код стоматологического ЛПУ прикрепления (заполняется из LPU)

Numeric

5

29

LOCAL

Признак регистрации прописки

Numeric

1

30

SEX

Пол

Numeric

1

31

KLADRST

Код территории проживания по КЛАДР, детализированный до уровня улицы для жителей иных областей

Character

17

32

FINSTAT

Страхователь: 1 - работодатель 2 - Правительство Самарской области за неработающее население

Numeric

1

33

POLISDATE

Дата выдачи полиса ОМС, используется для Silence

Date

8

34

REASONBASE

Причина смены ЛПУ ПМСП прикрепления

Numeric

1

35

REASONDENT

Причина смены стоматологического ЛПУ ПМСП прикрепления

Numeric

1

36

PENSION

Идентификатор пенсионного фонда

Character

14

37

REMSTAT

Признак окончания действия записи

Numeric

1

38

EIN REF

ЕИН оригинала (для «двойника»)

Character

16

39

BEGDATE

Дата регистрации объекта

Date

8

40

ENDDATE

Конец периода действия записи

Date

8

41

MODDATE

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

Date

8

42

SMOFIN

СМО, на которую производится финансирование квартала с FinDate (заполняется из справочника smo)

Numeric

5

43

BEGFIN

Дата начала квартала финансирования для СМО

Date

8

44

ENDFIN

Дата окончания финансирования

Date

8

45

INSTAT

Статус согласования записи

Numeric

1

46

AUTHORSTAT

Автор изменения статуса (пользователь или ЕМСР (Silence))

Numeric

1

47

LDBL

Ветка логического дублирования

Character

16

48

IDQ

Идентификатор запроса системы (уникальная ссылка на процесс)

Character

10

49

IDQ_SBJ

Идентификатор запроса субъекта (уникальная ссылка на процесс)

Character

20

50

DATE_CH

Дата последнего изменения записи в локальной БД страховой компании

Date

8

51

DOCREASON

Дополнительная информация ТФОМС

Character

40

52

OPERDATE

Дата проведения операций

Date

8

53

NUMQ

Код запроса

Character

З

54

SILENCE

Признак действия по умолчанию

Numeric

1

55

SOURCETAB

Имя таблицы - источника

Character

8

56

MESSCODE

Код сообщения

Numeric

3

57

ERRCODE

Код ошибки

Numeric

3

Порядок заполнения полей таблицы TRANS зависит от вида запроса. Код запроса характеризуется значением поля NUMQ, возможные варианты его заполнения приведены ниже в таблице 1.3.

Таблица 1.3 - Значения поля NUMQ

Код запроса

Наименование запроса

Инициатор

Q01

Определение ЕИН

ЛПУ, СМО

Q02

Получение информации об объекте

ЛПУ, СМО

Q03

Регистрация объекта в ЕМСР

СМО

Q04

Изменение данных в ЕМСР (прикрепление застрахованного к СМО или ЛПУ ПМСП, изменение предметной информации о человеке)

СМО

Q05

Изменение статуса в данных, участвующих в согласовании (подтверждение изменений, апелляция, снятие запроса на изменение - отмена согласования)

СМО

Q08

Удаление объекта из ЕМСР

СМО, ТФОМС

Q09

Восстановление объекта в ЕМСР

СМО, ТФОМС

Поле EIN единый идентификационный номер жителя, проживающего на территории Самарской области.

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

Поле MODDATE - дата внесения информации в ОБД. Генерируется ЕМСР и фактически является началом периода действия записи.

Поле OPERDATE - дата проведения операции или дата последней корректировки персональной информации.

Поле INSTAT определяет статус согласования. Может принимать следующие значения, перечисленные в таблице 1.4.

Таблица 1.4 - Значения поля INSTAT

Код

Расшифровка

0

исходящая запись с ошибками

1

входящая запись (заявка на согласование)

2

запись находится на согласовании

3

заявлена апелляция

4

подтверждение изменений

5

отмена изменений

6

силовое решение согласования

Значение поля AUTHORSTAT указаны в таблице 1.5.

Таблица 1.5 - Значения поля AUTHORSTAT

Код

Расшифровка

1

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

2

статус согласования был изменен ЕМСР по истечении срока

Поле LDBL хранит уникальные ключи, по которым запись была найдена в ЕМСР. Каждый символ данной строки - номер ветки логического дублирования в системе счисления по основанию 32.

Поле IDQ формируется в ЕМСР.

Поля LPUBASE, LPUDENT принимают значение 7001 для лиц, проживающих за пределами Самарской области (не заполнены поля RGN1,RGN2,RGN3, заполнено поле KLADRST).

Поле SILENCE описывает реакцию ЕМСР в случае завершения процесса согласования ЕМСР (если ни от одного участников процесса согласования не последовало реакции в установленный срок), значения поля представлены в таблице 1.6.

Таблица 1.6 - Значения поля SILENCE

Код

Расшифровка

1

по истечении отведенного срока изменения будут приняты

2

по истечении отведенного срока изменения будут отменены

Поле MessCode хранит ответ ЕМСР на запросы пользователей.

Допустимые значения полей перечислимого типа указаны ниже в таблице 1.7.

Таблица 1.7 - Значения полей перечислимого типа

Наименование поля

Допустимые значения

DOCTYPE

1-паспорт; 2-свидетельство о рождении; 3- паспорт граждан, на которых не заполняются адресные данные (сотрудники правоохранительных органов); 4- документ, выданный иностранным гражданам (данные могут быть заполнены не полностью); 6- временное удостоверение личности 7- вид на жительство.

LOCAL

1-в таблице указан адрес регистрации постоянного жителя Самарской области; 2 - в таблице указан адрес проживания в Самарской области жителя, прописанного в другом регионе РФ.

SEX

1 - мужской; 2 - женский.

FINSTAT

1 - работодатель; 2 - областная администрация.

REASONBASE, REASONDENT

1 - по территории (по умолчанию); 2 - по заявлению.

REMSTAT

1 - умер; 2 - переехал в другой регион РФ; 3 - прекратил действие договор страхования; 4 - является двойником; 5 - действие записи прекращено по данным мониторинга ТФОМС.

Для всех записей таблицы TRANS, должны выполняться следующие требования:

- в запросе к ЕМСР должны быть сгенерированы уникальные значения поля IDQ_SBJ. Пустые значения и дублирование значений поля IDQ_SBJ внутри таблицы TRANS не допускается;

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

Порядок заполнения полей таблицы TRANS для запросов представлен в таблице 1.8.

Таблица 1.8 - Порядок заполнения транспортной таблицы для запросов

№ п/п

Код запроса

Порядок заполнения полей

1

Q01

Значение поля EIN должно быть пустое. Обязательными для заполнения являются поля,IDQ_SBJ и хотя бы одна из комбинаций полей, соответствующая уникальным комбинациям ОБД ЕМСР.

2

Q02

Обязательными для заполнения являются поля EIN и IDQ_SBJ значения остальных полей могут быть пустыми.

3

Q03

Обязательными для заполнения являются поля, Surname, Name, Birthday, Sex, Insurer, Npolis, Spolis, Lpubase, Lpudent, FinStat, PolisDate, Ndoc, Doctype, Birthday, IDQ_SBJ и хотя бы одно из полей Rgn1, Rgn2, Rgn3.

4

Q04

Набор полей, обязательных для заполнения в точности соответствует набору полей для запроса Q03 но кроме этого обязательно должно быть заполнено поле EIN. Поле REMSTAT может принимать значения 0,2,3.

5

Q05

Обязательными для заполнения являются поля ein, Insurer, InStat, IDQ, IDQ_Sbj, NumQ. Поле IDQ заполняется значением идентификатора процесса согласования, статус которого изменяется субъектом-участником процесса.

6

Q08

Обязательными для заполнения являются поля EIN, REMSTAT, IDQ_SBJ и в случае если REMSTAT = 4, поле EIN_REF.

7

Q09

Набор полей, обязательных для заполнения в точности соответствует набору полей для запроса Q03 но кроме этого обязательно должно быть заполнено поле EIN. Поле REMSTAT может принимать значения 1,4,5.

1.5 Формулировка общих и специальных требований к системе

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

Нормативным документом предусмотрено информационное взаимодействие, в рамках которого СМО обменивается данными о застрахованных с ЕМСР. Для этой цели необходимо оперативно отслеживать изменения информации о застрахованных в ЛБД, отправлять эти данные на запрос в ОБД и эффективно обрабатывать полученный ответ.

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

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

Назначение:

Система предназначена для сбора, отправки и обработки информации о застрахованных. Результаты обработки могут быть использованы в дальнейших действиях, направленных на актуализацию данных в ЕМСР и ЛБД.

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

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

- отслеживание изменений в данных о застрахованных в ЛБД;

- формирование информационного пакета с соответствующим запросом;

- регистрация исходящих и входящих пакетов в журнале;

- отправка и прием пакетов по электронной почте;

- обработка полученных ответов;

- обновление ЛБД в соответствии с результатом;

- ведение архива данных за каждый квартал;

- печать отчетов.

В качестве нормативной базы для реализации поставленных задач использовать «Положение о порядке информационного взаимодействия в системе обязательного медицинского страхования на территории Самарской области (Версия 8.0)».

Требования к информационному обеспечению:

- исходной информацией должны быть данные о застрахованных, хранящиеся в накопительной ЛБД страховой компании;

- обмен должен производиться посредством таблицы DBF III, входящей в состав информационного пакета специального формата, описанного в разделе 1.4.2. данной пояснительной записки.

Результаты:

- актуальная информация в ЕМСР, то есть успешный результат обработки;

- отчеты для выверки в ОМС данных отбракованных ЕМСР;

- обновление ЛБД;

- журнал регистрации пакетов;

- статистика по запросам.

Требования к надежности:

Обеспечить целостность хранимой информации.

Специальные требования:

- обеспечить возможность не только ручного, но и автоматического запуска некоторых задач системы;

- обеспечить возможность ручного просмотра и изменения результатов обработки.

Требования к составу и параметрам технических средств:

Система должна работать на ПЭВМ типа IBM.

Минимальная конфигурация:

- тип процессора - Pentium-совместимый;

- объем оперативного запоминающего устройства - не менее 512 Мб;

- сеть Internet;

- почтовый сервер.

Требования к информационной и программной совместимости:

- операционная система MS Windows 9X/NT/2000;

- пакет прикладных программ Office 2003;

- СУБД Visual FoxPro 9.0;

- почтовый клиент типа the Bat.

1.6 Выбор инструментальных средств разработки

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

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

Средством обмена информацией с ЕМСР служит пакет, состоящий из таблицы формата DBF III. Его поддерживают следующие средства разработки приложений:

- Microsoft Visual FoxPro;

- Delphi.

Delphi позволяет работать с различными форматами структур данных посредством механизма ODBC.

Для Visual FoxPro формат DBF III является родным. Кроме того имеет преимущество в цене.

Таким образом, для реализации данного проекта будем использовать систему управления базами данных (СУБД) и язык программирования Microsoft Visual FoxPro версии 9.0.

Visual FoxPro - это мощное средство для разработки настольных приложений, работающих с базами данных.

Его основными достоинствами являются:

удобный интерфейс разработчика;

простота базового языка;

мощный диалект SQL для эффективной работы с локальными и удаленными данными;

интеграция с остальными приложениями Microsoft Office с помощью OLE Automation;

поддержка технологии COM и возможностей, предоставляемых Windows API;

1.7 Декомпозиция системы

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

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

Таким образом, можно выделить два основных направления задач системы:

формирование запроса;

обработка запроса.

Процесс формирования запроса к ЕМСР, можно разбить на следующие подзадачи:

выборка данных из ЛБД.

Предполагается, что выборка будет двух видов:

- на первичный запрос;

- на последующий запрос;

формирование информационного пакета.

Для этой подзадачи необходимо сделать следующее:

- оформить запрос;

- присвоить имя пакету;

- зарегистрировать пакет в журнале;

отправка пакета.

Эта подзадача заключается в следующем:

- запаковке архиватором таблицы формата DBF III;

- отсылке готового пакета по электронной почте.

Обработка запроса состоит в следующем:

получение пакета.

Для этого необходимо:

- получить пакет из электронной почты;

- распаковать архиватором;

обработка запроса.

Состоит из:

- регистрации полученного пакета;

- анализа полученной в ответ информации;

- обновлении ЛБД.

Кроме того, техническим заданием предусмотрено, наличие следующих отчетных форм:

- ошибки;

- журнал регистрации.

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

Рисунок 1.3 - Диаграмма иерархии функций системы

Полученный набор функций целесообразно объединить в модули. Их спецификация представлена в таблице 1.9.

Таблица 1.9 - Спецификация модулей приложения

№ п/п

Модуль

Состав процедур и функций

Назначение модуля

1

Запрос

Выборка из ЛБД

Осуществляет запрос к ЕМСР

Оформление запроса

Присвоение имени пакету

Регистрация пакета

Запаковка архиватором

Отправка по почте

Получение из почты

Распаковка архиватором

2

Обработка

В зависимости от запроса анализ полученного ответа

Обрабатывает запрос на основании ответа

Обновление ЛБД

3

Отчеты

Формирование отчетных форм

Формирует отчеты на печать

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

1.8 Построение концептуальной модели данных

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

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

«Запросы» - информация, отправленная на запрос;

«Ответы» - информация, полученная в ответ.

Для отправки на первичный запрос, данные должны быть выбраны из ЛБД за интервал времени, который система должна хранить - сущность «Выборка».

Запрос отправляется в пакете. Каждый пакет имеет свое уникальное имя, в котором заложена следующая информация:

- тип пакета;

- дата формирования;

- порядковый номер.

Таким образом, формируются следующие сущности:

«Типы пакетов» - справочник типов возможных пакетов;

«Имя пакета» - данные для формирования имени: дата и номер.

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

Кроме того, одним из специальных требований к системе является возможность автоматического запуска некоторых задач. Для этого потребуется планировщик - сущность «Задачи» и его расписание - сущность «Расписание».

ЕМСР в ответе на запрос возвращает одно из следующих значений:

ошибку;

сообщение;

детальную ошибку.

Для хранения списка их значений, создадим сущности-справочники соответственно: «Ошибки», «Сообщения», «Детальные ошибки».

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

Итак, набор основных сущностей разрабатываемой системы, определен:

«Запросы»;

«Ответы»;

«Выборка»;

«Типы пакетов»;

«Имя пакета»;

«Пакеты»;

«Статистика»;

«Задачи»;

«Расписание»;

«Ошибки»;

«Сообщения»;

«Детальные ошибки»;

«Результаты»;

«Группы результатов».

Связи сущностей между собой, представлены ниже в таблице 1.10.

Таблица 1.10 - Взаимодействие сущностей

№ п/п

Сущность

Класс принадлежности

Расшифровка класса принадлежности

Тип связи

Расшифровка типа связи

1. «Запросы» - «Ответы»

«Запросы»

Обязательный

На каждый запрос всегда есть ответ

1:М

1 запрос имеет хотя бы 1 ответ

«Ответы»

Обязательный

На каждый ответ всегда есть запрос

1:1

1 ответ соответствует 1 запросу

Общий тип связи

1:М

2. «Пакеты» - «Запросы»

«Пакеты»

Обязательный

Каждый запрос входит в состав пакета

1:М

1 пакет содержит хотя бы 1 запрос

«Запросы»

Обязательный

Каждый пакет содержит запрос

1:1

1 запрос входит в состав 1 пакета

Общий тип связи

1:М

Аналогична связь пары сущностей «Пакеты» - «Ответы»

3. «Типы пакетов» - «Пакеты»

«Типы пакетов»

Обязательный

Пакеты могут быть только определенных типов

1:М

1 тип пакетов соответствует хотя бы 1 зарегистрированному пакету

«Пакеты»

Обязательный

Все типы пакетов участвуют в обмене

1:1

Пакет 1 типа соответствует 1 типу возможных типов пакетов

Общий тип связи

1:М

4. «Пакеты» - «Статистика»:

«Пакеты»

Обязательный

Статистика создается по каждому пакету

1:М

По 1 пакету можно составить статистику хотя бы по 1 запросу

«Статистика»

Обязательный

Каждый пакет имеет статистику по запросам

1:1

Статистика конкретного запроса принадлежит 1 пакету

Общий тип связи

1:М

5. «Задачи» - «Расписание»:

«Задачи»

Необязательный

Расписание может быть составлено не на все задачи

1:М

1 задача может запускаться несколько раз в день

«Расписание»

Необязательный

Не все задачи могут запускаться по расписанию

1:1

В конкретный момент может быть запущена только 1 задача

Общий тип связи

1:М

6. «Результаты» - «Запросы»:

«Результаты»

Необязательный

Запросы могут содержать не все результаты

1:М

1 результату соответствует несколько запросов

«Запросы»

Необязательный

Результат может не появиться в настоящий момент в запросе

1:1

1 запрос может содержать только 1 результат

Общий тип связи

1:М

7. «Группы результатов» - «Результаты»:

«Группы результатов»

Обязательный

Каждый результат входит в группу результатов

1:М

1 группа объединяет в себе несколько результатов

«Результаты»

Обязательный

Каждая группа содержит результаты

1:1

1 результат соответствует 1 конкретной группе

Общий тип связи

1:М

8. «Сообщения» - «Ответы»:

«Сообщения»

Необязательный

Не все ответы могут содержать сообщения

1:М

1 сообщение содержится в нескольких ответах

«Ответы»

Необязательный

Не все сообщения могут присутствовать в ответах

1:1

1 ответ содержит только 1 сообщение

Общий тип связи

1:М

Аналогична связь пар сущностей «Ошибки» - «Ответы», «Детальные ошибки» - «Ответы»

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

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

Рисунок 1.4 - Концептуальная модель данных

2. Разработка структур данных и программного обеспечения

2.1 Построение физической модели данных

На основании анализа концептуальной модели данных и проведенной нормализации таблиц, в связи с устранением не атомарных атрибутов и связей «много-ко-многим», получим набор таблиц БД, представленный в таблице 2.1.

Таблица 2.2 - Набор таблиц базы данных

№

Сущность

Таблицы

1

Запросы

REQUEST.DBF

2

Ответы

REPLY.DBF

3

Выборка

MODIFYDATE.DBF

4

Типы пакетов

TYPEPACKETS.DBF

5

Имя пакета

FORNAMEPAK.DBF

6

Пакеты

PACKETY.DBF

7

Статистика

QUERYES.DBF

8

Задачи

RUNWHAT.DBF

9

Расписание

TIMING.DBF

10

Ошибки

ERRMESS.DBF

11

Сообщения

TRNMESS.DBF

12

Детальные ошибки

EXTENDERRMESS.DBF

13

Результаты

RESULTS.DBF

14

Группы результатов

RESULTGROUPS.DBF

15

Виды запросов

NUMQUERY.DBF

16

Улицы

STREETS.DBF

17

Районы

STANDART.DBF

18

Элементы

ITEMS.DBF

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

Рисунок 2.1 - Схема физической модели данных

Спецификация всей базы данных представлена в таблице 2.2.

Таблица 2.2 - Спецификация БД

№

Имя таблицы/БД

Назначение

EXCHANGE.DBC

Файл базы данных

1

TYPEPACKETS.DBF

Справочник типов пакетов, включает в себя тип пакета-запроса (QR), тип пакета-ответа(RQ), и имя шаблона в каждом случае (TRANS).

2

ERRMESS.DBF

Справочник ошибок, значения поля ERRCODE из пакета-ответа в таблице TRANS.

3

EXTENDERRMESS.DBF

Справочник для ошибок расширенных кодов, значения поля DOCREASON из пакета-ответа в таблице TRANS.

4

FORNAMEPAK.DBF

Данные генерации имени пакета, дата и порядковый номер пакета за эту дату.

5

MODIFYDATE.DBF

Параметры выгрузки данных из ЛБД на отправку первичного запроса. Период изменений данных: начальная и конечная даты. Может быть задан свой диапазон.

6

PACKETY.DBF

Сведения об отправленных и полученных пакетах. Журнал регистрации всех пакетов.

7

QUERYES.DBF

Статистика в разрезе "код запроса"/"количество записей" по указанному пакету.

8

TRNMESS.DBF

Справочник сообщений, значения поля MESSCODE из пакета-ответа в таблице TRANS.

9

RUNWHAT.DBF

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

10

TIMING.DBF

Расписание запуска задач.

11

NUMQUERY.DBF

Справочник запросов, содержит виды запросов и их описание.

12

RESULTS.DBF

Справочник кодов результатов обработки запросов, значение для поля RESULTID таблицы REQUEST.

13

RESULTGROUPS.DBF

Справочник групп результатов.

14

REPLY.DBF

Таблица ответов на запросы. Содержит ответы, полученные на запросы.

15

REQUEST.DBF

Таблица запросов. Содержит данные, отправленные на запросы.

16

SETTING.DBF

Настройки путей и постоянных значений.

17

ITEMS.DBF

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

18

STREETS.DBF

Предназначен для хранения и кодирования названий всех улиц на территории Самарской области.

19

STANDART.DBF

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

Структуры таблиц представлены в таблице 2.3.

Таблица 2.3 - Структуры таблиц БД

№ п/п

Имя поля

Расшифровка

Тип

Длина

1. TYPEPACKETS.DBF

1

TYPEID

Код типа пакета (Первичный ключ)

Integer (AutoInc)

4

2

TYPE

Тип

Character

3

3

TEMPLATE

Имя таблицы-шаблона

Character

10

4

COMMENT

Комментарий

Character

100

2. ERRMESS.DBF

1

ERRMESSID

Код ошибки (первичный ключ)

Integer

4

2

NAME

Текст ошибки

Character

254

3. EXTENDERRMESS.DBF

1

EXERMESSID

Код ошибки (первичный ключ)

Integer

4

2

NAME

Текст ошибки

Character

254

4. FORNAMEPAK.DBF

1

FORNAMEPAKID

Код (первичный ключ)

Integer (AutoInc)

4

2

DATEGEN

Дата для генерации пакета

Date

8

3

NUM

Порядковый номер пакета за день

Numeric

2

5. MODIFYDATE.DBF

1

MODIFYDATEID

Код (первичный ключ)

Integer (AutoInc)

4

2

DATESTART

Начальная дата поиска

DateTime

8

3

DATEFINISH

Конечная дата поиска

DateTime

8

4

AMOUNT

Количество найденных записей

Numeric

6

5

FLAG

Признак изменения условий

Logical

1

6. PACKETY.DBF

1

PACKETID

Код (первичный ключ)

Integer (AutoInc)

4

2

NAME

Имя пакета

Character

12

3

DATETSEND

Дата/время отправки/получения

DateTime

8

7. QUERYES.DBF

1

QUERYESID

Код (первичный ключ)

Integer (AutoInc)

4

2

PACKETID

Код пакета (PACKETY)

Integer

4

3

NUMQ

Код Запроса (NUMQUERY)

Character

3

4

AMOUNTNUMQ

Количество записей по запросу

Numeric

6

8. TRNMESS.DBF

1

TRNMESSID

Код сообщения (первичный ключ)

Integer

4

2

NAME

Текст сообщения

Character

254

9. RUNWHAT.DBF

1

RUNWHATID

Код задачи (первичный ключ)

Integer (AutoInc)

4

2

NAME

Описание задачи

Character

100

10. TIMING.DBF

1

TIMINGID

Код (первичный ключ)

Integer (AutoInc)

4

2

EVENTTIME

Время запуска

Character

5

3

EVENTRUN

Признак запуска

Logical

1

4

RUNWHATID

Код запускаемой задачи (RUNWHAT)

Integer

4

11. NUMQUERY.DBF

1

NUMQ

Код запроса (первичный ключ)

Character

3

2

NAME

Наименование запроса

Character

254

12. RESULTS.DBF

1

RESULTID

Код результата (первичный ключ)

Integer (AutoInc)

4

2

GROUPID

Код группы результата (GROUPSRESULT)

Integer

4

3

NAME

Расшифровка результата

Character

254

13. RESULTGROUPS.DBF

1

GROUPID

Код группы (первичный ключ)

Integer (AutoInc)

4

2

NAME

Расшифровка группы

Character

140

14. REPLY.DBF

1

REPLYID

Код (первичный ключ)

Integer (AutoInc)

4

2

PACKETID

Код пакета (PACKETY)

Integer

4

3

EIN

Единый идентификационный номер (ЕИН)

Character

16

4

SURNAME

Фамилия

Character

24

5

NAME

Имя

Character

16

6

SECNAME

Отчество

Character

16

7

NDOC

Номер документа

Numeric

7

8

NSDOC

Номер серии документа

Numeric

2

9

SDOC

Серия документа

Character

2

10

DOCTYPE

Тип документа (ITEMS)

Numeric

1

11

DOCDATE

Дата выдачи документа

Date

8

12

DOCEMISS

Код подразделения УВД, выдавшего документ

Character

10

13

NPOLIS

Номер бланка страхового полиса ОМС

Numeric

8

14

SPOLIS

Серия бланка страхового полиса ОМС

Character

5

15

INSURER

Код СМО (SMO)

Numeric

5

16

AGRNUM

Номер договора страхования

Numeric

6

17

BIRTHDAY

Дата рождения

Date

8

18

RGN1

Код города или сельского района (STANDART)

Numeric

3

19

RGN2

Гор.район, поселок или сельсовет (STANDART)

Numeric

3

20

RGN3

Населенный пункт (STANDART)

Numeric

3

21

STREET

Улица (STREETS)

Numeric

4

22

HOUSE

Номер дома

Numeric

4

23

HOUSEEDGE

Второй номер дома, если дом угловой

Numeric

4

24

HOUSELITER

Литера дома

Character

1

25

CORPUS

Корпус

Numeric

2

26

FLAT

Квартира

Numeric

4

27

FLATLITER

Литера квартиры

Character

1

28

LPUBASE

Код ЛПУ ПМСП прикрепления (LPU)

Numeric

5

29

LPUBASE_U

Номер участка в ЛПУ ПМСП

Numeric

3

30

LPUDENT

Код стоматологического ЛПУ прикрепления (LPU)

Numeric

5

31

LOCAL

Признак регистрации прописки (ITEMS)

Numeric

1

32

SEX

Пол (ITEMS)

Numeric

1

33

FINSTAT

Страхователь (ITEMS)

Numeric

1

34

POLISDATE

Дата выдачи полиса ОМС

Date

8

35

REASONBASE

Причина смены ЛПУ ПМСП прикрепления (ITEMS)

Numeric

1

36

REASONDENT

Причина смены стоматологического ЛПУ ПМСП прикрепления (ITEMS)

Numeric

1

37

PENSION

Идентификатор пенсионного фонда

Character

14

38

REMSTAT

Признак окончания действия записи (ITEMS)

Numeric

1

39

EIN_REF

ЕИН оригинала (для «двойника»)

Character

16

40

BEGDATE

Дата регистрации объекта

Date

8

41

ENDDATE

Конец периода действия записи

Date

8

42

MODDATE

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

Date

8

43

SMOFIN

СМО, на которую производится финансирование в текущем квартале(SMO)

Numeric

5

44

BEGFIN

Дата начала квартала финансирования для СМО

Date

8

45

ENDFIN

Дата окончания квартала финансирования

Date

8

46

INSTAT

Статус согласования записи (ITEMS)

Numeric

1

47

AUTHORSTAT

Автор изменения статуса (ITEMS)

Numeric

1

48

DATE_CH

Дата последнего изменения записи в локальной БД страховой компании

Date

8

49

KLADRST

Для жителей иных областей - код территории проживания по КЛАДР, детализированный до уровня улицы (KLADRST)

Character

17

50

LDBL

Ветка логического дублирования

Character

16

51

IDQ

Идентификатор запроса в системе ЕМСР ТФОМС

Character

10

52

IDQ_SBJ

Идентификатор запроса в системе «Система информационного обмена для СМО»

Character

20

53

OPERDATE

Дата проведенной операции

Date

8

54

NUMQ

Код запроса (NUMQUERY)

Character

3

55

SILENCE

Признак действия по умолчания (ITEMS)

Numeric

1

56

SOURCETAB

Имя таблицы-источника

Character

8

57

TRNMESSID

Код сообщения (TRNMESS)

Integer

4

58

ERRMESSID

Код ошибки (ERRMESS)

Integer

4

59

EXERMESSID

Код расширенной ошибки (EXTENDERRMESS)

Integer

4

60

COMMENT

Дополнительная информация ТФОМС

Character

40

15. REQUEST.DBF

1

REQUESTID

Код (первичный ключ)

Integer (AutoInc)

4

2

REPLYID

Ссылка на запись из ответа (REPLY)

Integer

4

3

PACKETID

Код пакета (PACKETY)

Integer

4

4

TKEY

Уникальный идентификатор записи в ЛБД СМО

Integer

4

5

EIN

Единый идентификационный номер (ЕИН)

Character

16

6

SURNAME

Фамилия

Character

24

7

NAME

Имя

Character

16

8

SECNAME

Отчество

Character

16

9

NDOC

Номер документа

Numeric

7

10

NSDOC

Номер серии документа

Numeric

2

11

SDOC

Серия документа

Character

2

12

DOCTYPE

Тип документа (ITEMS)

Numeric

1

13

DOCDATE

Дата выдачи документа

Date

8

14

DOCEMISS

Код подразделения УВД, выдавшего документ

Character

10

15

NPOLIS

Номер бланка страхового полиса ОМС

Numeric

8

16

SPOLIS

Серия бланка страхового полиса ОМС

Character

5

17

INSURER

Код СМО (SMO)

Numeric

5

18

AGRNUM

Номер договора страхования

Numeric

6

19

BIRTHDAY

Дата рождения

Date

8

20

RGN1

Код города или сельского района (STANDART)

Numeric

3

21

RGN2

Гор.район, поселок или сельсовет (STANDART)

Numeric

3

22

RGN3

Населенный пункт (STANDART)

Numeric

3

23

STREET

Улица (STREETS)

Numeric

4

24

HOUSE

Номер дома

Numeric

4

25

HOUSEEDGE

Второй номер дома, если дом угловой

Numeric

4

26

HOUSELITER

Литера дома

Character

1

27

CORPUS

Корпус

Numeric

2

28

FLAT

Квартира

Numeric

4

29

FLATLITER

Литера квартиры

Character

1

30

LPUBASE

Код ЛПУ ПМСП прикрепления (LPU)

Numeric

5

31

LPUBASE_U

Номер участка в ЛПУ ПМСП

Numeric

3

32

LPUDENT

Код стоматологического ЛПУ прикрепления (LPU)

Numeric

5

33

LOCAL

Признак регистрации прописки (ITEMS)

Numeric

1

34

SEX

Пол (ITEMS)

Numeric

1

35

FINSTAT

Страхователь (ITEMS)

Numeric

1

36

POLISDATE

Дата выдачи полиса ОМС

Date

8

37

REASONBASE

Причина смены ЛПУ ПМСП прикрепления (ITEMS)

Numeric

1

38

REASONDENT

Причина смены стоматологического ЛПУ ПМСП прикрепления (ITEMS)

Numeric

1

39

PENSION

Идентификатор пенсионного фонда

Character

14

40

REMSTAT

Признак окончания действия записи (ITEMS)

Numeric

1

41

EIN_REF

ЕИН оригинала (для «двойника»)

Character

16

42

BEGDATE

Дата регистрации объекта

Date

8

43

ENDDATE

Конец периода действия записи

Date

8

44

MODDATE

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

Date

8

45

SMOFIN

СМО, на которую производится финансирование в текущем квартале(SMO)

Numeric

5

46

BEGFIN

Дата начала квартала финансирования для СМО

Date

8

47

ENDFIN

Дата окончания квартала финансирования

Date

8

48

INSTAT

Статус согласования записи (ITEMS)

Numeric

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены