База знаний студента. Реферат, курсовая, контрольная, диплом на заказ

Министерство общего и профессионального образования РФ

Курсовой проект

По дисциплине: «Проектирование экономических информационных систем»

На тему: «Проектирование АРМ сотрудника отдела автоматизации информационного обеспечения Ивановского филиала ФОМС»

Выполнила:

Руководитель:

Содержание

Введение

1. Экономический анализ ФОМС

1.1 Краткая экономическая характеристика ФОМС

1.2 Обоснование целесообразности автоматизации функций

2. Разработка АРМ сотрудника отдела АИО ФОМС

2.1 Техническое задание

2.2 Постановка и алгоритм решения комплекса задач

2.2.1 Характеристика комплекса задач

2.2.2 Выходная информация

2.2.3 Входная информация

2.2.4 Описание алгоритма решения задачи

2.2.5 Требования к контрольному примеру

2.3 Программная реализация

Заключение

Список использованных источников

Приложения

Введение

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

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

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

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

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

- устаревшие аппаратные и программные средства

- низкая скорость обработки поступающей информации

- отсутствие способа передачи информации по сети

- чрезмерная сложность интерфейса пользователей

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

Данный курсовой проект содержит две основные части -аналитическую и проектно-расчетную, а так же введение и заключение.

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

Во второй части представляются проектные решения построения АРМа. Приводятся входная и выходная информация. Содержится постановка и алгоритм решения комплекса задач, а так же их машинная реализация. Здесь же приводится методика расчета показателей экономической эффективности.

Выводы и рекомендации изложены в заключении.

1. Экономический анализ ФОМС

1.1 Краткая экономическая характеристика ФОМС

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

ОМС появилось в России еще в 1912 г., но после Октябрьской революции было свернуто в связи с переводом системы здравоохранения на бюджетное финансирование. После принятия Закона № 4741-1 от 02.04.93 «О медицинском страховании граждан в Российской Федерации» развитие ОМС стало важнейшей гарантией обеспечения ст. 41 Конституции РФ, провозглашающей право граждан на бесплатную медицинскую помощь.

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

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

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

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

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

Коллектив фонда состоит из высококвалифицированных специалистов, нацеленных на поиск оптимальных управленческих решений и постоянно повышающих свою профессиональную квалификацию. Около 88% сотрудников исполнительной дирекции и 71% всех работников фонда имеют высшее и незаконченное высшее образование, преимущественно экономическое, медицинское и юридическое. Многие сотрудники получили два высших образования и имеют высокую профессиональную квалификацию по профилю своей деятельности. Высокий кадровый потенциал фонда, безусловно, стал одним из важнейших факторов, обеспечивших позитивные результаты его 10-летней деятельности.

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

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

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

Территориальный фонд обязательного медицинского страхования по Ивановской области создан решением Малого совета Ивановского областного Совета народных депутатов № 63 от 25.03 1993 г. "О территориальном фонде обязательного медицинского страхования Ивановской области" и действует на основании "Положения о территориальном фонде ОМС".

Структура обязательного медицинского страхования в Ивановской области в 2002 году была представлена Территориальным фондом обязательного медицинского страхования, 12 филиалами, 8 представительствами, 58 лечебно-профилактическими учреждениями.

Постановлением Главы администрации Ивановской области от 06.08. 1999 года № 501 функции страховщика возложены на Территориальный фонд обязательного медицинского страхования по Ивановской области. Страховые медицинские компании, имеющие лицензии па право проведения ОМС на территории Ивановской области, отсутствовали.

Общая структура системы медицинского страхования показана на рис.1:

… и т.д.

Рисунок 1. Структура системы медицинского страхования

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

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

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

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

Рисунок 2. Схема управления отделения ФОМС Ивановской области

Рассмотрим подробнее отдел АИО ФОМС. Он включает в себя:

- группу системных программистов

- группу программистов прикладных программ

- сотрудника по работе с лечебными учреждениями Иванова и области

- группу технического снабжения и отладки оборудования

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

1.2 Обоснование целесообразности автоматизации функций

Необходимость проектирования АРМ для данной системы определяется целым рядом весомых причин, основными из которых являются:

1) обеспечение целостности данных, разделения данных, безопасности, производительности, стандартного способа доступа;

2) в данном случае АРМ – это не просто механизм хранения и поиска информации, но также система, способная поддерживать сложные информационные технологии, решать такие проблемы как: ведение больших баз данных, поддержка распределенных БД, интегрирование в уже существующие и работающие информационные системы, и в будущем – состоящая из множества узлов вычислительной сети;

3) моральное и не редко «физическое» старение ранее существовавших систем (архаичные алгоритмы решения задач, использование устаревших языков программирования и СУБД, а также комплексы ЭВМ, на которых они основаны);

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

5) необходимость перехода данной информационной подсистемы на единую систему управления реляционными базами данных (например, на основе корпоративной информационной системы Oracle), для большей стандартизации работ всех филиалов Российской системы ОМС;

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

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

Создание подобного программно-технического комплекса предполагает достижение решение следующих задач:

1) разработка, создание и ведение базы данных;

- формирование запросов к базе данных;

- разработка и отладка программных модулей комплекса задач АРМ;

- оценка проектных решений АРМ по критериям эффективности, быстродействия, надёжности и стоимости;

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

3) разработка комплекса прикладных программ сопровождения, полностью покрывающих данную задачу (и в последствии – другие задачи);

4) автоматизировать формирование выходных документов;

6) информационное объединение всех служб ТФОМС и обеспечение возможности доступа к любой из них.

Отметим цели создания АРМ:

- повышение оперативности реализации запросов;

- снижение трудоемкости обработки информации;

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

- повышение качества контроля входной и выходной информации;

- автоматизация проведения расчетов.

2. Разработка АРМ сотрудника отдела АИО ФОМС

2.1 Техническое задание

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

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

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

