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

Вид работы:

Дипломная (ВКР)
Предмет:

Информационное обеспечение, программирование
Язык:

Русский
,
Формат файла:
MS Word

482,1 Кб
Опубликовано:

2014-12-14

Все дипломные работы по информационному обеспечению

Скачать дипломную работу Читать текст online Заказать дипломную
*Помощь в написании! Посмотреть все дипломные работы

Вы можете узнать стоимость помощи в написании студенческой работы.

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

Содержание

Сокращения и обозначения

Введение

. Анализ предметной области и постановка задачи

.1 Описание структуры и направление деятельности организации

.2 Описание объекта автоматизации

.3 Обзор существующих аналогов

.4 Изучение правил информационного взаимодействия

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

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

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

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

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

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

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

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

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

.2 Разработка алгоритмов

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

.4 Разработка процедур и функций приложения

. Технико-экономическое обоснование разработки ПО

.1 Расчет затрат на разработку ПО

.2 Расчет цена разработанной программы

.3 Расчет капитальных вложений

.4 Расчет эксплуатационных расходов

.5 Расчет денежного годового экономического эффекта

.6 Определение показателей эффективности инвестиций

.7 Выводы

. Охрана труда

.1 Выявление явных и потенциально опасных вредных производственных факторов

.1.1 Излучение электромагнитных полей

.1.2 Шум

.1.3 Микроклимат

.1.4 Электробезопасность

.1.5 Освещенность

.1.6 Пожарная безопасность

.1.7 Организация рабочего места

4.2 Мероприятия по устранению опасных и вредных производственных факторов

Заключение

Приложения

Сокращения и обозначения

БД - база данных.

ЕМСР - единый медико-социальный регистр.

ЛПУ - лечебно-профилактическое учреждение.

ЛПУ ПМСП - лечебно-профилактическое учреждение первичной медико-санитарной помощи.

ОМС - обязательное медицинское страхование.

ПО - программное обеспечение.

СМО - страховая медицинская организация.

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

ФИО - фамилия имя отчество.

ЛБД - локальная база данных.

ОБД - областная база данных.

АИС - автоматизированная информационная система.

программа страховой медицинский интерфейс

Введение

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

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

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

Все население Самарской области делится на две категории:

работающие, страхователем является работодатель;

неработающие, страхователем является Администрация Самарской области.

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

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

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

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

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

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

1 Анализ предметной области и постановка задачи

.1 Описание структуры и направление деятельности организации

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

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

Организационная структура страховой компании представлена на рисунке 1.1.

Рисунок 1.1 - Организационная структура страховой медицинской организации

Деятельность страховой медицинской организации направлена на решение следующих задач:

1) выдача полисов ОМС;

2) прием и обработка счетов за оказанные медицинские услуги;

3) защита прав застрахованных;

4) проведение экспертизы медицинской помощи;

5) оказание консультационной помощи по бесплатной горячей телефонной линии;

6) поддержание в актуальном и корректном состоянии информации о застрахованных в ЕМСР и другие.

Из вышеперечисленных задач, приоритетной является выдача полиса ОМС. Эта процедура осуществляется следующим образом.

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

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

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

Итак, полис ОМС выдан, но кроме его наличия, не менее важным является, то какое ЛПУ будет оказывать медицинскую помощь застрахованному и соответственно, куда будет перечисляться оплата по выставленным счетам. По умолчанию, при выдаче полиса, застрахованного прикрепляют к лечебному учреждению, по его территории проживания. Если же гражданин хочет обслуживаться другим ЛПУ, то для этого ему необходимо написать там заявление на прикрепление, после чего данное лечебное учреждение передает это заявление в страховую компанию, которая изменяет прикрепление в БД по умолчанию, на основании заявления.

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

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

.2 Описание объекта автоматизации

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

Сведения о застрахованном в БД описываются следующими информационными сегментами:

1) ЕИН - единый идентификационный номер в ОБД;

2) персональные данные (ФИО, пол, дата рождения, документ, адрес);

3) данные о страховании (полис, договор, страхователь, СМО);

4) данные о прикреплении (базовое ЛПУ, стоматологическое ЛПУ).

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

Рисунок 1.2 - Схема информационного обмена

Для выполнения этой задачи, СМО реализуется следующая последовательность действий:

1) из ЛБД выбираются данные о застрахованных, по которым произошли изменения, в каком-либо информационном сегменте;

2) выборка анализируется и на основании ее формируется запрос, отсылаемый по электронной почте. Запрос оформляется в виде таблицы формата DBF III, которая заполняется в соответствии с правилами информационного взаимодействия, и упаковывается архиватором в информационный пакет с паролем;

3) затем в течение двух дней, в зависимости от вида запроса, приходит ответ, также в виде информационного пакета по электронной почте;

4) ответ обрабатывается, и далее в зависимости от полученного результата, выбирается дальнейшая стратегия действий:

- ошибки передаются на выверку и исправление в отдел страховой деятельности (ОМС);

посылаются на другие виды запросов;

на основе результата, обновляется информация в ЛБД.

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

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

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

отсылку их на соответствующий запрос;

получение ответа и его обработка;

обновление ЛБД, в соответствии с результатом обработки.

.3 Обзор существующих аналогов

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

1) МИАЦ - медицинский информационно-аналитический центр;

2) ИМЦ - информационный медицинский центр.

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

ООО ИМЦ создано в 2000 году на базе отдела информационных систем самарской компании «ПАРУС». Специалисты, работающие в компании, с 1991 года специализируются на разработке и внедрении программного обеспечения и информационном обслуживании медицинских учреждений, включая развитие всей сопутствующей технической инфраструктуры, сопровождение, модернизацию и распространение программ, обучение и консалтинг пользователей.

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

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

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

Функциональные возможности системы:

1) организация комплексного учета основных этапов медицинского страхования гражданина;

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

3) учет заключенных договоров страхования;

4) ведение истории изменений данных по каждому застрахованному.

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

Преимуществом системы является то, что функционально она входит в состав программного комплекса АИС «ОМС» как один из его модулей. Это позволяет использовать единый программный продукт для реализации всех функций в отношении информации о застрахованных в рамках ЕМСР.

Недостатки:

1) блокировка записи на срок до момента получения ответа на запрос;

2) отсутствие анализа полученных ответов;

3) отсутствие возможности автоматического отслеживания изменения информации о застрахованных и отсылки соответствующих данных в ОБД;

4) несоответствие текущим требованиям нормативных документов.

Таким образом, очевидно, что функционал АИС «ОМС» по обмену информации с ОБД является недостаточным для эффективной организации деятельности СМО. Из этого следует необходимость в разработке новой системы, которая будет лишена указанных выше недостатков.

.4 Изучение правил информационного взаимодействия

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

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

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

Объект учета - человек, проживающий на территории Самарской области.

Запись - сведения об объекте учета за определённый временной интервал, содержащиеся в накопительной таблице ОБД.

Владелец объекта - субъект ОМС, с которым у человека имеются юридические взаимоотношения (СМО, которой застрахован человек).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.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	Код территории проживания по КЛАДР, детализированный до уровня улицы для жителей иных областей	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 - это мощное средство для разработки настольных приложений, работающих с базами данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Состоит из:

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

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

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

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

ошибки;

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

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

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

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

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

