Министерство общегои профессионального образования РФ
Курсовой проект
По дисциплине: «Проектированиеэкономических информационных систем»
На тему: «ПроектированиеАРМ сотрудника отдела автоматизации информационного обеспечения Ивановскогофилиала ФОМС»
Выполнила:
Руководитель:
Содержание
Введение
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 (рекомендуется 512Mb) или выше.
Объем жесткого диска: не менее 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-е. После того, как все следы неудачного переноса удалены, можноповторить перенос.
Если при контроле счетов появилась ошибка “Accessviolation …”, то повторите контроль счетов, предварительно удалив неудачнообработанные счета. Если ошибка повторяется вновь, то смотрите исходный текстпрограммы.
Заключение
Данный курсовой проект явился завершающим этапом изучениядисциплины «Проектирование информационных систем». Его основная цель состоит всамостоятельной разработке проектных решении, имеющих практическую ценность, атакже в их технико-экономическом обосновании. В процессе работы над курсовымпроектом во время технико-организационной практики мною были реализоватьполученные теоретические знания.
Я стремился к тому, чтобы этот проект был практическиреализуем, способствовал совершенствованию управления, выполнялся на конкретныхматериалах, и мог быть использован на предприятии. И в конечном итоге эта цельбыла мною достигнута – версия данного проекта принята к сведению в Ивановскомотделений ТФОМС и скоро планируется его внедрение. Особенно полезными оказалисьзамечания по поводу существующего способа передачи информации в системе.
В перспективе следует улучшать параметры работы данногопродукта как за счет улучшения быстродействия всей системы в целом (заменаустаревшего оборудования более новым, создание новых систем передачи информациии т.д.), так и с помощью модернизации кода программных модулей, структуры базданных и др.
Особое внимание при усовершенствовании системы следуетобратить на способы и скорости передачи информации, а также на возможныеварианты увеличения производительности всей системы в целом. Следует стремитьсяк тому, чтобы при максимальных информационных нагрузках на отдельные компьютеры(клиенты) достигались высокие показатели быстродействия.
Поскольку большая часть информации, использующаяся всистеме является личной тайной любого гражданина РФ, то необходимо разработатьсистему по ее защите, а именно: предупреждение несанкционированного доступа кданным, а также их изменение или уничтожение как со стороны «нелегальных»пользователей, так и при сбоях аппаратных или программных средств. Средства иметоды защиты информации должны использоваться комплексно с использованиемтехнических и программных средств.
В обязанности администратора системы следует включитьработу по обеспечению защиты локальных баз данных, а именно:
— классификация данных;
— определение прав доступа отдельных пользователей иограничений на характер операций;
— организация системы контроля доступа к данным;
— тестирование средств защиты;
— прочие работы по защите системы.
В дальнейшем следует более полно и комплексноиспользовать возможности современных операционных систем. Многие функцийадминистратора системы могут быть возложены на операционную систему. А такженеобходимо переходить от централизованного к распределенному способу обработкиданных. Распределенная обработка данных позволяет разместить базу данных вразличных узлах компьютерной сети. Таким образом, каждый компонент базы данныхрасполагается по месту наличия техники и ее обработки.
Список использованных источников
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 vidfrom sta ');
2: sql.Add('INSERT INTO «z»(kod_lpu, n_ch, dat_sc, vid) select distinct kod_lpu, n_ch, dat_sc, 2 as vidfrom amb ');
4: sql.Add('INSERT INTO «z»(kod_lpu, n_ch, dat_sc, vid) select distinct kod_lpu, n_ch, dat_sc, 4 as vidfrom 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 vidfrom 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 vidfrom 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 vidfrom 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;
procedureTForm1.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.