1. Физическая неспособность ВСЕХ лечебных учреждений проводить такой контроль, как, собственно, и любую другую задачу, требующую большой производительности. Так, например, если запустить программный код разрабатываемой системы на компьютере типа DELL-386AT (основная техническая база), то программа успешно выполнит все действия спустя 3 дня с момента запуска при условии бесперебойной работы компьютера в автоматическом режиме без вмешательства пользователя-контролера.

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

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

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

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

Процессор – с тактовой частотой не ниже 2 ГГц, например

AMD ATHLON XP 2500+ или Intel Pentium 2.3 ГГц

Оперативная память – 512 Mb

Видео система– Монитор SVGA 15’’ и совместимая видеокарта.

Например платы от компании NVidea – GeForce-4 MX-440

Модем – любой современный USB или PCI модем, например ZyXEL.

Устройство чтения компакт-дисков CD-ROM – только при начальной установке программного обеспечения и отладке системы

Также обязателен источник бесперебойного питания UPS.

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

Перечень автоматизируемых функций:

Контроль наличия входной информации – Код 0101

Первичная подготовка таблиц исходных данных – Код 0201

Проверка сводного счета по коду ЛПУ и номеру счета – Код 0301

Проверка о взаиморасчетах между территориями – Код 0302

Контроль поводов посещения и услуг ЛПУ – Код 0303

Поиск и устранение записей дубликатов – Код 0401

Проверка иногородних пациентов – Код 0501

Контроль по срокам предоставления счетов к оплате – Код 0502

Формирование выходных документов – Код 0601

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

Таблица 1

Перечень автоматизируемых функций

Код функции	Наименование	Входная информация	Выходная информация	Получатель
0101	Контроль наличия входной информации	Код ЛПУ, Дата, Номер счета, Серия полиса, Номер полиса, ФИО, Дата рождения, Адрес, Место работы, Телефон …	Код ЛПУ, Дата, Номер счета, Серия полиса, Номер полиса, ФИО, Дата рождения, Адрес, Место работы, Телефон …	0201
0201	Первичная подготовка таблиц исходных данных	См. 0101	См. 0101	0301 0302 0303
0301	Проверка сводного счета по коду ЛПУ и номеру счета	См. 0101	См. 0101	0201 0401
0302	Проверка о взаиморасчетах между территориями	См. 0101	См. 0101	0201 0401
0303	Контроль поводов посещения и услуг ЛПУ	См. 0101	См. 0101	0201 0401
0401	Поиск и устранение записей дубликатов	См. 0101	См. 0101	0501 0502
0501	Проверка иногородних пациентов	См. 0101	См. 0101	0601
0502	Контроль по срокам предоставления счетов к оплате	См. 0101	См. 0101	0601
0601	Формирование выходных документов	См. 0101	-	Передача в единую базу по модему

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

2.2 Постановка и алгоритм решения комплекса задач

2.2.1 Характеристика комплекса задач

Отметим цели создания комплекса задач:

- повышение оперативности реализации запросов;

- снижение трудоемкости обработки информации;

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

- повышение качества контроля входной и выходной информации;

- автоматизация проведения расчетов.

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

1) разработка, создание и ведение базы данных;

- формирование запросов к базе данных;

- разработка и отладка программных модулей комплекса задач АРМ;

- оценка проектных решений АРМ по критериям эффективности, быстродействия, надёжности и стоимости;

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

3) разработка комплекса прикладных программ сопровождения, полностью покрывающих данную задачу (и в последствии – другие задачи);

4) автоматизировать формирование выходных документов;

6) информационное объединение всех служб ТФОМС и обеспечение возможности доступа к любой из них.

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

Естественно, что в данном случае предъявляются особо жесткие требования к техническому и программному обеспечению.

2.2.2 Выходная информация

В рамках АРМ выходные сообщения могут выдаваться как в виде документов-отчетов работы, так и в виде отдельных файлов – массивов данных.

На бумажный носитель (при необходимости) переносится следующая информация:

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

2. Отчет о наличие ошибок в исходных базах данных в разрезе каждого этапа технологии обработки информации.

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

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

1. Единая информационная база застрахованных лиц по Ивановской области.

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

Выходная информацию представлена ниже в таблице 2.

Таблица 2

Описание выходных сообщений

Наименование выходного сообщения	Идентифи-катор	Форма представления	Период выдачи	Срок выдачи	Получатель	Макс. число строк
Отчет о текущем состоянии Центральной БД	Д060101	Документ	Ежене-дельно	В начале рабочей недели	Центральное Управление ФОМС	100
Отчет наличия ошибок в БД	Д060102	Документ	Ежене-дельно	В начале рабочей недели	Центральное Управление ФОМС	1 000
Служебная информация	Д060103	Документ	Ежедне-вно	При необходимости	Главный программист	100
Единая БД граждан	М060104	Массив	Ежене-дельно	В начале рабочей недели	Центральное Управление ФОМС	1 500 000
Перечень некорр записей в БД	М060105	Массив	Ежене-дельно	В начале рабочей недели	Центральное Управление ФОМС	1 000

Описание составных единиц информации в выходных сообщениях приведено ниже в таблице 3. Следует отметить, что во всех представленных документах общее количество СЕИ превышает 200, и рассмотреть их все не представляется возможным. Поэтому ниже представлены описания только основных реквизитов документов.

Таблица 3

Описание структурных единиц информации выходных сообщений