№ п/п	Модуль	Состав процедур и функций	Назначение модуля
1	Запрос	Выборка из ЛБД	Осуществляет запрос к ЕМСР
		Оформление запроса
		Регистрация пакета
		Запаковка архиватором
		Отправка по почте
		Получение из почты
		Распаковка архиватором
2	Обработка	В зависимости от запроса анализ полученного ответа	Обрабатывает запрос на основании ответа
		Обновление ЛБД
3	Отчеты	Формирование отчетных форм	Формирует отчеты на печать

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

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

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

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

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

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

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

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

тип пакета;

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

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

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

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

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

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

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

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

1) ошибку;

2) сообщение;

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

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

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

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

1) «Запросы»;

2) «Ответы»;

3) «Выборка»;

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

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

6) «Пакеты»;

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

8) «Задачи»;

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

10)«Ошибки»;

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

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

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

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

Связи сущностей между собой, представлены ниже в таблице 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. Разработка структур данных и программного обеспечения

.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	Код (первичный ключ)		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
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		1
49	AUTHORSTAT	Автор изменения статуса (ITEMS)	Numeric
50	DATE_CH	Дата последнего изменения записи в локальной БД страховой компании	Date		8
51	KLADRST	Для жителей иных областей - код территории проживания по КЛАДР, детализированный до уровня улицы (KLADRST)	Character		17
52	LDBL	Ветка логического дублирования	Character		16
53	IDQ	Идентификатор запроса в системе ЕМСР ТФОМС	Character		10
54	IDQ_SBJ	Идентификатор запроса в системе «Система информационного обмена для СМО»	Character		20
55	OPERDATE	Дата проведенной операции	Date		8
56	NUMQ	Код запроса (NUMQUERY)	Character		3
57	SILENCE	Признак действия по умолчания (ITEMS)	Numeric		1
58	SOURCETAB	Имя таблицы-источника	Character		8
59	RESULTID	Код результата обработки запроса (RESULTS)	Integer		4
16. SETTING.DBF
1	SETTINGID	Код	Integer		4
2	VARNAME	Имя переменной	Character		20
3	VARVALUE	Значение	Character		200
4	VARTEXT	Назначение	Character		100
17. ITEMS.DBF
1	CKEY	Уникальный код пункта прейскуранта	Numeric		6
2	CREF	Ссылка на родительский пункт	Numeric		6
3	CNUM	Пор. № пункта.в своей иерархии	Numeric		4
4	CEND	Флаг наличия подпунктов	Numeric		1
5	FIELD	Идентификатор поля	Character		10
6	CODE	Значение перечислимого параметра	Numeric		2
7	DESCRIPT	Описание значения перечислимого параметра	Character		64
8	ACTPACK	Идентификатор актуального пакета НСИ	Character		3
9	CHANGE_R	Признак внесения изменений в запись	Numeric		1
10	D_FIN	Дата окончания действия кода	Date		8
11	D_START	Дата ввода кода в действие	Date		8
12	D_MODIF	Дата последней модификации содержательной части записи	Date		8
13	DELETED	Признак логического удаления записи	Numeric		1
18. STREETS.DBF
1	STREET	Код улицы	Numeric		4
2	NAME	Наименование улицы текущее	Character		24
3	DELETED	Признак логического удаления записи	Numeric		1
4	STREET_NEW	Код улицы при переименовании	Numeric		4
5	ACTPACK	Идентификатор актуального пакета НСИ	Character		3
6	CHANGE_R	Признак внесения изменений в запись	Numeric		1
7	D_FIN	Дата окончания действия кода	Date		8
8	D_START	Дата ввода кода в действие	Date		8
9	D_MODIF	Дата последней модификации содержательной части записи	Date		8
19. STANDART.DBF
1	RGN1	Код города или сельского района	Numeric		3
2	RGN2	Гор. район, поселок или сельсовет	Numeric		3
3	RGN3	Населенный пункт	Numeric		3
4	NAME	Наименование	Character		24
5	LABEL	Метка	Numeric		3
6	INSURER	Код базовой СМО на данной территории	Numeric		5
7	OR1	Код города или сельского района по ОКАТО	Numeric		2
8	OR2	Гор. район, поселок или сельсовет по ОКАТО	Numeric		3
9	OR3	Населенный пункт по ОКАТО	Numeric		6
10	ACTPACK	Идентификатор актуального пакета НСИ	Character		3
11	CHANGE_R	Признак внесения изменений в запись	Numeric		1
12	D_FIN	Дата окончания действия кода	Date		8
13	D_START	Дата ввода кода в действие	Date		8
14	D_MODIF	Дата последней модификации содержательной части записи	Date		8
15	DELETED	Признак логического удаления записи	Numeric		1

2.2 Разработка алгоритмов

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

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

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

Программа

Начало

Инициализировать глобальные значения

Вывести окно приложения с заголовком и строкой меню

Выполнять

Если Выбрана команда пункта меню

То Выполнить команду

Конец-если

До Команда меню = Выход

Конец

Блок-схема алгоритма представлена на рисунке 2.2.

Рисунок 2.2 - Блок-схема алгоритма основной программы

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

Детализируем операцию Выполнить команду:

Выполнить команду

Выбор Команда

Файл:

Свернуть в трей

Выход

Настройка:

Параметры

Планировщик

Выгрузка первичного запроса

Запросы:

Формирование

Обработка

Навигатор

Отчеты

Конец - выбор

Определим, какие фрагменты имеет смысл реализовывать в виде подпрограмм и модулей.

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

Во-вторых, фрагменты Формирование, Обработка - достаточно сложные и многострочные операции, поэтому их целесообразно выделить в отдельные модули.

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

В результате, получим следующий алгоритм.

Программа

Начало

Запуск приложения

Выполнять

Если Выбрана команда пункта меню

То

Выбор команда

Файл:

Сворачивание приложения в трей

Настройка:

Вывод на экран формы «Параметры»

Вывод на экран формы «Планировщик»

Вывод на экран формы «Выгрузка первичного запроса»

Запросы:

Запуск модуля «Формирование запроса»

Запуск модуля «Обработка запроса»

Вывод на экран формы «Навигатор»

Вывод на экран формы «Отчеты»

Конец - выбор

Конец - если

До Команда = Выход

Конец

Блок-схема алгоритма представлена на рисунке 2.3.

Детализируем модули «Формирование запроса» и «Обработка запроса».

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

1) выгрузка из ЛБД на первичный запрос;

2) выгрузка из ЛБД на последующий запрос;

3) присвоение имени пакету;

4) регистрация пакета;

5) запаковка архиватором;

6) отправка по электронной почте.

В свою очередь, процесс обработки запроса, содержит:

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

2) распаковка архиватором;

3) анализ полученной информации;

4) обновление ЛБД.

Рисунок 2.3 - Блок-схема основной программы

Проанализировав состав модулей, получим спецификацию подпрограмм, представленную в таблице 2.4.

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

№ п/п	Процедура/Функция	Описание	Параметры
			На входе	На выходе
