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

метки: Информация, Oracle, Медицинский, Обеспечение, Лечение, Контроль, Диагноз, Услуга

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

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

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

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

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

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

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

Этот курсовой проект состоит из двух основных частей: аналитики, проектирования и расчета, а также введения и заключения.

Овердрафт: проблемы и перспективы развития

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

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

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

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

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

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

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

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

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

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

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

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

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

История развития медицинского страхования в РФ

... началось благодаря принятию 28.06.1991 Закона РСФСР «О медицинском страховании граждан в РСФСР» № 1499-1. Медицинское страхование — это новые экономические отношения в здравоохранении в условиях рынка, направленные на создание такой ...

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

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

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

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

Территориальный фонд обязательного медицинского страхования по Ивановской области создан решением Малого совета Ивановского областного Совета народных депутатов № 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 Выходная информация

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

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

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 …” , то повторите контроль счетов, предварительно удалив неудачно обработанные счета. Если ошибка повторяется вновь, то смотрите исходный текст программы.

Заключение

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

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

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

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

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

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

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

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

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

[Электронный ресурс]//URL: https://ddmfo.ru/kursovoy/razrabotka-arm-rabotnika-strahovoy-kompanii/

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.