Наименование единиц информации	Обозначение	Идентификатор	Длина в знаках	Диапазон изменения
Код ЛПУ	KOD_LPU	Д060102, М060104, М060105	9(3)	1-999
Дата передачи счета	DAT_SC	М060104, М060105	9(8)	-
Номер счета	N_CH	М060104, М060105	9(10)	1-9999999999
Серия полиса	SER_POL	М060104, М060105	9(6)	1-999999
Номер полиса	NOM_POL	М060104, М060105	9(10)	1-9999999999
Фамилия	FAMIL	Д060102, М060104, М060105	A(25)	-
Имя	IMYA	Д060102, М060104, М060105	A(20)	-
Отчество	ОТ	Д060102, М060104, М060105	A(20)	-
Дата рождения	D_R	М060104, М060105	9(8)	-
Время рождения	TIME_R	М060104, М060105	А(5)	-
Масса	VES	М060104, М060105	9(4)	1-9999
Район	RAION	М060104, М060105	9(3)	1-999
Населенный пункт	NAS_P	М060104, М060105	9(4)	1-9999
Категория работающего	KATEGOR	Д060102, М060104, М060105	9(1)	1-9
Место работы	MES_R	Д060102, М060104, М060105	А(80)	-
Профиль отделения	OTD	М060104, М060105	А(2)	-
Профиль койки	PROFIL	М060104, М060105	А(3)	-
Номер истории болезни или карты	N_KART	М060104, М060105	А(8)	-
Диагноз направившего учреждения	DIA_NAPR	М060104, М060105	А(6)	-
Диагноз основной	DIA_O	М060104, М060105	А(6)	-
Диагноз сопутствующий	DIA_S	М060104, М060105	А(6)	-
Диагноз осложнений	OSL	М060104, М060105	А(6)	-
Продолжите льность лечения	DL_LEC	Д060102, М060104, М060105	9(3)	1-999
Исход лечения	ISH_LEC	Д060102, М060104, М060105	9(2)	-
Стоимость лечения	STOIM	Д060102, М060104, М060105	9(10),2	-
Дата поступления в стационар	DAT_VV	М060104, М060105	9(8)	-
Время поступления в стационар	VR_VV	М060104, М060105	А(6)	-
Дата выписки	DAT_PR	Д060102, М060104, М060105	9(8)	-
Время смерти	TIME_SM	Д060102, М060104, М060105	А(5)	-
Принадлежность к инвалидности	OS_PRIZ	М060104, М060105	9(2)	1-99
Направившее учреждение	NAP_LPU	М060104, М060105	9(4)	1-9999
Уровень качества лечения	UKL	Д060102, М060104, М060105	9(4),2	-
Вид оплаты	IV	Д060102, М060104, М060105	9(2)	-
Признак страхования	PR_STR	Д060102, М060104, М060105	9(1)	1-2
Серия паспорта	SER_DOK	М060104, М060105	А(10)
Номер паспорта	NOM_DOK	М060104, М060105	9(4)	1-9999

2.2.3 Входная информация

Входными сообщениями для АРМ являются:

1. Базы данных застрахованных лиц по всем лечебным учреждениям города и области (в том числе БД ЛПУ и БД полисов граждан).

2. Тарифы для межтерриториальных взаиморасчетов.

Входная информацию представлена ниже в таблице 4.

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

Таблица 4

Описание входных сообщений

Наименование выходного сообщения	Идентификатор	Форма представления	Период полступления	Срок поступления	Источник	Макс. число строк
Базы данных полисов граждан и ЛПУ по всем ЛПУ области	М010101	Массив	Еженедельно	В начале рабочей недели	ЛПУ города и области	100 000
Тарифы для межтерриториальных взаиморасчетов	М010102	Массив	Ежемесячно	В начале месяца	Центральное Управление ФОМС	1 000

Таблица 5

Описание структурных единиц информации входных сообщений

Наименование единиц информации	Обозначение	Идентификатор	Длина в знаках	Диапазон изменения
Код региона	REGION	М010102	9(3)	1-999
Код главного ЛПУ	GLAV	М010102	А(5)	-
ЛПУ символы	LPU	М010102	A(5)	-
ЛПУ числа	LPU_N	М010102	A(5)	-
Путь рассылки	PATH	М010102	A(30)	-
Номер ЛПУ	NLPU	М010102	9(3)	1-999
Код района	RAI	М010102	9(3)	1-999
Категория населения	KATEGOR	М010102	9(1)	1-9
Расшифровка	FULL	М010102	A(10)	-
Наименование	NAIM	М010102	A(25)	-
Код услуги	KODUSL	М010102	A(4)	-
Тариф старый	TARIF	М010102	9(7),2	-
Тариф новый	TARIF_N	М010102	9(7),2	-
Дата смены тарифа	DATE	М010102	9(8)	-
Тип договора	GOG_YN	М010102	9(1)	1-9
Профиль отделения	PROFIL	М010102	A(2)	-
Уровень качества лечения	UKL	М010102	9(4),2	-
Вид оплаты	IV	М010102	9(4)	-
Признак страхования	PR_STR	М010102	9(1)	1-2
Вид графика	GRAFIK	М010102	A(5)	-
Код диагноза	KOD	М010102	A(8)	-
Код отказа	NEC	М010102	9(2)	1-99
Территория страхования	TERR_STR	М010102	9(4)	-

2.2.4 Описание алгоритма решения задачи

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

Рисунок 4. Технология обработки информации

Все каталоги, с которыми работает программа настраиваются в самой программой. Входными файлами для задачи являются архивы счетов ЛПУ, которые имеют вид Ln???.ARJ, где n=1,2,4. (1-стационар, 2 – поликлиника, 4- стоматология). ??? – код ЛПУ.

Архив счета стационара должен содержать файлы вида L1???.DBF,I1???.DBF,O1???.DBF, где ??? – код ЛПУ. База L1???.DBF содержит основную информацию о пролеченных в стационаре, I1???.DBF содержит дополнительную информацию о гражданах, застрахованных в других регионах, но пролеченных в ЛПУ Ивановской области, а файл O1???.DBF включает в себя дополнительную информацию о проведенных операциях.

Архив счета поликлиники должен содержать файлы вида L2???.DBF,I2???.DBF,L2???_US.DBF, архив счета стоматологии должен содержать файлы вида L4???.DBF,I4???.DBF,L4???_US.DBF,

При входном контроле может быть сформирован текстовый файл вида P?nnn.TXT, содержащий ошибки по полисам контролируемого счета. Текстовый файл помещается в M:\AIO=SCHT\OUT вместе с конвертом для рассылки.

После входного контроля программой DecodSch может быть дополнительно создана БД отбракованных записей счета в виде B?nnn.DBF, где ? = ( 1 - стационар, 2 – поликлиника, 4 – стоматология), nnn – код ЛПУ.