1	Выгрузка на первичный запрос	Выгружает из ЛБД в соответствии с интервалом времени данные для отправки на первичный запрос	Начальная дата, конечная дата	Dbf-таблица
2	Выгрузка на последующий запрос	-	Dbf-таблица
3	Присвоение имени пакету	Генерирует имя пакета	Дата, номер и тип пакета	Имя пакета
4	Регистрация пакета	Регистрирует пакет в журнале и создает статистику по видам запросам в разрезе каждого пакета	Dbf-таблица, имя и тип пакета	Идентификатор пакета
5	Запаковка	Запаковывает архиватором с паролем dbf-таблицу в пакет	Dbf-таблица, имя пакета	Пакет
6	Отправка	Отсылает пакет по электронной почте	Пакет	-
7	Получение	Проверяет электронную почту на наличие новых пакетов	-	Пакет
8	Распаковка	Распаковывает архиватором с паролем пакет	Пакет	-
9	Анализ ответа	В зависимости от вида запроса и полученной в ответ информации формирует результат	-	Обработанные данные
10	Обновление ЛБД	В соответствии с результатом обработки обновляет ЛБД	-	Обновленные данные

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

Выгрузка на первичный запрос (Начальная дата, Конечная дата);

Выгрузка на последующий запрос ();

Если Выборка пуста

То

Конец

Иначе

Если Порядковый номер пакета > лимита (9)

То

Конец

Иначе

Присвоение имени пакету (Дата, Номер, Тип пакета)

Регистрация пакета (Выборка, Имя пакета, Тип пакета)

Запаковка (Выборка, Имя пакета)

Отправка (Пакет)

Конец - если

Блок-схема алгоритма, показана на рисунке 2.4.

Рисунок 2.4 - блок-схема алгоритма формирование запроса

Алгоритм модуля «Обработка запроса» будет иметь следующий вид:

Получение

Если Пакета нет

То

Конец

Иначе

Распаковка (Пакет)

Анализ ответа ()

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

Конец - если

Блок-схема алгоритма, показана на рисунке 2.5.

Рисунок 2.5 - Блок-схема алгоритма обработки запроса

2.3 Разработка интерфейса пользователя, экранных форм и отчетов

Интерфейс - это связь между функциями системы и пользователем, реализуемая программными средствами.

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

Рисунок 2.6 - Структура меню приложения

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

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

Рисунок 2.7 - Форма «Параметры выгрузки на первичный запрос»

Система предоставляет пользователю возможность пункты «Формирование» и «Обработка» запускать в двух режимах:

ручной - посредством выбора соответствующего пункта меню;

автоматический - через задание расписания запуска в планировщике задач.

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

Рисунок 2.8 - форма задания расписания запуска

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

Выполнение данных задач визуализировано при помощи формы, представленной на рисунке 2.9.

Рисунок 2.9 - Форма, демонстрирующая выполнение формирования запроса

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

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

Рисунок 2.10 - Форма навигации

Не менее важным в любой системе является формирование отчетных форм.

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

Спецификация всех форм приложения, представлена в таблице 2.5.

Таблица 2.5 - Спецификация форм приложения

№	Файл формы	Название	Описание
1	frmSet.scx	Параметры работы приложения	Установка настроек приложения, путей и постоянных значений
2	frmSetQuery.scx	Параметры выгрузки на первичный запрос	Изменяет интервал выгрузки данных из ЛБД на первичный запрос
3	frmPlaner.scx	Планировщик задач	Составляет расписание запуска задач
4	frmNavigator.scx	Навигатор	Позволяет просматривать и редактировать результаты обработки
5	frmReports.scx	Отчеты	Формирует отчеты

2.4 Разработка процедур и функций приложения

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

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

№ п/п	Процедура/Функция		Описание		Параметры на входе	Результат
1. Файл Main.prg
1	prcSetting		Устанавливает пути и постоянные значения		-	Начальные установки
2	prcExitApp		Процедура выхода из приложения		-	Выход
2. Файл mldPackets.prg
1	fncPrepareProcess		Осуществляет подготовку к обработке		-	1 - есть новые пакеты, 0 - нет новых пакетов
2	fncUnPack		Распаковывает архиватором полученный пакет		lcNamePak - пакет	Распакованный пакет
3	fncPrepareQuery		Осуществляет подготовку запроса		lcAlias - алиас таблицы	Алиас готовой таблицы
4	fncGetDataForQ1_2		Выбирает из ЛБД записи на первичный запрос		ldStartDate - начальная дата ldFinishDate - конечная дата	Алиас таблицы
5	fncGetDataForQ_Other		Выбирает записи из ЛБД на запросы модификации (последующий запрос)		-	Алиас таблицы
6	fncPack		Запаковывает архиватором таблицу в пакет		lcAlias - алиас таблицы, lcNamePak - имя пакета	Пакет
7	fncGetTemplate		Определяет имя шаблона таблицы		lnIdType - идентификатор типа пакета	Имя шаблона таблицы пакета
8	fncGetRegPacket		Функция регистрации пакета в журнале и отметка о статистике по запросам		lnNamePak - имя пакета, lnType - тип пакета lcAlias - алиас таблицы	Идентификатор пакета
9	fncGetNamePak		Функция генерации имени пакета		-	Имя пакета
10	fncGetTypePacket		Функция определения типа пакета		lnId - идентификатор типа	Тип пакета
11	fncDateToYMD		Функция перевода даты в формат ГМД		ldDate - дата	ГМД
12	fncSystem32		Функция перевода каждого числа даты в число в систему счисления по основанию 32		lcPartDate - часть даты	часть даты в системе счисления по основанию 32
13	fncGetNextPakNum		Функция определения следующего порядкового номера пакета		ldDate - дата	Номер пакета
14	RunProcess		Функция запуска приложение с ожиданием его завершения		tcCmdLine - командная строка запуска приложениея, ExDirectory - директория	0 - если Ошибка, 1- все в норме
3. Файл CreateQuery.prg
1	prcCreateQuery		Формирование запроса		-	Готовый запрос
4. Файл ProcessQuery.prg
1	prcProcessQuery		Обработка запроса		-	Обработанные и обновленные данные
5. Файл mdlProcess.prg
1	fncProcess		Обработка записей		-	Обработанные данные
2	fncGetUpdateLBD		Обновление ЛБД		-	Обновленные данные
3	fncGetProcessQ_Other		Обработка запросов модификации		lcNumq - вид запроса	Результат обработки
4	fncGetReplyIDForQ1_2		Определят запись из ответа для обработки запроса		lcIdq_sbj - код, lcSurName - фамилия, lcName - имя, lcSecName - отчество, ldBirthday - дата рождения, lnNpolis - номер полиса, lcSpolis - серия полиса, lnNdoc - номер документа, lcSdoc - серия документа, lnNsdoc - номер серии документа, lnDocType - тип документа, lnRGN1, lnRGN2, lnRGN3 lnStreet, lnFlat - адрес	Код записи из ответа
5	fncProcessQ1_2	Обработка первичного запроса		lcIdq_sbj - код		Результат
6	fncIdent	Функция идентификации записей в ответе		lnReplyID - код записи в ответе, lcSurName - фамилия, lcName - имя, lcSecName - отчество, ldBirthday - дата рождения, lnNpolis - номер полиса, lcSpolis - серия полиса, lnNdoc - номер документа, lcSdoc - серия документа, lnNsdoc - номер серии документа, lnDocType - тип документа, lnRGN1, lnRGN2, lnRGN3 lnStreet, lnFlat - адрес		Истина если запись идентифицирована, Ложь в обратном случае
7	fncKeyFIOB	Функция проверки по ключу FIOB		lnReplyID - код записи в ответе, lcSurName - фамилия, lcName - имя, lcSecName - отчество, ldBirthday - дата рождения		Истина - запись совпала по ключу, ложь в обратном случае
8	fncKeyFIB	Функция проверки по ключу FIB		lnReplyID - код записи в ответе, lcSurName - фамилия, lcName - имя, ldBirthday - дата рождения		Истина - запись совпала по ключу, ложь в обратном случае
9	fncKeyFIO	Функция проверки по ключу FIO		lnReplyID - код записи в ответе, lcSurName - фамилия, lcName - имя, lcSecName - отчество		Истина - запись совпала по ключу, ложь в обратном случае
10	fncKeyIOB	Функция проверки по ключу IOB		lnReplyID - код записи в ответе, lcName - имя, lcSecName - отчество ldBirthday - дата рождения		Истина - запись совпала по ключу, ложь в обратном случае
11	fncKeyFOB	Функция проверки по ключу FOB		lcSurName - фамилия, lcSecName - отчество ldBirthday - дата рождения		Истина - запись совпала по ключу, ложь в обратном случае
12	fncAtrPolis	Функция проверки по атрибуту полис		lnReplyID - код записи в ответе, lnNpolis - номер полиса, lcSpolis - серия полиса		Истина - запись совпала по атрибуту, ложь в обратном случае
13	fncAtrDoc	Функция проверки по атрибуту документ		lnReplyID - код записи в ответе, lnNdoc - номер документа, lcSdoc - серия документа, lnNsdoc - номер серии документа, lnDocType - тип документа,		Истина - запись совпала по атрибуту, ложь в обратном случае
14	fncAtrAdres	Функция проверки по атрибуту адрес		lnRGN1, lnRGN2, lnRGN3 lnStreet, lnFlat - адрес		Истина - запись совпала по атрибуту, ложь в обратном случае