Причем БД после входного контроля уже подготовлены для переноса на ORACLE, поэтому не желательно их просматривать с помощью FOXPRO или программ, написанных на нем, т.к. FOXPRO нередко изменяет кодовую страницу открытых БД. В этом случае при переносе могут быть проблемы с русскими буквами в символьных строках ('асмимти' à ‘######’). Далее осуществляется перенос информации на ORACLE. Для этого информация переписывается в алиас TOORA(D:\DATA\TOORA) в соответствующие БД, но информация хранится уже не в DOS, а в WINDOWS-кодировке и затем переносится на ORACLE-сервер. При завершении переноса формируется файл вида M?nnnsss.LPU, где ? =( 1 - стационар, 2 – поликлиника, 4 – стоматология), nnn – код ЛПУ, sss – номер счета.

Он содержит информацию о результатах автоматической проверки счета. В случае получения повторного счета также формируется аналогичный файл с сообщением «Повторный сводный счет – ОТКЛОНЕН !!!» . Пустые счета просто удаляются из обработки.

Теперь подробнее о контроле счетов «Поликлиника» (аналогично работают алгоритмы для счетов «Стоматология» и «Стационар)».

Алгоритм работы программы:

Осуществляется проверка наличия файлов (MAIN.PAS, процедура actFindFilesExecute).

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

Проверка сводного счета по коду ЛПУ, дате счета и номеру счета. Если представлен повторный сводный счет, то формируется текстовый файл по результатам автоматической проверки с сообщением «Повторный сводный счет - ОТКЛОНЕН !!!» (MAIN.PAS, процедура actSvodSchetExecute)

Проверки в соответствии с письмом № 07-2194 от 06.09.2000 года (для выполнения приказа № 70 ФФОМС о взаиморасчетах между территориями) (MyFunc.PAS,процедура New_cntrl_amb) если в поле «Категория» стоит «Работающий», то поле «Место работы» должно быть обязательно заполнено.

Обязательно должна быть введена информация либо о полисе пациента, либо его паспортные данные.

Если нет информации о полисе пациента, то должно быть заполнено поле «Особый случай»

Если в поле «Особый случай» заполнено «Медпомощь новорожденному» или «Документ родителя», то обязательно должны быть заполнены поля «Фамилия», «Имя», «Отчество» родителя или опекуна

Если в поле «Особый случай» заполнено «В документе отсутствует отчество», то поле «Отчество» должно быть пустым для отделенческой больницы все записи о пролеченных больных-жителей Ивановской области отправляются в некорректные

Проверка на соответствие поводов посещения и услуг в соответствии с письмом от 30.11.1998 года. (MAIN.PAS, процедура ActAmbCtrlUslExecute)

Проверка иногородних пациентов не является ли они иностранцами (их мы не оплачиваем). (MyFunc.PAS, процедура Del_States)

Контроль по срокам представления счетов к оплате. В представленном счете дата последней услуги, оказанной пациенту должна быть не позднее 3-х месяцев от даты формирования счета. Также в счете не должно быть услуг с датой услуги, относящейся к будущим плановым периодам (MyFunc.PAS, процедура Date_cntrl_amb).

Не должно быть записей-дубликатов в основном файле представленного счета . (MAIN.PAS, процедура ActAmbDoubleStrExecute)

Проверка заполнения требуемых полей. В основной базе обязательно должны быть заполнены поля «Фамилия», «Дата рождения», «Категория», «Повод посещения» «Основной диагноз», «Случай», «Стоимость». В БД иногородних обязательно должны быть заполнены те же поля, что и в основной БД, а также информация о полисе пациента или его паспортные данные. (MAIN.PAS, процедура ActAmbReqFieldsExecute)

Проверка кода основного диагноза по МКБ, а также проверка на правильность сочетания основного диагноза и повода посещения . Кроме того не оплачиваются пациенты старше 18 лет с некоторыми диагнозами (см. записку отдела КТиСМП от 19.10.2000 года) (MAIN.PAS, процедура actFindDiagORAExecute).

Проверка посещений. Не должно быть случаев преставления счетов на два посещения к одному врачу пациента в тот же день. Внутри одного талона не должно быть дубликатных услуг (MAIN.PAS, процедура actAmbOneToOneExecute).

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

Сравнение с архивом. Для данного ЛПУ проверяется по номеру талона, фамилии, имени и отчеству пациента наличие информации в архиве ранее предъявленных счетов к оплате. Кроме того, не должно быть двух посещений к одному врачу в тот же день в текущем счете и в архиве.(MAIN.PAS, процедура actAmbCompArcORAExecute)

Проверка стоимости оказанных медицинских услуг. (MyFunc.PAS, процедура AMB_Stoim)

Для наглядности алгоритм работы программы представлена следующей блок-схемой (рисунок 5).

Проверка на соответствие поводов посещения и услуг

Проверка заполнения требуемых полей

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

Проверка посещений

Проверка полиса пациента по областной БД

Обеспечение целостности данных

Рисунок 5. Алгоритм работы АРМ

2.2.5 Требования к контрольному примеру

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

- 2 и более БД от лечебных учреждений города и области

- Часть единой информационной базы данных. Для полноты представления контрольного примера необходимо как минимум 1 000 записей.

Данный объем информации позволяет оценить все возможности системы. Основные требования к контрольному примеру:

- использование реальной информации и в реальных объемах. На этих данных производится контроль полноты и правильность производимых расчетов и сформированных баз данных;

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

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

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

Часть используемых алгоритмов, а также примеры выходных сообщений представлены в приложении.

2.3. Программная реализация

Для оптимальной работы АРМ необходимо использование следующей архитектуры персонального компьютера:

Аппаратные средства:

Компьютер на базе процессора Intel Pentium 3 (1 GHz) или AMD Athlon 1600 XP или выше.

Оперативная память: не менее 256 Mb (рекомендуется 512 Mb) или выше.

Объем жесткого диска: не менее 40 Gb.

Программные средства:

Операционная система Windows 98, NT, 2000, XP

BDE Administrator (прилагается к системе программирования Delphi 7)

Oracle для Windows 98, NT

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

Любая современная СУБД (FoxPro, Clarion, Paradox и др.) позволяющая использовать формат dbf для создания баз данных.

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

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

Общие замечания по входному контролю счетов ЛПУ. На начало практики планировалась следующая схема работы этой программы: рано утром автоматически включается ROBOT(сервер), загружается программа обработки счетов ЛПУ и она запускает программу переноса БД полисов на ORACLE. А программа обработки счетов начинает работать автоматически согласно составленному расписанию и проверяя наличие флага отсутствия питания от UPS ( файл C:\POWERFLG\POWER.FLG). Сейчас действует переходный вариант к этой модели работы : при запуске программы обработки счетов ЛПУ устанавливается флаг автоматической обработки, осуществляется проверка запуска переноса БД полисов на ORACLE и если его не было в последние сутки, то он автоматически запускается, а по завершении переноса флаг автоматической обработки снимается.

О проблемах и ошибках программы, а также их устранении.

Контроль счетов поликлиник и стоматологий иногда завершается с ошибкой “Index iN_KART not found…”. При контроле поликлиники эта ошибка была лишь один раз за все время практики, в стоматологии - 2-3 раза в неделю. Похоже эта ошибка BDE при выполнении запросов (DBASE + ORACLE). Как правило это случается при контроле либо большого счета стоматологии, либо большого и маленького счета одновременно. При ручном запуске обработки счетов я стремился в стоматологии подбирать счета примерно одного размера. Если случилась эта ошибка, то обрабатываемые счета из каталога D:\DATA\STO (D:\DATA\AMB) удалить и повторить входной контроль.

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

Далее необходимо очистить соответствующие таблицы в D:\DATA\TOORA. Это можно сделать программно, но я просто копирую нужные пустые БД из соответствующего каталога. Каталог C:\TODAY\TOORA имеется на моем компьютере и на ROBOT-е. После того, как все следы неудачного переноса удалены, можно повторить перенос.

Если при контроле счетов появилась ошибка “Access violation …” , то повторите контроль счетов, предварительно удалив неудачно обработанные счета. Если ошибка повторяется вновь, то смотрите исходный текст программы.

Заключение

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

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

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

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

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

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

- классификация данных;

- определение прав доступа отдельных пользователей и ограничений на характер операций;

- организация системы контроля доступа к данным;

- тестирование средств защиты;

- прочие работы по защите системы.

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

Список использованных источников

1. «Итоги научно-практической конференции, посвященной 10-летию системы обязательного медицинского страхования» - Медицинская газета №44 20.06.2003 Иваново 2003г.

2. «ОМС: реальность и перспективы» - Медицинская газета №68 12.09.2003 Иваново 2003г.

3. «Методические подходы к формированию сочетанных и многоуровневых программ медицинского страхования в современных условиях» - В.В. Петухова, М.В. Айвазова и др. – Санкт-Петербургский институт медицинского страхования М. 2001г.

4. «Работа системы ОМС Ивановской области по реализации программы государственных гарантий обеспечения бесплатной медицинской помощью граждан РФ в 2002 году. Задачи на 2003 год (Сборник научных трудов)» - Территориальный фонд ОМС по Ивановской области, Управление здравоохранения Ивановской области, Ивановская государственная медицинская академия – Иваново 2003г.

5. «Проектирование баз данных (Учебное пособие)» - В.Г. Шишкин – Ивановский государственный университет – Иваново 1999г.

6. «Налоги. 4-е издание (учебное пособие)» - Д.Г. Черник и др. – «Финансы и статистика» - М. 1999г.

7. «Справочное руководство по языку SQL» - Andrew Mendelsohn, Ken Jacobs и др. – Нью-Йорк 1999г.

8. «Руководство администратора базы данных ORACLE» - Sanjay Bulchandani, Dennis Cochran и др. - Нью-Йорк 1996г.

9. «Проектирование баз данных в примерах и задачах» - Т.И. Гусева - М. 1992г.

10. «Компьютерные системы в управлении финансами» - А.П. Колесник - М.: "Финансы и статистика" 1997г.

Приложение №1

Пример распечатки счета в режиме «Стационар»

Лечебное учреждение Родниковская ЦРБ счёт № 01 [стационар]

Дата счёта 05.02.2001

Дата принятия счёта 06.02.2001

Номер карты 999000

Фамилия ВОРОНЦОВ

Имя СЕРГЕЙ

Отчество ЕВГЕНЬЕВИЧ

Адрес Родниковский район г.Родники Мк-н Шагова д.16 кв.53

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

Полис 0

Вид направления Поступил по СМП

Категория работающего Работающий СП

Место работы РУП

Профиль койки Хирургические взросл. Т06.3

Диагноз основной Повреждения кровеносных сосудов, захватывающие несколько областей

тела

Диагноз сопутствующий S21.1 Открытая рана передней стенки грудной клетки

Диагноз осложнения R57.8 Другие виды шока Экстренная, первичная

Госпитализация Экстренная, первичная

Дата поступления 28.12.2000 01.01.2001

Время поступления 22.10

Дата выписки 01.01.2001

Длительность лечения 4

Случай обслуживания Законченный

Исход лечения Летальный исход

Специальность врача ВРАЧ-ХИРУРГ

Стоимость Операции: 429,72

Дата	Наименование
28.12.2000	Z38.93 Катетеризация вены др.
28.12.2000	Z46.73 Сшивание разрыва тонкой кишки (кроме 12-перстной кишки)
28.12.2000	Z39.31 Наложение шва на артерии
29.12.2000	Z38.08 Рассечение артерии нижней конечности

Диагноз непосредственной причины смерти:

J81. Легочный отек Диагноз заболевания, обусловивший причину смерти:

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

R57.8 Другие виды шока Диагноз патологоанатомический:

Т06.3 Повреждения кровеносных сосудов, захватывающие несколько областей тела

Приложение № 2

Пример распечатки счета в режиме «Поликлиника»

Лечебное учреждение Городская клин, б-ца N7 счёт N'87 [поликлиника]

Дата счёта 05.02.2001

Дата принятия счёта 07.02.2001

Фамилия АВЕРЬЯНОВ

Имя БОРИС

Отчество АЛЕКСЕЕВИЧ

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

Полис 372400 4006580726

Адрес г.Иваново ул.Лежневская д.156 кв.18

Категория работающего Пенсионер

Место работы

Повод обращения Лечебно-диагностический

Длительность лечения 11

Диагноз основной l6. Коксартроз [артроз тазобедренного сустава]

Случай обслуживания Законченный

Исход лечения направление к др. врачу

Стоимость 9,2

Доп. Информация к физиотерапевту

№	Дата	Наименование услуги	Специальность врача
1	03.01.2001	Лечебно-диагностический приём	Врач-хирург
2	09.01.2001	Лечебно-диагностический приём	Врач-хирург
3	11.01.2001	Лечебно-диагностический приём	Врач-хирург
4	13.01.2001	Лечебно-диагностический приём	Врач-хирург

Приложение №3

Пример распечатки счета в режиме «Стоматология»

Лечебное учреждение Городская клин, б-ца N7 счёт № 11 [стоматология]

Дата счёта 05.02.2001

Дата принятия счёта 07.02.2001

Фамилия АНДРИАНОВА

Имя ИРИНА

Отчество АЛЕКСАНДРОВНА

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

Полис 372400 7008281152

Адрес г.Иваново ул.Воронина д.З кв.47

Категория работающего Работающий

Место работы Школа-лицей № 67

Повод обращения лечебно-диагностический

Длительность лечения 1

Случай обслуживания Законченный

Исход лечения выздоровление

Стоимость 2,5

Дата	Услуги	Стоимость	Диагноз
31.01.2001	Осмотр полости рта первичного больного.	0,15
31.01.2001	Сбор анамнеза.	0,15
31.01.2001	Оформление документации первичного больного.	0,2	Кариес зубов не уточненный
31.01.2001	Цементная пломба на две поверхности зуба	2	Кариес зубов не уточненный

СУММА (УЕТ) = 2,5

Приложение №4

Наименование и структура основных справочников.

1. ORACLE:KIS.SVSCHET -справочник сводных счетов ЛПУ

2. ORACLE:SNMDN_ST -справочник видов дневного стационара

3. ORACLE:SNMGRAFIK -справочник графиков дн.стационаров ЛПУ

4. ORACLE:SNMGRUP -справочник группировки ЛПУ.

5. ORACLE:SNMKAT -категории населения при проверке стационара

6. ORACLE:SNMKAT1 -категории населения при проверке поликлиники

7. ORACLE:SNMMKB -справочник диагнозов

8. ORACLE:SNMMKB_N -справочник взаимосвязей поводов и услуг

9. ORACLE:SNMMKB_O -справочник ятрогении

10 ORACLE:SNMNAPRAV -справочник направлений

11. ORACLE:SNMPO_TAR - тарифы поликлиник , работающих по полной программе

12. ORACLE:SNMPO_TAR_C -тарифы поликлиник , работающих по неполной программе

13. ORACLE:SNMST_TAR -тарифы стационаров , работающих по полной программе

14. ORACLE:SNMST_TAR_C -тарифы стационаров, работающих по неполной программе

15. ORACLE:SNMPROFIL -справочник профилей коек

16. ORACLE:SNMSCOB -справочник целей обращения

17. ORACLE:SNMSPR_INV -справочник видов инвалидности

18. ORACLE:SNMSPR_LPU -справочник ЛПУ

19 ORACLE:SNMSPR_OTK -справочник отказов

20. ORACLE:SNMSPUSL -справочник услуг стоматологии

21. ORACLE:SNMSPL -справочник исходов лечения

22. ORACLE:SNMTARIF1 -справочник специальностей врачей

23. ORACLE:SNMUSLUGI -справочник услуг

24. ORACLE:SNMYEAR -календарь работы 6-дн. дневного стационара

25. ORACLE:SNMYEAR_5 -календарь работы 5-дн. дневного стационара

1.ORACLE:KIS.SVSCHET - справочник сводных счетов ЛПУ

KOD_LPU NUMBER(3, 0)Код ЛПУ

VID NUMBER(1, 0)Вид ЛПУ

N_SCH VARCHAR2(10) Номер счета

DT_SCH DATEДата формирования счета

DT_IN DATEДата первичной обработки счета

COUNT NUMBER(6, 0)Количество корректных записей

TOTAL NUMBER(10, 2)Стоимость корректных записей

COUNT_BAD NUMBER(6, 0)Количество некорректных записей

TOTAL_BAD NUMBER(10, 2)Стоимость некорректных записей

DOG_YN NUMBER(1, 0)Признак работы по полной программе

FIRST NUMBER(1, 0)

OMS NUMBER(1, 0)Признак проверки отделом ОМС

MEDEKS NUMBER(1, 0)Признак проверки экспертами

PEO NUMBER(1, 0)Признак обработки счета плановым отделом

ARX NUMBER(1, 0)Признак отправки счета в архив

EKSPERT NUMBER(1, 0)

2. ORACLE:SNMDOGOVOR - ЛПУ, работающие по полной программе

LPU NUMBER(3, 0) Код ЛПУ

DATA DATE Дата заключения договора

3. ORACLE:SNMDN_ST - справочник видов дневного стационара

KOD NUMBER(1, 0) Код вида дневного стационара

PROFIL CHAR(3)Профиль койки

NAIM VARCHAR2(40)Наименование

GRAFIK NUMBER(1, 0) Вид графика

4. ORACLE:SNMGRAFIK - справочник графиков дн.стационаров ЛПУ

KOD_LPU NUMBER(3, 0)Код ЛПУ

VID NUMBER(1, 0)Вид дневного стационара

GRAF NUMBER(1, 0)График дневного стационара

5. ORACLE:SNMGRUP - справочник группировки ЛПУ.

GLAV CHAR(3)Код главного ЛПУ

LPU CHAR(5)Код ЛПУ в символьном формате

LPU_N CHAR(5)Код ЛПУ в числовом формате

PUTH1 VARCHAR2(30)Путь для рассылки

GLN NUMBER(3, 0)Код главного ЛПУ в числовом формате

NLPU NUMBER(4, 0)

RAI NUMBER(3, 0)Код района

SS NUMBER(1, 0)

6. ORACLE:SNMKAT - категории населения при проверке стационара

KATEGOR NUMBER(1, 0) Категория населения

NAIM VARCHAR2(25) Наименование

7. ORACLE:SNMKAT1 - категории населения при проверке поликлиники

KATEGOR NUMBER(1, 0) Категория населения

NAIM VARCHAR2(25) Наименование

8. ORACLE:SNMMKB - справочник диагнозов

GRU NUMBER(3, 0)

KOD VARCHAR2(8)Код диагноза

NAIM VARCHAR2(72)Наименование

HIR CHAR(2)

9. ORACLE:SNMMKB_O - справочник ятрогении

KOD VARCHAR2(8)Код диагноза

NEK NUMBER(2, 0)Код отказа

10. ORACLE:SNMMKB_N - справочник взаимосвязей поводов и услуг

COB NUMBER(1, 0)Код обращения

KOD VARCHAR2(8)Код диагноза

NEK NUMBER(2, 0)Код отказа

FLG NUMBER(1, 0)Флаг

11. ORACLE:SNMNAPRAV - справочник направлений

KOD NUMBER(2, 0) Код направления

NAIM VARCHAR2(40) Наименование

15. ORACLE:SNMPROFIL - справочник профилей коек

KOD CHAR(3) Код профиля койки

NAIM VARCHAR2(30)Наименование

SR_DL NUMBER(5, 2)Средняя длительность

SR_DL1 NUMBER(5, 2)Средняя длительность

16.ORACLE:SNMSCOB - справочник целей обращения

KC NUMBER(2, 0) Код обращения

NC VARCHAR2(25) Наименование

18. ORACLE:SNMSPR_LPU - справочник ЛПУ

KOD_LPU NUMBER(3, 0) Код ЛПУ

NAIM_LPU VARCHAR2(45) Наименование

KOD_TMO NUMBER(2, 0)

VL NUMBER(1, 0)

ADR_LPU VARCHAR2(50)Адрес

FIO_LPU VARCHAR2(20)Руководитель

TEL_LPU VARCHAR2(9)Телефон

KOD_RAY NUMBER(2, 0)Код района

RAS_CH CHAR(20)Расчетный счет

BANK VARCHAR2(50)Наименование банка

GOROD_BN VARCHAR2(25)Город банка

INN VARCHAR2(15)ИНН ЛПУ

OKONX VARCHAR2(10)Код ОКОНХ

OKPO VARCHAR2(8)Код ОКПО

20. ORACLE:SNMSPL -справочник исходов лечения

KRL NUMBER(2, 0) Код исхода лечения

NRL VARCHAR2(30) Наименование

21. ORACLE:SNMTARIF1 - справочник специальностей врачей

KOD NUMBER(3, 0) Код специальности врача

SPEC VARCHAR2(45) Наименование

22. ORACLE:SNMUSLUGI - справочник услуг

KODUSL NUMBER(1, 0) Код услуги

NUSL VARCHAR2(20)Наименование

25. ORACLE:SNMYEAR_5 - календарь работы 5-дн. дневного стационара

YEAR NUMBER(4, 0) Год

MES_1 CHAR(42) 1-й месяц года

MES_2 CHAR(42)2-й месяц года

MES_3 CHAR(42) 3-й месяц года

MES_4 CHAR(42) 4-й месяц года

MES_5 CHAR(42)5-й месяц года

MES_6 CHAR(42)6-й месяц года

MES_7 CHAR(42) 7-й месяц года

MES_8 CHAR(42) 8-й месяц года

MES_9 CHAR(42) 9-й месяц года

MES_10 CHAR(42) 10-й месяц года

MES_11 CHAR(42) 11-й месяц года

MES_12 CHAR(42) 12-й месяц года

Приложение №5

Код основного модуля

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,

StdCtrls, ComCtrls, Buttons, ExtCtrls, RxGrdCpt, Grids, DBGrids,

bdeutils, fileutil, strutils, Db, DBTables, RXCtrls, SpeedBar, vclutils, ToolWin,

ImgList,DBLists;

type

TForm1 = class(TForm)

RxGradientCaption1: TRxGradientCaption;

SpeedBar1: TSpeedBar;

SpeedbarSection1: TSpeedbarSection;

SpeedItem1: TSpeedItem;

ToolBar1: TToolBar;

tbtn1: TToolButton;

tbtn2: TToolButton;

RxGradientCaption2: TRxGradientCaption;

ImageList1: TImageList;

Panel1: TPanel;

Animate1: TAnimate;

Label1: TLabel;

ToolButton1: TToolButton;

RxGradientCaption3: TRxGradientCaption;

Label2: TLabel;

Tbtn3: TToolButton;

procedure FormShow(Sender: TObject);

procedure SpeedItem1Click(Sender: TObject);

procedure ToolButton1Click(Sender: TObject);

procedure FormCreate(Sender: TObject);

procedure FormDestroy(Sender: TObject);

private

{ Private declarations }

procedure TblUpdt(s: TDatabaseItems);

public

{ Public declarations }

end;

var

Form1: TForm1;

reg : Byte;

implementation

{$R *.DFM}

uses data1, Data, main;

procedure create_msg(fi: string; n_ch: integer; d: tdatetime;cou, cou_bad: integer; tot, tot_bad: real);

const

str1:AnsiString='Получен счет:';

str2:AnsiString='Счет:';

str3:AnsiString='Дата:';

str4:AnsiString='Результаты автоматичекой проверки:';

str5:AnsiString='Документов без ошибок ';

str6:AnsiString='Документов с ошибками ';

str7:AnsiString='Отдел АИО ТФ ОМС г.Иваново';

str8:AnsiString=' на сумму ';

var f: textFile;

begin

if fileexists(fi) then Exit;

AssignFile(f,fi);

Rewrite(f);

writeln(f,strtooem(str1));

writeln(f,strtooem(str2)+inttostr(n_ch));

writeln(f,strtooem(str3)+DateTimeToStr(d));

writeln(f,strtooem(str4));

writeln(f,strtooem(str5)+IntToStr(cou)+strtooem(str8)+floattostrF(tot, ffFixed,10,2 ));

writeln(f,strtooem(str6)+IntToStr(cou_bad)+strtooem(str8)+floattostrF(tot_bad,ffFixed,10,2));

writeln(f,strtooem(str7));

CloseFile(f);

end;

procedure create_pst(p,fi1,fi2: string);

var f: textFile;

begin

AssignFile(f,fi1);

Rewrite(f);

writeln(f,'PATH:'+p);

writeln(f,'FILE:'+fi2);

writeln(f,strtooem('КТО : decodsch.exe'));

writeln(f,strtooem('ДАТА: '+ datetimetostr(now)));

CloseFile(f);

end;

procedure ChangeLangDrv(drv: string);

var l: TStrings;

begin

Session.Close;

l := TStringList.Create;

l.Add('LANGDRIVER='+drv);

Session.ModifyDriver('DBASE',l);

Session.Open;

l.Free;

end;

procedure kod_lpu(t: TTable);

begin

t.TableName := 'L2'+Copy(t.TableName,3,3)+'.DBF';

t.Open;

if not(t.IsEmpty) then

with dm1.Query1 do begin

Close;

SQL.Clear;

sql.Add('UPDATE AMB_US SET KOD_LPU='+

t.FieldByName('kod_lpu').asstring+' , N_CH='''+

t.FieldByName('n_ch').asstring+''' , DAT_SC='''+

t.FieldByName('dat_sc').AsString+''' WHERE KOD_LPU IS NULL');

ExecSQL;

end;

t.Close;

end;

procedure TForm1.TblUpdt(s: TDatabaseItems);

var t: TTable;

begin

Label1.Caption := 'Идет подготовка таблиц ...'; delay(10);

t := TTable.Create(self);

case reg of

1: t.DatabaseName := 'dbSTA';

2: t.DatabaseName := 'dbAMB';

4: t.DatabaseName := 'dbSTO';

end;

{cоздание БД переносимых LPU и счетов}

if deletefile('d:\data\toORA\z.dbf') then;

with dm1.Query2 do

begin

sql.Clear;

sql.Add('CREATE TABLE "z" (kod_lpu numeric(3),n_ch character(10), dat_sc date, vid numeric(1) )');

Prepare;

ExecSQL;

end;

with s do begin

Open;

First;

while not eof do begin

t.TableName := ItemName;

TableUpdate(t);

Next;

end;

Close;

{Формирование БД переносимых LPU и счетов}

{ если весь счет забракован в ошибки, то усложняется SQL на INSERT в z.dbf }

with dm1.Query2 do

begin

sql.Clear;

case reg of

1: sql.Add('INSERT INTO "z" (kod_lpu, n_ch, dat_sc, vid) select distinct kod_lpu, n_ch, dat_sc, 1 as vid from sta ');

2: sql.Add('INSERT INTO "z" (kod_lpu, n_ch, dat_sc, vid) select distinct kod_lpu, n_ch, dat_sc, 2 as vid from amb ');

4: sql.Add('INSERT INTO "z" (kod_lpu, n_ch, dat_sc, vid) select distinct kod_lpu, n_ch, dat_sc, 4 as vid from sto ');

end;

ExecSQL;

sql.Clear;

case reg of

1: sql.Add('INSERT INTO "z" (kod_lpu, n_ch, dat_sc, vid) select distinct kod_lpu, n_ch, dat_sc, 1 as vid from sta_bad where kod_lpu not in (select distinct kod_lpu from sta) ');

2: sql.Add('INSERT INTO "z" (kod_lpu, n_ch, dat_sc, vid) select distinct kod_lpu, n_ch, dat_sc, 2 as vid from amb_bad where kod_lpu not in (select distinct kod_lpu from amb) ');

4: sql.Add('INSERT INTO "z" (kod_lpu, n_ch, dat_sc, vid) select distinct kod_lpu, n_ch, dat_sc, 4 as vid from sto_bad where kod_lpu not in (select distinct kod_lpu from sto) ');

end;

ExecSQL;

Close;

end;

end;

t.Free;

end;

procedure TForm1.FormShow(Sender: TObject);

begin

Icon := Application.Icon;

ToolBar1.Buttons[0].Down := True;

Label1.Caption := '';

Label2.Caption := '';

try

dm1.dbORA.Connected := True;

except

MessageDlg('Ошибка при подключении к серверу ORACLE(WG73)!', mtWarning, [mbOK], 0);

end;

end;

procedure TForm1.ToolButton1Click(Sender: TObject);

begin

ChangeLangDrv('db866ru0');

Close;

end;

procedure TForm1.FormCreate(Sender: TObject);

begin

ChangeLangDrv('db866ru0');

end;

procedure TForm1.FormDestroy(Sender: TObject);

begin

ChangeLangDrv('db866ru0');

end;

end.

Министерство общего и профессионального образования РФ Курсовой проект По дисциплине: «Проектирование экономических информационных систем» На тему: «Проектирование АРМ сотрудника отдела автоматизаци

 

• 14:21 05 Июля 2016
  Российско-китайский медуниверситет откроет магистерскую программу по TCM
• 01:21 05 Июля 2016
  На форуме МГУ Россия и Китай обсудят научно-образовательное сотрудничество
• 11:00 04 Июля 2016
  Реморенко: "ЕГЭ-туризм" в России сходит на нет
• 10:52 04 Июля 2016
  Летняя российско-австрийская школа откроется в Москве
• 15:31 01 Июля 2016
  В СПбГУ могут воссоздать географический факультет

Заказать уникальную работу