3. Технико-экономическое обоснование разработки ПО

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

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

1) расчет технико-экономических показателей и выбор базы сравнения;

2) определение трудоемкости и стоимости программного обеспечения (ПО);

3) расчет цены ПО;

4) расчет капитальных и эксплуатационных затрат на разработку;

5) определение показателей финансово-экономической эффективности.

Исходные данные для расчета экономических показателей приведены в таблице 3.1.

Таблица 3.1 - Исходные данные

№ п/п	Обозначение	Наименование показателя	Единица измерения	Значение показателя
1	С_ЭВМ	Стоимость ЭВМ	Тыс. руб.	12
2	Д_М	Среднее количество дней в месяце	Дни	22
3	_н	Норматив рентабельности	-	0,20
4	_д	Коэффициент, учитывающий дополнительную заработную плату разработчика программы	-	0,10
5	_с	Коэффициент, учитывающий начисления органам социального страхования	-	0,356
6	_н	Коэффициент, учитывающий накладные расходы организации	-	1,15
7	q_I	Количество I-задач, решаемых потребителем	Зад. год	60
8	t_M.B.I	Время, решаемой I-ой задачи разработанной программы	1
9	t’_M.B.I	Время решаемой I-задачи базовой программой	Маш. час	6
10	n_п	Количество организаций, которые приобретут данную программу	Шт.	7
11	Z_ЭЛ	Тариф за 1кВт/час	Руб.	1,63
12	_н	Нормативный коэффициент эффективности капиталовложений	-	0,25
13	Т_С	Срок службы разработанной программы	Год	4
14	НДС	Налог на добавленную стоимость	%	18
15	Т_Р	Количество рабочих дней в году	Дни	264
16	N_CM	Количество смен работы ЭВМ	-	3
17	t_СМ	Продолжительность смены	Часы	8
18		Простои ЭВМ	%	1
19	Р	Мощность, потребляемая ЭВМ	кВТ	0,25
20	N_CP	Среднее количество ремонтов в год	-	1
21	S_Д	Стоимость деталей, заменяемых при ремонте	Руб.	500

3.1 Расчет затрат на разработку ПО

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

(3.1)

где: - затраты по заработной плате инженера-программиста;

- накладные расходы.

Затраты по заработной плате инженера-программиста рассчитываются по формуле:

(3.2)

где: - основная заработная плата инженера программиста за месяц (8000 руб.);

- время, необходимое для разработки приложения программистом I-го разряда (чел.-мес.);

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

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

Приложение разрабатывалось 30 дней, если учесть что в одном месяце 22 рабочих дня, то:

(чел.-мес.)

Таким образом, затраты по заработной плате инженера-программиста составят:

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

(3.3)

Таким образом, суммарные затраты на разработку приложения составляют:

В качестве базы сравнения будем использовать АИС «ОМС».

3.2 Расчет цена разработанной программы

Оптовая цена разработанной системы определяется по следующей формуле:

(3.4)

где: - оптовая цена (цена разработчика) (руб.);

- суммарные затраты на разработку системы (руб.);

- прибыль, рассчитанная по формуле:

(3.5)

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

Итак,

Розничная цена системы рассчитывается с учетом налога на добавленную стоимость () по формуле:

(3.6)

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

(3.7)

3.3 Расчет капитальных вложений

Капиталовложения, связанные с работой ПК рассчитываются по формуле:

(3.8)

где: - стоимость ПК (руб.);

- стоимость транспортировки ПК (руб.);

- стоимость монтажа ПК (руб.);

- стоимость запасных частей (руб.);

- стоимость площади установки ПК (руб.).

Так как площадь, отводимая под установку ПК, в данном случае не существенна, то этим коэффициентом можно пренебречь.

Итак, произведем расчет коэффициентов входящих в формулу расчета величины капиталовложений:

; (руб.);

; (руб.).

Капиталовложения в ПК составляют:

3.4 Расчет эксплуатационных расходов

Эксплуатационные расходы на ПК рассчитываются по формуле:

(3.9)

где: - машинное время для решения задач с помощью разработанной системы, (маш.час/год);

- эксплуатационные расходы, приходящиеся на 1 час работы ПК;

- цена, по которой продается система (руб.);

- срок службы системы (г.).

Полезный фонд времени работы ПК рассчитывается по формуле:

(3.10)

где: - общий фонд времени работы ПК (дни); ;

- количество смен работы ПК;

- время одного рабочего дня (час);

- простои ПК (в % от общего фонда времени работы ПК).

Полезный фонд времени работы ПК получим:

Машинное время для решения задач с помощью данной ситемырассчитывается по формуле:

(3.11)

где: - количество I-задач, решаемых потребителем в год (шт.);

- время для решения I-задачи, разработанной системой (маш.час).

(маш.час/год)

Эксплуатационные расходы, приходящиеся на 1 час работы ЭПК, оцениваются по формуле:

(3.12)

где: - амортизационные отчисления (руб.);

- затраты по заработной плате инженера в год (руб./год);

- стоимость потребляемой энергии (руб.);

- затраты на ремонт ПК (руб.);

- полезный годовой фонд работы ПК (маш.час/год).

Амортизационные отчисления рассчитываются с учетом нормы амортизации ();

Затраты по заработной плате инженера за год рассчитываются по формуле:

(3.13)

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

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

- основная заработная плата инженера за месяц 6-го разряда (10000 руб.).

Рассчитываем годовые затраты по заработной плате и социальным отчислениям инженера:

(руб./год)

Стоимость потребляемой энергии оценивается по формуле:

(3.14)

где: - мощность, потребляемая ПК (кВт);

- полезный годовой фонд работы ЭПК (маш.час/год);

- тариф за 1 кВт/час (руб./кВт).

Итак, произведем расчет стоимости потребляемой энергии:

Затраты на ремонт ПК вычисляются по формуле:

(3.15)

где: - среднее количество ремонтов в год;

- стоимость деталей заменяемых при одном ремонте, в среднем.

(руб.)

Произведем вычисление эксплуатационных расходов, приходящихся на 1 час работы ПК:

(руб./час)

Далее вычислим эксплуатационные расходы на ПК:

3.5 Расчет денежного годового экономического эффекта

Денежный годовой экономический эффект оценивается по следующей формуле:

(3.16)

где: - экономия стоимости машинного времени (руб.);

- нормативный коэффициент эффективности капитальных вложений;

- экономия капитальных вложений (руб.).

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

(3.17)

где: - машинное время для решения задач с помощью разработанной системы (маш.час/год);

- капиталовложения в ПК (руб.);

- полезный годовой фонд работы ПК (маш.час/год);

- машинное время для решения задач базовой системой рассчитывается с учетом - время решения I-ой задачи базовой программой:

(маш.час/год)

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

Расчет экономии стоимости машинного времени производится по формуле:

(3.18)

где: - эксплуатационные расходы, приходящиеся на 1 час работы ПК;

- машинное время для решения задач базовой программой (маш.час/год);

- машинное время для решения задач с помощью разработанной системы (маш.час/год).

Произведем расчет экономии стоимости машинного времени по формуле:

Теперь определим денежный годовой экономический эффект по формуле:

.6 Определение показателей эффективности инвестиций

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

Расчеты будем производить соизмеряя разновременные затраты и результаты, путем дисконтирования. Для этого используется норма дисконта:

(3.19)

где: - цена капитала;

- коэффициент, учитывающий риск;

- уровень инфляции на валютном рынке.

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

(3.20)

где: - период дисконтирования.

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

чистая дисконтированная стоимость (текущая дисконтированная стоимость), т.е. доход;

внутренняя норма доходности;

срок окупаемости.

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

Таблица 3.2 - План денежных потоков

№ п/п	Показатель	Значения, руб.
		0-й год	1-й год	2-й год	3-й год	4-й год
1	Выручка от реализации		284 876,90	284 876,90	284 876,90	284 876,90

2	НДС (18%)		51 277,84	51 277,84	51 277,84	51 277,84
3	Выручка от реализации без НДС		233 599,06	233 599,06	233 599,06	233 599,06
4	Издержки на персонал		178 992	178 992	178 992	178 992

5	Эксплуатационные расходы		10 381,38	10 381,38	10 381,38	10 381,38

6	Амортизационные отчисления		1 851,75	1 851,75	1 851,75	1 851,75
7	Прибыль от реализации		42 373,93	42 373,93	42 373,93	42 373,93

8	Налог на прибыль (24%)		10 169,74	10 169,74	10 169,74	10 169,74
9	Чистая прибыль		32 204,19	32 204,19	32 204,19	32 204,19
10	Капитальные вложения	14 814
11	Прочие единовременные затраты	28 740,61
12	Денежный поток	-43 554,61	32 204,19	32 204,19	32 204,19	32 204,19

Размер выручки от реализации определяется с учетом прогнозируемой средней потребности в разработанной системе (7 шт.) и розничной цены (40 696,70 руб.).

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

(3.21)

где: - результат в -ом году;

- затраты в -ом году;

- период дисконтирования.

Вычисление чистой дисконтированной стоимости и текущей дисконтированной стоимости приведено в таблице 3.3.

Таблица 3.3 - Вычисление чистой и текущей дисконтированной стоимости

№ п/п	Год	Затраты(+) Результаты (-)	при (тыс. руб.)нарастающим итогом
1	0	-43 554,61	1	-43 554,61	-43 554,61
2	1	32 204,19	0,7576	24 475,18	-19 079,43
3	2	32 204,19	0,5739	18 356,39	-723,04
4	3	32 204,19	0,4348	13 847,80	13 124,76
5	4	32 204,19	0,3294	10 627,38	23 752,14
= 23 752,14

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

Точное значение ставки дисконта вычисляется по формуле:

(3.22)

где: - значение ставки дисконта, при которой принимало последнее положительное значение;

- последнее положительное значение ;

- последнее отрицательное значение .

Зависимость чистой дисконтированной стоимости от нормы дисконта представлена в таблице 3.4. и отражена на рисунке 3.1.

Таблица 3.4 - Зависимость ЧДС от нормы дисконта

Номер

Значение нормы дисконта ()Значение , тыс. руб.

0,32

23,94

0,47

10,29

0,62

0,85

0,77

-5,99

Рисунок 3.1 - Зависимость от нормы дисконта

Расчет внутренней нормы дисконта представлен в таблице 3.5.

Таблица 3.5 - Расчет внутренней нормы дисконта

№ п/п	Год	Денежные потоки	=63%=64%

1	0	-43 554,61	1	-43 554,61	1	-43 554,61
2	1	32 204,19	0,6135	19 757,27	0,6098	19 636,70
3	2	32 204,19	0,3764	12 121,66	0,3718	11 973,60
4	3	32 204,19	0,2309	7 435,95	0,2267	7 300,97
5	4	32 204,19	0,1417	4 563,33	0,1382	4 451,81

Точное значение внутренней нормы доходности (рентабельность) составит:

Рассчитанное значение , составляющее 63,63%, превышает фактическую норму дисконта , следовательно, инвестиции в данный проект оправданы.

Индекс доходности рассчитывается по формуле:

(3.23)

где: - приведенная величина инвестиций, рассчитывающаяся по формуле:

(3.24)

где: - величина инвестиций в -ом году.

Индекс доходности проекта составляет:

Рассчитанное значение = 1,55 больше единицы, следовательно, разработку системы можно считать эффективной и экономически обоснованной.

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

(3.25)

где: - индекс доходности проекта;

- срок службы системы.

Средняя рентабельность разработки в нашем случае составит:

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

Определим графическим методом, график, изображенный на рисунке 3.2, строится по данным таблицы 1.3.

Рисунок 3.2 - Определение срока окупаемости проекта

Как видно из графика, значение составляет 2,05 года.

3.7 Выводы

Обобщенные технико-экономические показатели разработки системы сведены в таблицу 3.6.

Таблица 3.6 - Обобщенные технико-экономические показатели

№	Показатель	Значение
1	Капитальные вложения (руб.)	14 814
2	Эксплуатационные расходы (руб.)	10 381,38
3	Оптовая цена (руб.)	34 488,73
4	Свободная отпускная цена (руб.)	40 696,70
5	Затраты на проектирование	28 740,61
6	Чистая дисконтированная стоимость (при =32%) (руб.)23 752,14
7	Внутренняя норма доходности (%)	63,63
8	Индекс доходности	1,55
9	Средняя рентабельность разработки (%)	38,63
10	Срок окупаемости	2,05

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

4. Охрана труда

.1 Выявление явных и потенциально опасных вредных производственных факторов

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

Пользователь разрабатываемой системы, при работе с видеодисплейными терминалами (ВДТ) и ПК, сталкивается с воздействием следующих опасных и вредных производственных факторов:

излучение электромагнитных полей;

статическое электричество;

повышенный уровень шума;

микроклимат;

электрический ток;

недостаточная освещенность.

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

4.1.1 Излучение электромагнитных полей

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

ПК являются источниками таких излучений как:

мягкого рентгеновского;

ультрафиолетового 200-400 нм;

видимого 400-700 нм;

ближнего инфракрасного 700-1050 нм;

радиочастотного 3 кГц-3О мГц;

электростатических полей.

Ультрафиолетовое излучение полезно в небольших количествах, но в больших дозах приводит к дерматиту кожи, головной боли, рези в глазах. Инфракрасное излучение приводит к перегреву тканей человека (особенно хрусталика глаза), повышению температуры тела. Уровни напряженности электростатических полей составляют не более 20 кВ/м. При повышенной опасности электромагнитного поля на расстоянии 5-10 см от экрана и корпуса монитора уровни напряженности могут достигать 140 В/м по электрической составляющей.

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

Таблица 4.1 - Предельно допустимые значения характеристик ЭМП

Наименование параметров	Допустимое значение
Напряженность электромагнитного поля по электрической составляющей на расстоянии 50 см от поверхности видеомонитора	10 В/м
Напряженность электромагнитного поля по магнитной составляющей на расстоянии 50 см от поверхности видеомонитора	0,3 А/м
Напряженность электростатического поля не должно превышать: - для взрослых пользователей	20 кВ/м
Напряженность электромагнитного поля на расстоянии 50 см вокруг ВДТ по электрической составляющей должна быть не более:
- в диапазоне частот 5 Гц - 2 кГц;	25 В/м
- в диапазоне частот 2 - 400 кГц	2,5 В/м
Плотность магнитного потока должна быть не более:
- в диапазоне частот 5 Гц - 2 кГц;	250 нТл
- в диапазоне частот 2 - 400 кГц	25 нТл
Поверхностный электростатический потенциал не должен превышать	500 В

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

Для предупреждения внедрения опасной техники все дисплеи проходят испытания на соответствие требованиям безопасности (например, международные стандарты MRP 2, TCO 99).

4.1.2 Шум

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

Эквивалентный уровень звука не превышает 50 дБ. Для того чтобы добиться этого уровня шума, применяется звукопоглощающее покрытие стен.

В качестве мер по снижению шума можно предложить следующее:

облицовка потолка и стен звукопоглощающим материалом (снижает шум на 6-8 дб);

экранирование рабочего места (постановкой перегородок, диафрагм);

установка в компьютерных помещениях оборудования, производящего минимальный шум;

рациональная планировка помещения.

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

4.1.3 Микроклимат

Работа администратора БД, относится к категории Іа (легкие физические работы), и соответствует следующим требованиям:

1) оптимальная температура воздуха:

- в теплый период 23-25 С;

в холодный период 22-24 С;

2) оптимальная относительная влажность - 40-60% (допустимая - не более 75%);

3) скорость движения воздуха не более 0,1 м/с.

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

4.1.4 Электробезопасность

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

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

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

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

4.1.5 Освещенность

Для освещения помещения, в котором работает администратор БД, используется совмещенное освещение, то есть сочетание естественного и искусственного освещения.

Естественное освещение - осуществляется через окна в наружных стенах здания.

Искусственное освещение - используется при недостаточном естественном освещении и осуществляется с помощью двух систем: общего и местного освещения. Общим называют освещение, светильники которого освещают всю площадь помещения. Местным называют освещение, предназначенное для определённого рабочего места.

Освещенность на поверхности стола в зоне размещения рабочего документа составляет 300-500 лк, также установлены светильники местного освещения для подсветки документов, с таким условием, чтобы оно не создавало бликов на поверхности экрана и не увеличивало освещенность экрана более чем на 300 лк.

В качестве источников света при искусственном освещении применяются преимущественно люминесцентные лампы типа ЛБ.

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

.1.6 Пожарная безопасность

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

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

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

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

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

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

.1.7 Организация рабочего места

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

Чтобы исключить возникновение заболеваний необходимо иметь возможность свободной перемены поз. Необходимо соблюдать режим труда и отдыха с перерывами, заполняемыми “отвлекающими” мышечными нагрузками на те звенья опорно-двигательного аппарата, которые не включены в поддержание основной рабочей позы.

Антропологические характеристики человека определяют габаритные и компоновочные параметры его рабочего места, а также свободные параметры отдельных его элементов.

По условиям работы рабочее место администратора БД относится к индивидуальному рабочему месту для работы сидя.

Рабочий стул администратора БД снабжен подъемно-поворотным механизмом. Высота сиденья регулируется в пределах 400 - 500 мм. Глубина сиденья составляет не менее 380 мм, а ширина - не менее 400 мм. Высота опорной поверхности спинки не менее 300 мм, ширина - не менее 380 мм. Угол наклона спинки стула к плоскости сиденья изменяется в пределах 90 - 110°.

4.2 Мероприятия по устранению опасных и вредных производственных факторов

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

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

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

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

1) отключение компьютера от сети;

2) проверка отсутствия напряжения.

После выполнения этих действий проводится ремонт неисправного оборудования.

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

В организации используются рабочие столы с высотой рабочей поверхности 725 мм, а также рабочие кресла с подъемно-поворотным устройством. Конструкция кресел обеспечивает регулировку высоты опорной поверхности сиденья в пределах 400-500 мм и углов наклона вперед до 15 градусов и назад до 5 градусов. Каждое кресло оборудовано подлокотниками, что сводит к минимуму неблагоприятное воздействие на кистевые суставы рук.

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

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

В целом условия труда в отделе соответствуют общепринятым нормам, сотрудникам обеспечены комфорт и благоприятные условия труда.

Заключение

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

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

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

В ходе работы были сформулированы требования к техническому обеспечению и обоснован выбор средств автоматизации. Программное обеспечение системы разработано в среде Visual Fox Pro 9 под управлением ОС Windows XP.

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

Приложение 1

Листинг файла mdlPackets.prg

Функция подготовки к обработке, поступивших пакетов

На входе - ничего нет

На выходе - 1 - если есть новые пакеты, 0 в ином случае

FUNCTION fncPrepareProcesslnI as Integer,;as Integer,;as Integer,;as String,;as String = ADIR(MasFile, gcInPutPath + PADL(gcSmo,5,"0")+ "*.*")lnFileCnt = 00lnI = 1 TO lnFileCnt.container1.label3.ForeColor = RGB(0, 128, 255).container1.label3.caption = ALLTRIM(STR(lnI)).Refresh

= fncUnPack(MasFile[lnI,1])= MasFile[lnI,1]= fncGetTemplate(gnIDTypeOut)!USED(lcAlias)(gcArxPath + lcAlias) IN 0 ALIAS &lcAlias= fncGetRegPacket(lcNamePak, gnIDTypeOut, lcAlias)!USED('Reply')(gcDataPath + "Reply.dbf") IN 0 ALIAS Reply*, lnPacketID as PacketID FROM &lcAlias INTO CURSOR curReplyFROM DBF('cur')IN curIN ReplyIN &lcAlias1

ENDFUNC

&& Функция распаковки полученного пакета

&& На входе - полное имя пакета

&& На выходе - результат работы архиватора

FUNCTION fncUnPacklcNamePak as StringlnReturn as IntegerFILE (gcInPutPath + ALLTRIM(lcNamePak)) TO (gcArxPath + ALLTRIM(lcNamePak))= RunProcess(gcArxPath+"unpack.bat"+" "+ALLTRIM(lcNamePak),gcArxPath)

RETURN lnReturn

Функция подготовки к отправке

На входе - Алиас таблицы

На выходе - Алиас готовой таблицы

FUNCTION fncPrepareQuerylcAlias as StringldDate as Date,;as Integer,;as String,;as String,;as Integer,;_sbj as String!USED('Request')(gcDataPath + "Request") IN 0 ALIAS Request= DATE()= fncGetNextPakNum(ldDate)lnNum = 0(TTOC(DATETIME()) + ":";

+ " Превышен лимит пакетов в день " + CHR(10) + CHR(13),;

gcLogsPath + "Log.txt",1).Null.= fncDateToYMD(ldDate)_sbj = "S" + ALLTRIM(STR(lnNum)) + ALLTRIM(lcYMD)= fncGetNamePak(lnNum,lcYMD).container1.label12.ForeColor = RGB(0,128,255).container1.label12.caption = ALLTRIM(lcNamePak)= fncGetRegPacket(lcNamePak, gnIDTypeIn, lcAlias)&lcAlias SET PacketID = lnPacketID, idq_sbj = lcIdq_sbj + PADL(RECNO(),15,"0")&lcAliasFSIZE('RequestID') != 0table &lcAlias drop COLUMN RequestID* FROM &lcAlias INTO CURSOR curRequestFROM DBF('cur')IN curIN Request.container1.label4.ForeColor = RGB(0,255,64).container1.label12.ForeColor = RGB(0,255,64).container1.label5.ForeColor = RGB(0,128,255).container1.label13.ForeColor = RGB(0,128,255).container1.label13.caption = TTOC(DATETIME())

= fncPack(lcAlias,lcNamePak).container1.label5.ForeColor = RGB(0,255,64).container1.label13.ForeColor = RGB(0,255,64)

ENDFUNC

Функция, создающая выборку для запросов Q1,2

На входе - интервал времени

На выходе - Алиас выборки

FUNCTION fncGetDataForQ1_2ldStartDate, ldFinishDate as Datetime!USED('Request')(gcDataPath + "Request.dbf") IN 0 ALIAS RequestRequestSTRUCTURE TO (gcTempPath + "tmp1.dbf")(gcTempPath + "tmp1.dbf") IN 0 ALIAS tmp1IN RequestDATABASE (gcLBDPath + "dbins.dbc") SHAREDdbins!Fullins IN 0 ALIAS Fullins SHARED= 0.container1.label2.ForeColor = RGB(0,128,255).container1.label3.ForeColor = RGB(0,128,255).container1.label14.caption = "Внимание! Идет выборка на первичный запрос"

SELECT FullinsFOR BETWEEN(Fullins.changedate, ldStartDate, ldFinishDate)= k + 1.container1.label3.Caption = ALLTRIM(STR(k)).refreshMEMVAR Tmp1 BLANK MEMVAREMPTY(ein) OR VAL(ALLTRIM(ein)) = 0numq WITH 'Q01' IN Tmp1numq WITH 'Q02' IN Tmp1ResultID WITH 25,;WITH.F. IN Tmp1 Fullins

ENDSCAN

goFrm.container1.label2.ForeColor = RGB(0,255,64).container1.label3.ForeColor = RGB(0,255,64).refreshIN FullinsDATABASESRECCOUNT('tmp1') = 0(TTOC(DATETIME()) + ":";

+ " Нет данных за период: с " +;

TTOC(ldStartDate) + " по " +;(ldFinishDate)+ CHR(10) + CHR(13),;+ "Log.txt",1)'tmp1'

RETURN 'tmp1'

Функция создающая выборку для запросов модификации

На входе - ничего нет

На выходе - алиас

FUNCTION fncGetDataForQ_OtherlnNumq as Integer !USED('Results')(gcDataPath + "Results.dbf") IN 0 ALIAS Results!USED('Request')(gcDataPath + "Request.dbf") IN 0 ALIAS RequestRequestSTRUCTURE TO (gcTempPath + "tmp2.dbf")(gcTempPath + "tmp2.dbf") IN 0 ALIAS tmp2DATABASE (gcLBDPath + "dbins.dbc") SHAREDdbins!Fullins IN 0 ALIAS Fullins SHAREDrequestID, MAX(operdate) FROM Request WHERE Flag AND ResultID in;

(SELECT ResultID FROM Results WHERE groupid = 1) GROUP BY 1 INTO CURSOR curRECCOUNT('cur') = 0(TTOC(DATETIME()) + ":";

+ " Нет данных для отправки на запросы модификации" + CHR(10) + CHR(13),;

gcLogsPath + "Log.txt",1)'tmp2'= 0.container1.label2.ForeColor = RGB(0,128,255).container1.label3.ForeColor = RGB(0,128,255).container1.label14.caption = "Внимание! Идет выборка на запросы модификации"

SELECT cur

SCAN ALL

k = k + 1.container1.label3.Caption = ALLTRIM(STR(k)).refreshSEEK(cur.RequestID, 'Request', 'RequestID')Request= Request.ResultIDSEEK(Request.tkey, 'Fullins', 'tkey')FullinsMEMVARTmp2BLANKMEMVARResultID WITH 25,;WITH.F. IN Tmp2lnNumq = 1numq WITH "Q01" IN Tmp2lnNumq = 2numq WITH "Q03" IN Tmp2lnNumq = 3numq WITH "Q04" IN Tmp2lnNumq = 4numq WITH "Q05" IN Tmp2lnNumq = 5numq WITH "Q05" IN Tmp2lnNumq = 6numq WITH "Q08" IN Tmp2lnNumq = 7numq WITH "Q09" IN Tmp2IN FullinsDATABASESIN curIN ResultsIN Request!USED('Reply')(gcDataPath + "Reply.dbf") IN 0 ALIAS Replytmp2ALLSEEK(tmp2.ReplyID, 'Reply', 'ReplyID')

Продолжение приложения 1

IF ALLTRIM(tmp2.numq) == 'Q01'

replace ein WITH "" IN Tmp2ALLTRIM(tmp2.numq) == 'Q03'ein WITH "",;WITH 0 IN Tmp2ALLTRIM(tmp2.numq) == 'Q04'ein WITH Reply.ein IN Tmp2ALLTRIM(tmp2.numq) == 'Q08'ein WITH Reply.ein,;WITH 3 IN Tmp2ALLTRIM(tmp2.numq) == 'Q09'ein WITH Reply.ein,;WITH Reply.remstat IN Tmp2IN Reply

RETURN 'tmp2'

Процедура запаковки и отправки пакета

На входе - Алиас, полное имя пакета

На выходе - результат работы архиватора

FUNCTION fncPacklcAlias as String, lcNamePak as StringlcTemplate as String, lnReturn as Integer= fncGetTemplate(gnIDTypeIn)!USED(lcTemplate)(gcTemplatePath + lcTemplate) IN 0 ALIAS &lcTemplateSTEP ON TALK OFF IN &lcTemplateTALK ON &lcTemplateFROM DBF(lcAlias)IN &lcTemplateFILE (gcTemplatePath + ALLTRIM(lcTemplate)+'.dbf') TO (gcArxPath + ALLTRIM(lcTemplate)+'.dbf')=RunProcess(gcArxPath+"pack.bat"+" "+gcOutPutPath + ALLTRIM(lcNamePak) + " " + ALLTRIM(lcTemplate)+ ".dbf",gcArxPath)

* (0 - если Ошибка, 1- все в норме)

DELETE FILE (gcArxPath + ALLTRIM(lcTemplate)+'.dbf')

RETURN lnReturn

Функция определения имени таблицы пакета

На входе - Id Типа пакета

На выходе - Имя шаблонаfncGetTemplatelnIdType as IntegerlcTemplate as String !USED('TypePackets')(gcDataPath + "TypePackets.dbf") IN 0 ALIAS TypePacketsTypePacketsFOR TypePackets.TypeId = lnIdTypeFOUND()= TypePackets.TemplateIN TypePacketslcTemplate

Функция регистрации пакета в журнале и отметка о статистике по запросам

На входе - Id Типа пакета, полное имя пакета, алиас таблицы

На выходе - Id ПакетаfncGetRegPacket

LPARAMETERS lnNamePak as String, lnType as Integer, lcAlias as StringlnId!USED('Packety')(gcDataPath + "Packety.dbf") IN 0 ALIAS PacketyINTO Packety (Name, TypeID) VALUES (lnNamePak, lnType)BOTTOM in Packety= Packety.PacketIdIN Packety!USED('Queryes')(gcDataPath + "Queryes.dbf") IN 0 ALIAS QueryeslnId as packetid, numq, COUNT(*) FROM &lcAlias GROUP BY 1,2 INTO CURSOR curINTO queryes (PacketId, Numq, AmountNumq) SELECT * FROM curIN curIN Queryes

RETURN lnId

Функция генерации имени пакета

На входе - нет ничего

На выходе - полное имя пакета

FUNCTION fncGetNamePaklnNum as Integer, lcYMD as StringlcType as String= fncGetTypePacket(gnIDTypeIn)PADL(gcSMO,5,"0") + ALLTRIM(lcType) + ALLTRIM(STR(lnNum)) + "." + ALLTRIM(lcYMD)

Функция определения типа исходящего пакета

Входной параметр - Id Типа

На выходе - типfncGetTypePacketlnId as IntegerlcType as String= ""!USED('TypePackets')(gcDataPath + "TypePackets.dbf") IN 0 ALIAS TypePacketsTypePacketsFOR TypePackets.TypeId = lnIdFOUND()= TypePackets.TypeIN TypePacketslcType

Функция перевода даты в формат ГМД

На входе - дата

На выходе - ГМД

FUNCTION fncDateToYMDldDate as DateldYear,;,;as Integer,;as StringDECIMALS TO 0= VAL(RIGHT(STR(YEAR(DATE())),2))= MONTH(ldDate)= DAY(ldDate)= fncSystem32(ldYear) + fncSystem32(ldMonth) + fncSystem32(ldDay)

RETURN lcYMD

Функция перевода каждого числа даты в число по сч 32

На входе - часть даты

На выходе - часть даты в сч 32

Продолжение приложения 1fncSystem32lcPartDate as Integer lcPartDate >= 1 AND lcPartDate <= 9 THEN= ALLTRIM(STR(lcPartDate))lcPartDatelcPartDate > 9 THEN

RETURN CHR(65 + (lcPartDate - 10))

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

На входе - дата

На выходе - номер

FUNCTION fncGetNextPakNumldDate as DatelnRetVal as Integer !USED('ForNamePak')(gcDataPath + "ForNamePak.dbf") IN 0 ALIAS ForNamePakForNamePakFOR ForNamePak.DateGen = ldDateFOUND()= ForNamePak.NumBLANKDateGen WITH ldDate,;WITH 0 IN ForNamePak= ForNamePak.NumlnRetVal >= VAL(gcAmountPak)0ForNamePakFOR ForNamePak.DateGen = ldDateFOUND()= lnRetVal + 1Num WITH lnRetVal IN ForNamePakIN ForNamePaklnRetValShellExecutelcCmdName as StringLong ShellExecute IN Shell32.dll Long hwnd, String Operation, String File,;parameters, String Directory, Integer ShowCmdlnReturn as Integer= ShellExecute(0, "open", lcCmdName,.null.,.null., 1)

RETURN lnReturn

Приложение 2

Листинг файла main.prg

CLOSE ALL

*SET STEP ON prcSettingDATABASE (gcDataPath + "exchange.dbc") SHAREDSHUTDOWN do prcExitApp

_screen.Visible =.T.

_screen.Caption = "Обмен информацией с ЕМСР"

_screen.WindowState = 2

_screen.Icon = (gcIcoPath + "snow.ico")

_screen.MaxButton =.F.

_screen.MinButton =.F.

_screen.Picture = (gcIcoPath + "PIC.JPG")(gcMenuPath + "CustomMenu.mpr")Tray as Object,;as Object= CREATEOBJECT("systray.MyTray").systray1.iconfile = (gcIcoPath + "snow.ico")

Tray.systray1.tiptext = "Обмен информацией с ЕМСР"

goTimer = CREATEOBJECT("MyTimer.MyTimer").init()EVENTSprcSetting, gnIDTypeOut as Integer= 1=2SAFETY OFF TALK OFFDATE GERMANDECIMALS TO 0lcStr as String!FILE(ADDBS(application.DefaultFilePath) + "Setting.dbf")

MESSAGEBOX ("Отсутствует файл с настройками программы",0,"Error")

DO prcExitApp(ADDBS(application.DefaultFilePath) + "Setting.dbf") IN 0 ALIAS Setting EXCLUSIVESettingALL= "PUBLIC " + ALLTRIM(Setting.VarName) + " AS STRING "

Продолжение приложения 2

&lcStr= ALLTRIM(Setting.VarName) + "='" + ALLTRIM(Setting.VarValue) + "'"

&lcStrIN SettingLIBRARY TO (gcProgPath + "mdlPackets.prg") ADDITIVELIBRARY TO (gcProgPath + "tasks.prg") ADDITIVECLASSLIB TO (gcClassPath + "systray.vcx") ALIAS systray ADDITIVECLASSLIB TO (gcClassPath + "myforms.vcx") ALIAS myforms ADDITIVECLASSLIB TO (gcClassPath + "mytimer.vcx") ALIAS mytimer ADDITIVEprcExitAppTABLES ALLDATABASES ALLALLEVENTS

QUIT

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

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

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

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

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

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

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

2.2 Разработка алгоритмов

2.4 Разработка процедур и функций приложения

3. Технико-экономическое обоснование разработки ПО

3.1 Расчет затрат на разработку ПО

3.2 Расчет цена разработанной программы

3.4 Расчет эксплуатационных расходов

3.7 Выводы

4.1.1 Излучение электромагнитных полей

4.1.2 Шум

4.1.3 Микроклимат

4.1.4 Электробезопасность

4.2 Мероприятия по устранению опасных и вредных производственных факторов

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