Проектування АРМ співробітника відділу автоматизації інформаційного забезпечення Іванівського філії

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Міністерство загальної та професійної освіти РФ
Курсовий проект
З дисципліни: «Проектування економічних інформаційних систем»
На тему: «Проектування АРМ співробітника відділу автоматизації інформаційного забезпечення Іванівського філії ФОМС»
Виконала:
Керівник:

Зміст
Введення
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
ЛПУ-n
ЛПУ-1
ЛПУ-n
ЛПУ-1
ЛПУ-n


Малюнок 1. Структура системи медичного страхування
Ієрархічна структура управління ФОМС можна назвати досить складною. Тут присутні численні і багатофункціональні взаємозв'язку в керуючій системі між управлінським апаратом і об'єктами управління.
Як і у більшості підприємств в ФОМС можна зробити поділ управління на три основні рівні: вищий (стратегічний), середній (функціональний) та оперативний. На кожному з них ведуться певні роботи, які в комплексі забезпечують загальне управління фондом.
Прийняття основних управлінських рішень, які забезпечують нормальну роботу ФОМС, здійснюється генеральним директором. Він відноситься до вищого рівня управління. Його основними функціями є вироблення управлінських рішень, спрямованих на організацію безперебійної роботи ФОМС. У його обов'язки також входить контроль взаємодії між різними структурними підрозділами (господарським відділом, відділом видачі страхових полісів громадян, юридичним відділом, експертним відділом, відділом автоматизації інформаційного забезпечення та інших). Все вище перераховане можна віднести до внутрішніх функцій генерального директора. Так само можна виділити зовнішні функції вищого рівня керівництва це - спостереження за загальною економічною і політичною ситуацією в регіоні, своєчасне зміна політики підконтрольних лікувальних установ, підтримування зовнішніх зв'язків і т.д.
Середній та оперативний функціональний рівень представлений керівниками відділів. У їх основні обов'язки входить: організація роботи співробітників відділу протягом певного періоду часу, розробка механізмів роботи окремих груп працівників, розробка методологічного забезпечення, навчання і підвищення кваліфікації співробітників та інші. Таким чином, загальна схема управління Іванівського регіонального відділення ФОМС може бути представлена ​​на рис.2

Генеральний директор ТФОМС

1-ий заступник генерального директора
Другий Заступник генерального директора
Економічний (господарський)
відділ
Юридичний відділ
Експертний
відділ
Відділ видачі страхових полісів громадян
Відділ автоматизації інформаційного забезпечення
Відділ бух. Обліку і фінансово-кредитної політики


Малюнок 2. Схема управління відділення ФОМС Івановської області

Розглянемо докладніше відділ АІО ФОМС. Він включає в себе:
- Групу системних програмістів
- Групу програмістів прикладних програм
- Співробітника по роботі з лікувальними установами Іванова і області
- Групу технічного постачання і налагодження обладнання
Кожна група підпорядковується безпосередньо начальнику даного відділу. На момент проходження виробничої практики загальний склад відділу включав 8 чоловік, по 2 особи на кожну групу фахівців.
1.2 Обгрунтування доцільності автоматизації функцій
Необхідність проектування АРМ для даної системи визначається цілою низкою вагомих причин, основними з яких є:
1) забезпечення цілісності даних, розділення даних, безпеки, продуктивності, стандартного способу доступу;
2) у даному випадку АРМ - це не просто механізм збереження і пошуку інформації, але також система, здатна підтримувати складні інформаційні технології, вирішувати такі проблеми як: ведення великих баз даних, підтримка розподілених БД, інтегрування у вже існуючі і працюючі інформаційні системи, і в майбутньому - що складається з безлічі вузлів обчислювальної мережі;
3) моральне і не рідко «фізична» старіння раніше існуючих систем (архаїчні алгоритми вирішення завдань, використання застарілих мов програмування і СУБД, а також комплекси ЕОМ, на яких вони засновані);
4) прагнення до збільшення продуктивності розрахунків у системі, прискорення обробки величезної кількості інформації, що надходить (основним вхідним документом є база даних полісів, яка розбивається на частини, а в цілому вона може складатися з більш ніж 10 000 рядків, причому кожен рядок повинен бути своєчасно перевірена та внесена до реєстру. Нове програмне засіб здатний в значній мірі скоротити витрати часу на обробку цієї інформації);
5) необхідність переходу даної інформаційної підсистеми на єдину систему управління реляційними базами даних (наприклад, на основі корпоративної інформаційної системи Oracle), для більшої стандартизації робіт всіх філій Російської системи ОМС;
6) неможливість вирішення безлічі аналітичних завдань за існуючої структури АРМ, а також відсутність прикладних програм, що дозволяють більш повно використовувати інформацію з вступників від ЛПУ баз даних.
Підводячи підсумок, можна сказати, що основною метою даної роботи є вдосконалення роботи та підвищення продуктивності праці співробітників відділу автоматизації інформаційного забезпечення.
Створення подібного програмно-технічного комплексу передбачає досягнення рішення наступних завдань:
1) розробка, створення та ведення бази даних;
- Формування запитів до бази даних;
- Розробка та налагодження програмних модулів комплексу завдань АРМ;
- Оцінка проектних рішень АРМ за критеріями ефективності, швидкодії, надійності та вартості;
2) оснащення філій ТФОМС (відділу автоматизації інформаційного забезпечення) обчислювальними програмно-технічними комплексами (у даному випадку - оновлення і доповнення вже існуючих комплексів) з розвиненою периферією;
3) розробка комплексу прикладних програм супроводу, повністю покривають дану задачу (і надалі - інші завдання);
4) автоматизувати формування вихідних документів;
6) інформаційне об'єднання всіх служб ТФОМС і забезпечення можливості доступу до будь-якої з них.
Відзначимо мети створення АРМ:
- Підвищення оперативності реалізації запитів;
- Зниження трудомісткості обробки інформації;
- Забезпечення можливості швидкого пошуку та обробки необхідної інформації;
- Підвищення якості контролю вхідний і вихідний інформації;
- Автоматизація проведення розрахунків.

2. Розробка АРМ співробітника відділу АІО ФОМС
2.1 Технічне завдання
Повна назва проектованої системи - «Автоматизоване робоче місце фахівця відділу автоматизації інформаційного забезпечення Іванівського відділення Фонду обов'язкового медичного страхування».
Мета проектування даного АРМ - створення системи контролю рахунків, що надходять до відділу АІО ФОМС з лікувальних установ міста та області, для забезпечення достовірності єдиної інформаційної бази застрахованих осіб.
Головною особливістю даного проекту є те, що всі бази даних, що надходять від лікувальних установ, що не проходять первинний контроль правильності вихідної інформації безпосередньо на місці її створення як було б при класичному способі формування БД. У даному випадку такий контроль проводиться в центральному філії ФОМС, куди стікаються вся початкова інформація. Такий спосіб обробки даних на перший погляд вкрай не логічний і відрізняється підвищеними фінансовими витратами, але на його використання є ряд вагомих причин. До них можна віднести наступні:
1. Фізична нездатність ВСІХ лікувальних установ проводити такий контроль, як, власне, і будь-яку іншу задачу, що вимагає великої продуктивності. Так, наприклад, якщо запустити програмний код системи, що розробляється на комп'ютері типу DELL-386AT (основна технічна база), то програма успішно виконає всі дії через 3 дні з моменту запуску за умови безперебійної роботи комп'ютера в автоматичному режимі без втручання користувача-контролера.
2. Проведення фондом єдиної організаційної політики, при якій кожен елемент Російської системи медичного страхування виконує виключно ті функції, які були призначені йому спочатку.
3. Проведення політики інформаційно безпеки. Контроль доступу до єдиної інформаційної бази застрахованих осіб.
Тому впровадження АРМ дозволить значно скоротити фінансові витрати підконтрольних установ, а також буде сприяти підвищенню продуктивності роботи всієї системи ФОМС в цілому.
Слід зауважити, що проект в силу своєї специфіки пред'являє високі вимоги як до апаратного, так і до програмного забезпечення комп'ютерів, рекомендована конфігурація яких буде такою:
Процесор - з тактовою частотою не нижче 2 ГГц, наприклад
AMD ATHLON XP 2500 + або Intel Pentium 2.3 Ггц
Оперативна пам'ять - 512 Mb
Відео система-Монітор SVGA 15''і сумісна відеокарта.
Наприклад плати від компанії NVidea - GeForce-4 MX-440
Модем - будь-який сучасний USB або PCI модем, наприклад ZyXEL.
Пристрій читання компакт-дисків CD-ROM - тільки при початковій установці програмного забезпечення та налагодженні системи
Також обов'язкова джерело безперебійного живлення UPS.
Згідно з вимогою наведемо перелік автоматизуються функцій, а також схему інформаційних взаємозв'язків і схему технологічного процесу обробки інформації.
Перелік автоматизуються функцій:
Контроль наявності вхідної інформації - Код 0101
Первинна підготовка таблиць вихідних даних - Код 0201
Перевірка зведеного рахунку за кодом ЛПУ і номером рахунку - Код 0301
Перевірка про взаєморозрахунки між територіями - Код 0302
Контроль приводів відвідин і послуг ЛПУ - Код 0303
Пошук і усунення записів дублікатів - Код 0401
Перевірка іногородніх пацієнтів - Код 0501
Контроль за термінами надання рахунків до оплати - Код 0502
Формування вихідних документів - Код 0601
Для наочності, представимо цей перелік у вигляді таблиці:
Таблиця 1
Перелік автоматизуються функцій
Код функції
Найменування
Вхідна інформація
Вихідна інформація
Одержувач
0101
Контроль наявності вхідної інформації
Код ЛПУ, Дата, Номер рахунку, Серія поліса, Номер поліса, ПІБ, Дата народження, адресу, місце роботи, Телефон ...
Код ЛПУ, Дата, Номер рахунку, Серія поліса, Номер поліса, ПІБ, Дата народження, адресу, місце роботи, Телефон ...
0201
0201
Первинна підготовка таблиць вихідних даних
Див 0101
Див 0101
0301
0302
0303
0301
Перевірка зведеного рахунку за кодом ЛПУ і номером рахунку
Див 0101
Див 0101
0201
0401
0302
Перевірка про взаєморозрахунки між територіями
Див 0101
Див 0101
0201
0401
0303
Контроль приводів відвідин і послуг ЛПУ
Див 0101
Див 0101
0201
0401
0401
Пошук і усунення записів дублікатів
Див 0101
Див 0101
0501
0502
0501
Перевірка іногородніх пацієнтів
Див 0101
Див 0101
0601
0502
Контроль за термінами надання рахунків до оплати
Див 0101
Див 0101
0601
0601
Формування вихідних документів
Див 0101
-
Передача в єдину базу по модему

Також представимо схему інформаційних взаємозв'язків і схему технологічного процесу обробки інформації:
2.2 Постановка і алгоритм вирішення комплексу завдань
2.2.1 Характеристика комплексу задач
Відзначимо мети створення комплексу завдань:
- Підвищення оперативності реалізації запитів;
- Зниження трудомісткості обробки інформації;
- Забезпечення можливості швидкого пошуку та обробки необхідної інформації;
- Підвищення якості контролю вхідний і вихідний інформації;
- Автоматизація проведення розрахунків.
Досягнення поставлених цілей можливо тільки при вирішенні таких завдань:
1) розробка, створення та ведення бази даних;
- Формування запитів до бази даних;
- Розробка та налагодження програмних модулів комплексу завдань АРМ;
- Оцінка проектних рішень АРМ за критеріями ефективності, швидкодії, надійності та вартості;
2) оснащення філій ТФОМС (відділу автоматизації інформаційного забезпечення) обчислювальними програмно-технічними комплексами (у даному випадку - оновлення і доповнення вже існуючих комплексів) з розвиненою периферією;
3) розробка комплексу прикладних програм супроводу, повністю покривають дану задачу (і надалі - інші завдання);
4) автоматизувати формування вихідних документів;
6) інформаційне об'єднання всіх служб ТФОМС і забезпечення можливості доступу до будь-якої з них.
Особливими вимогами до організації обчислювального процесу є те, що інформаційна система ТФОМС є багато користувачів, отже, тут актуальні питання забезпечення безпеки даних. Відповідно до вирішуваних задач необхідно визначити групи користувачів зі специфічними привілеями розділяється доступу. Механізми безпеки, які використовуються в СУБД, повинні стати бар'єром на шляху неавторизованого використання інформації і в той же час не знижувати ефективності системи в цілому.
Природно, що в даному випадку пред'являються особливо жорсткі вимоги до технічного і програмного забезпечення.
2.2.2 Вихідна інформація
У рамках АРМ вихідні повідомлення можуть видаватися як у вигляді документів-звітів роботи, так і у вигляді окремих файлів - масивів даних.
На паперовий носій (при необхідності) переноситься наступна інформація:
1. Звіт про поточний станів центральної бази даних.
2. Звіт про наявність помилок у вихідних базах даних у розрізі кожного етапу технології обробки інформації.
3. Інформація службового призначення: - звіти про поточні характеристики каналів зв'язку, технічних засобів і т.п.
В якості вихідних масивів даних виступають:
1. Єдина інформаційна база застрахованих осіб по Івановській області.
2. Перелік некоректних записів у вхідних базах даних, представлений у вигляді БД коректур.
Вихідна інформацію представлена ​​нижче у таблиці 2.

Таблиця 2
Опис вихідних повідомлень
Найменування вихідного повідомлення
Ідентифіка-катор
Форма подання
Період видачі
Термін видачі
Одержувач
Макс. число рядків
Звіт про поточний стан Центральної БД
Д060101
Документ
Ежен-но
На початку робочого тижня
Центральне управління ФОМС
100
Звіт наявності помилок в БД
Д060102
Документ
Ежен-но
На початку робочого тижня
Центральне управління ФОМС
1 000
Службова інформація
Д060103
Документ
Щоденно-вно
При необхідності
Головний програміст
100
Єдина БД громадян
М060104
Масив
Ежен-но
На початку робочого тижня
Центральне управління ФОМС
1 500 000
Перелік некорр записів в БД
М060105
Масив
Ежен-но
На початку робочого тижня
Центральне управління ФОМС
1 000
Опис складових одиниць інформації у вихідних повідомленнях наведено нижче у таблиці 3. Слід зазначити, що у всіх представлених документах загальна кількість СЕІ перевищує 200, і розглянути їх усі не представляється можливим. Тому нижче представлені описи тільки основних реквізитів документів.

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

Таблиця 4
Опис вхідних повідомлень
Найменування вихідного повідомлення
Ідентифікатор
Форма подання
Період полступленія
Строк надходження
Джерело
Макс. число рядків
Бази даних полісів громадян та ЛПЗ по всіх ЛПЗ області
М010101
Масив
Щотижня
На початку робочого тижня
ЛПУ міста і області
100 000
Тарифи для міжтериторіальних взаєморозрахунків
М010102
Масив
Щомісяця
На початку місяця
Центральне управління ФОМС
1 000
Таблиця 5
Опис структурних одиниць інформації вхідних повідомлень
Найменування одиниць інформації
Позначення
Ідентифікатор
Довжина у знаках
Діапазон зміни
Код регіону
REGION
М010102
9 (3)
1-999
Код головного ЛПУ
GLAV
М010102
А (5)
-
ЛПУ символи
LPU
М010102
A (5)
-
ЛПУ числа
LPU_N
М010102
A (5)
-
Шлях розсилки
PATH
М010102
A (30)
-
Номер ЛПУ
NLPU
М010102
9 (3)
1-999
Код району
RAI
М010102
9 (3)
1-999
Категорія населення
KATEGOR
М010102
9 (1)
1-9
Розшифровка
FULL
М010102
A (10)
-
Найменування
NAIM
М010102
A (25)
-
Код послуги
KODUSL
М010102
A (4)
-
Тариф старий
TARIF
М010102
9 (7), 2
-
Тариф новий
TARIF_N
М010102
9 (7), 2
-
Дата зміни тарифу
DATE
М010102
9 (8)
-
Тип договору
GOG_YN
М010102
9 (1)
1-9
Профіль відділення
PROFIL
М010102
A (2)
-
Рівень якості лікування
UKL
М010102
9 (4), 2
-
Вид оплати
IV
М010102
9 (4)
-
Ознака страхування
PR_STR
М010102
9 (1)
1-2
Вид графіка
GRAFIK
М010102
A (5)
-
Код діагнозу
KOD
М010102
A (8)
-
Код відмови
NEC
М010102
9 (2)
1-99
Територія страхування
TERR_STR
М010102
9 (4)
-
2.2.4 Опис алгоритму розв'язання задачі
Дане завдання вирішується за допомогою прикладної програми. Загальна технологія обробки інформації в ній представлена ​​на рис.4:
Бази даних від ЛПУ
Оброблені БД для ЛПУ
Комплекс прикладних програм
Вхідні документи
Вихідні документи


Малюнок 4. Технологія обробки інформації
Всі каталоги, з якими працює програма настроюються у самою програмою. Вхідними файлами для завдання є архіви рахунків ЛПЗ, які мають вигляд Ln???. ARJ, де n = 1,2,4. (1-стаціонар, 2 - поліклініка, 4 - стоматологія). ??? - Код ЛПУ.
Архів рахунку стаціонару повинен містити файли виду L1???. DBF, I1???. DBF, O1???. DBF, де? - Код ЛПУ. База L1???. DBF містить основну інформацію про пролікованих в стаціонарі, I1???. DBF містить додаткову інформацію про громадян, застрахованих в інших регіонах, але пролікованих у ЛПЗ Івановської області, а файл O1???. DBF включає в себе додаткову інформацію про проведені операції.
Архів рахунки поліклініки повинен містити файли виду L2???. DBF, I2???. DBF, L2??? _US.DBF, Архів рахунку стоматології повинен містити файли виду L4???. DBF, I4???. DBF, L4? _US.DBF,
При вхідному контролі може бути сформований текстовий файл виду P? Nnn.TXT, містить помилки за полісами контрольованого рахунку. Текстовий файл поміщається в M: \ AIO = SCHT \ OUT разом з конвертом для розсилки.
Після вхідного контролю програмою DecodSch може бути додатково створена БД відбракованих записів рахунку у вигляді B? Nnn.DBF, де? = (1 - стаціонар, 2 - поліклініка, 4 - стоматологія), nnn - код ЛПУ.
Причому БД після вхідного контролю вже підготовлені для перенесення на ORACLE, тому не бажано їх переглядати за допомогою FOXPRO або програм, написаних на ньому, тому що FOXPRO нерідко змінює кодову сторінку відкритих БД. У цьому випадку при переносі можуть бути проблеми з російськими літерами в символьних рядках ('асмімті' à'######'). Далі здійснюється перенесення інформації на ORACLE. Для цього інформація переписується у аліас TOORA (D: \ DATA \ TOORA) до відповідних БД, але інформація зберігається вже не в DOS, а в WINDOWS-кодуванні і потім переноситься на ORACLE-сервер. При завершенні перенесення формується файл виду M? Nnnsss.LPU, де? = (1 - стаціонар, 2 - поліклініка, 4 - стоматологія), nnn - код ЛПУ, sss - номер рахунку.
Він містить інформацію про результати автоматичної перевірки рахунку. У разі отримання повторного рахунку також формується аналогічний файл з повідомленням «Повторний зведений рахунок - ВІДХИЛИВ!». Порожні рахунки просто видаляються з обробки.
Тепер докладніше про контроль рахунків «Поліклініка» (аналогічно працюють алгоритми для рахунків «Стоматологія» та «Стаціонар)».
Алгоритм роботи програми:
Здійснюється перевірка наявності файлів (MAIN.PAS, процедура actFindFilesExecute).
Підготовка таблиць. Перевіряється структура БД на наявність необхідних полів, які були додані в БД відносно недавно. У разі їх відсутності необхідні поля додаються в БД автоматично. Іногородні хворі переписуються в основну БД. БД індексується.
Перевірка зведеного рахунку за кодом ЛПУ, дату рахунку і номером рахунку. Якщо представлений повторний зведений рахунок, то формується текстовий файл за результатами автоматичної перевірки з повідомленням «Повторний зведений рахунок - ВІДХИЛИВ!» (MAIN.PAS, процедура actSvodSchetExecute)
Перевірки відповідно до листа № 07-2194 від 06.09.2000 року (для виконання наказу № 70 ФФОМС про взаєморозрахунки між територіями) (MyFunc.PAS, процедура New_cntrl_amb) якщо в полі «Категорія» стоїть «Працюючий», то поле «Місце роботи »має бути обов'язково заповнено.
Обов'язково повинна бути введена інформація або про поліс пацієнта, або його паспортні дані.
Якщо немає інформації про поліс пацієнта, то має бути заповнено поле «Особливий випадок»
Якщо в полі «Особливий випадок» заповнене «Медична допомога новонародженому» або «Документ батька», то обов'язково повинні бути заповнені поля «Прізвище», «Ім'я», «батькові» одного з батьків або опікуна
Якщо в полі «Особливий випадок» заповнене «У документі відсутній по батькові», то поле «батькові» має бути порожнім для відділковій лікарні всі записи про пролікованих хворих-мешканців Івановської області вирушають у некоректні
Перевірка на відповідність приводів відвідин і послуг відповідно до листа від 30.11.1998 року. (MAIN.PAS, процедура ActAmbCtrlUslExecute)
Перевірка іногородніх пацієнтів чи не є вони іноземцями (їх ми не оплачуємо). (MyFunc.PAS, процедура Del_States)
Контроль за термінами подання рахунків до оплати. У представленому рахунку дата останньої послуги, наданої пацієнтові повинна бути не пізніше 3-х місяців від дати формування рахунку. Також в рахунку не повинно бути послуг з датою послуги, що відноситься до майбутніх плановим періодам (MyFunc.PAS, процедура Date_cntrl_amb).
Не повинно бути записів-дублікатів в основному файлі наданого рахунку. (MAIN.PAS, процедура ActAmbDoubleStrExecute)
Перевірка заповнення необхідних полів. На основній базі обов'язково повинні бути заповнені поля «Прізвище», «Дата народження», «Категорія», «Привід відвідування» «Основний діагноз», «Випадок», «Вартість». В БД іногородніх обов'язково повинні бути заповнені ті ж поля, що і в основній БД, а також інформація про поліс пацієнта або його паспортні дані. (MAIN.PAS, процедура ActAmbReqFieldsExecute)
Перевірка коду основного діагнозу за МКХ, а також перевірка на правильність поєднання основного діагнозу і приводу відвідування. Крім того не оплачуються пацієнти старше 18 років з деякими діагнозами (див. записку відділу КТіСМП від 19.10.2000 року) (MAIN.PAS, процедура actFindDiagORAExecute).
Перевірка відвідувань. Не повинно бути випадків кончини рахунків на два відвідування до одного лікаря пацієнта в той же день. Всередині одного талона не повинно бути дублікатну послуг (MAIN.PAS, процедура actAmbOneToOneExecute).
Перевірка наявності поліса пацієнта в обласній БД полісів і збіг прізвища, імені, по батькові та дати народження пацієнта і тих же відомостей в обласній базі. Крім того перевіряється наявність поліса у пацієнтів, які пред'явили тільки паспорт і робиться відповідна відмітка в БД для відділу ОМС. (MAIN.PAS, процедура ActFindPolisIBExecute)
Порівняння з архівом. Для даного ЛПУ перевіряється за номером талону, прізвища, імені та по батькові пацієнта наявність інформації в архіві раніше пред'явлених рахунків до оплати. Крім того, не повинно бути двох відвідувань до одного лікаря в той же день в поточному рахунку і в архіві. (MAIN.PAS, процедура actAmbCompArcORAExecute)
Перевірка вартості наданих медичних послуг. (MyFunc.PAS, процедура AMB_Stoim)
Для наочності алгоритм роботи програми представлена ​​наступною блок-схемою (рисунок 5).
Контроль за термінами подання рахунків до оплати
Контроль на наявність записів-дублікатів
Підготовка звіту про виконану роботу
Кінець
Порівняння з наявними даними в архіві
Перевірка вартості наданих послуг
Початок
Наявність БД
Ні
Так
Підготовка таблиць
Перевірка рахунку за кодом ЛПУ
Перевірка іногородніх пацієнтів
Екстрений вихід
Перевірка на відповідність приводів відвідин і послуг
Перевірка заповнення необхідних полів
Перевірка коду діагнозу та його поєднання зі способом відвідування
Перевірка відвідувань
Перевірка поліса пацієнта по обласній БД
Забезпечення цілісності даних


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

2.2.5 Вимоги до контрольного Приміром
Вхідними даними для контрольного прикладу служить інформація, що витягує з наступних документів:
- 2 і більше БД від лікувальних установ міста і області
- Частина єдиної інформаційної бази даних. Для повноти уявлення контрольного прикладу необхідно як мінімум 1 000 записів.
Даний обсяг інформації дозволяє оцінити всі можливості системи. Основні вимоги до контрольного прикладу:
- Використання реальної інформації і в реальних обсягах. На цих даних проводиться контроль повноти і правильність здійснених розрахунків і сформованих баз даних;
- Крім реально використовується в системі інформації в контрольному прикладі повинні бути представлені службові дані, що відображають поведінку апаратної частини АРМ в процесі його функціонування;
- Використання таких алгоритмів роботи системи при розрахунку контрольного прикладу, які повною мірою відображають всі аспекти її роботи;
- Дані контрольного прикладу повинні охоплювати повний ланцюжок функціональних завдань в рамках технологічного процесу обробки інформації;
Частина використовуваних алгоритмів, а також приклади вихідних повідомлень представлені у додатку.
2.3. Програмна реалізація
Для оптимальної роботи АРМ необхідно використання наступної архітектури персонального комп'ютера:
Апаратні засоби:
Комп'ютер на базі процесора Intel Pentium 3 (1 GHz) або AMD Athlon 1600 XP або вище.
Оперативна пам'ять: не менше 256 Mb (рекомендується 512 Mb) або вище.
Об'єм жорсткого диска: не менше 40 Gb.
Програмні засоби:
Операційна система Windows 98, NT, 2000, XP
BDE Administrator (додається до системи програмування Delphi 7)
Oracle для Windows 98, NT
Система програмування Delphi 7 для усунення можливих помилок апаратних чи програмних засобів, а також для можливої ​​модернізації або оновлення продукту.
Будь-яка сучасна СУБД (FoxPro, Clarion, Paradox та ін) дозволяє використовувати формат dbf для створення баз даних.
Детальний опис та малюнки блок-схем, налагоджених модулів комплексу завдань тут не наводяться, у додатках можна побачити готові тексти тільки деяких з них, тому що як це вже було сказано вище - ця інформація є комерційною таємницею.
Оскільки цей проект реалізований на базі прикладних програм, то далі описуються роботи, виконані за їх адаптації.
Загальні зауваження по вхідному контролю рахунків ЛПЗ. На початок практики планувалася наступна схема роботи цієї програми: рано вранці автоматично включається ROBOT (сервер), завантажується програма обробки рахунків ЛПУ і вона запускає програму перенесення БД полісів на ORACLE. А програма обробки рахунків починає працювати автоматично відповідно до складеного розкладом і перевіряючи наявність прапора відсутність живлення від UPS (файл C: \ POWERFLG \ POWER.FLG). Зараз діє перехідний варіант до цієї моделі роботи: при запуску програми обробки рахунків ЛПУ встановлюється прапор автоматичної обробки, здійснюється перевірка запуску перенесення БД полісів на ORACLE і якщо його не було в останню добу, то він автоматично запускається, а по завершенні перенесення прапор автоматичної обробки знімається .
Про проблеми і помилки програми, а також їх усунення.
Контроль рахунків поліклінік і стоматологій іноді завершується з помилкою "Index iN_KART not found ...". При контролі поліклініки ця помилка була лише один раз за весь час практики, в стоматології - 2-3 рази на тиждень. Схоже ця помилка BDE при виконанні запитів (DBASE + ORACLE). Як правило це трапляється при контролі або великого рахунку стоматології, якого великого і маленького рахунки одночасно. При ручному запуску обробки рахунків я прагнув у стоматології підбирати рахунку приблизно одного розміру. Якщо трапилася ця помилка, то оброблювані рахунки з каталогу D: \ DATA \ STO (D: \ DATA \ AMB) видалити і повторити вхідний контроль.
Якщо щось відбулося при перенесенні рахунків на ORACLE (наприклад, комп'ютер "помер"). У цьому випадку необхідно видалити з ORACLE ті рахунки, перенесення яких було аварійно завершено (з усіх чотирьох таблиць - основний, іногородніх жителів, некоректних і послуг (операцій)).
Далі необхідно очистити відповідні таблиці в D: \ DATA \ TOORA. Це можна зробити програмно, але я просто копіюю потрібні порожні БД з відповідного каталогу. Каталог C: \ TODAY \ TOORA є на моєму комп'ютері і на ROBOT-е. Після того, як всі сліди невдалого перенесення видалені, можна повторити перенесення.
Якщо при контролі рахунків з'явилася помилка "Access violation ...", то повторіть контроль рахунків, попередньо видаливши невдало оброблені рахунку. Якщо помилка повторюється знову, то дивіться вихідний текст програми.

Висновок
Даний курсовий проект з'явився завершальним етапом вивчення дисципліни «Проектування інформаційних систем». Його основна мета полягає в самостійній розробці проектних рішенні, мають практичну цінність, а також в їх техніко-економічному обгрунтуванні. У процесі роботи над курсовим проектом під час техніко-організаційної практики мною були реалізувати отримані теоретичні знання.
Я прагнув до того, щоб цей проект був практично реалізуємо, сприяв вдосконаленню управління, виконувався на конкретних матеріалах, і міг бути використаний на підприємстві. І в кінцевому підсумку ця мета була мною досягнута - версія даного проекту прийнята до відома в Іванівському відділень ТФОМС і скоро планується його впровадження. Особливо корисними виявилися зауваження з приводу існуючого способу передачі інформації в системі.
У перспективі слід покращувати параметри роботи даного продукту як за рахунок поліпшення швидкодії всієї системи в цілому (заміна застарілого обладнання більш новим, створення нових систем передачі інформації і т.д.), так і за допомогою модернізації коду програмних модулів, структури баз даних та ін .
Особливу увагу при удосконаленні системи слід звернути на способи та швидкості передачі інформації, а також на можливі варіанти збільшення продуктивності всієї системи в цілому. Слід прагнути до того, щоб при максимальних інформаційних навантаженнях на окремі комп'ютери (клієнти) досягалися високі показники швидкодії.
Оскільки більша частина інформації, що використовується в системі є особистою таємницею будь-якого громадянина РФ, то необхідно розробити систему для її захисту, а саме: попередження несанкціонованого доступу до даних, а також їх зміну або знищення як з боку «нелегальних» користувачів, так і при збоях апаратних чи програмних засобів. Засоби і методи захисту інформації повинні використовуватися комплексно з використанням технічних і програмних засобів.
До обов'язків адміністратора системи слід включити роботу щодо забезпечення захисту локальних баз даних, а саме:
- Класифікація даних;
- Визначення прав доступу окремих користувачів і обмежень на характер операцій;
- Організація системи контролю доступу до даних;
- Тестування засобів захисту;
- Інші роботи із захисту системи.
У подальшому слід більш повно і комплексно використовувати можливості сучасних операційних систем. Багато функцій адміністратора системи можуть бути покладені на операційну систему. А також необхідно переходити від централізованого до розподіленого способі обробки даних. Розподілена обробка даних дозволяє розмістити базу даних в різних вузлах комп'ютерної мережі. Таким чином, кожен компонент бази даних розташовується за місцем наявності техніки і її обробки.

Список використаних джерел
1. «Підсумки науково-практичної конференції, присвяченої 10-річчю системи обов'язкового медичного страхування» - Медична газета № 44 20.06.2003 Іваново 2003р.
2. «ОМС: реальність і перспективи» - Медична газета № 68 12.09.2003 Іваново 2003р.
3. «Методичні підходи до формування поєднаних і багаторівневих програм медичного страхування в сучасних умовах» - В.В. Пєтухова, М.В. Айвазова та ін - Санкт-Петербурзький інститут медичного страхування М. 2001р.
4. «Робота системи ОМС Івановської області з реалізації програми державних гарантій забезпечення безкоштовною медичною допомогою громадян РФ у 2002 році. Завдання на 2003 рік (Збірник наукових праць) »- Територіальний фонд ОМС по Івановській області, Управління охорони здоров'я Івановської області, Іванівська державна медична академія - Іваново 2003р.
5. «Проектування баз даних (Навчальний посібник)» - В.Г. Шишкін - Іванівський державний університет - Іваново 1999р.
6. «Податки. 4-е видання (навчальний посібник) »- Д.Г. Черник і ін - «Фінанси та статистика» - М. 1999р.
7. «Довідник з мови SQL» - Andrew Mendelsohn, Ken Jacobs і ін - Нью-Йорк 1999р.
8. «Керівництво адміністратора бази даних ORACLE» - Sanjay Bulchandani, Dennis Cochran и др. - Нью-Йорк 1996р.
9. «Проектування баз даних у прикладах і задачах» - Т.І. Гусєва - М. 1992.
10. «Комп'ютерні системи в управлінні фінансами» - А.П. Колесник - М.: "Фінанси і статистика" 1997р.

Додаток № 1
Приклад роздрукування рахунку в режимі «Стаціонар»
Лікувальна установа Родниковська ЦРЛ рахунок № 01 [стаціонар]
Дата рахунку 05.02.2001
Дата прийняття рахунку 06.02.2001
Номер картки 999000
Прізвище ВОРОНЦОВ
Ім'я СЕРГІЙ
По батькові ЄВГЕНОВИЧ
Адреса Родніковської район г.Роднікі Мк-н Шагова д.16 кв.53
Дата народження 29.12.1974
Поліс 0
Вид напрямки Поступив по СМП
Категорія працюючого Працюючий СП
Місце роботи РУП
Профіль ліжка Хірургічні дорослі. Т06.3
Діагноз основний Пошкодження кровоносних судин, захоплюючі кілька областей
тіла
Діагноз супутній S21.1 Відкрита рана передньої стінки грудної клітки
Діагноз ускладнення R57.8 Інші види шоку Екстрена, первинна
Госпіталізація Екстрена, первинна
Дата надходження 28.12.2000 01.01.2001
Час надходження 22.10
Дата виписки 01.01.2001
Тривалість лікування 4
Випадок обслуговування Закінчений
Результат лікування Летальний результат
Спеціальність лікаря ЛІКАР-ХІРУРГ
Вартість Операції: 429,72
Дата
Найменування
28.12.2000
Z38.93 Катетеризація вени ін
28.12.2000
Z46.73 Зшивання розриву тонкої кишки (окрім 12-палої кишки)
28.12.2000
Z39.31 Накладення шва на артерії
29.12.2000
Z38.08 Розсічення артерії нижньої кінцівки
Діагноз безпосередньої причини смерті:
J81. Легеневий набряк Діагноз захворювання, що зумовили причину смерті:
ТО6.З Пошкодження кровоносних судин, захоплюючі кілька областей тіла Діагноз захворювання, що сприяв смертельного результату:
R57.8 Інші види шоку Діагноз патологоанатомічний:
Т06.3 Пошкодження кровоносних судин, захоплюючі кілька областей тіла

Додаток № 2
Приклад роздрукування рахунку в режимі «Поліклініка»
Лікувальна установа Міська клин, б-ца N7 рахунок N'87 [поліклініка]
Дата рахунку 05.02.2001
Дата прийняття рахунку 07.02.2001
Прізвище АВЕР'ЯНОВ
Ім'я БОРИС
По батькові ОЛЕКСІЙОВИЧ
Дата народження 08.07.1926
Поліс 372400 4006580726
Адреса г.Іваново ул.Лежневская д.156 кв.18
Категорія працюючого Пенсіонер
Місце роботи
Привід звернення Лікувально-діагностичний
Тривалість лікування 11
Діагноз основний l6. Коксартроз [артроз кульшового суглоба]
Випадок обслуговування Закінчений
Результат лікування напрямок до ін лікаря
Вартість 9,2
Доп. Інформація до фізіотерапевта

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

Додаток № 3
Приклад роздрукування рахунку в режимі «Стоматологія»
Лікувальна установа Міська клин, б-ца N7 рахунок № 11 [стоматологія]
Дата рахунку 05.02.2001
Дата прийняття рахунку 07.02.2001
Прізвище Андріанова
Ім'я ІРИНА
По батькові ОЛЕКСАНДРІВНА
Дата народження 28.11.1952
Поліс 372400 7008281152
Адреса г.Іваново ул.Вороніна Д.З кв.47
Категорія працюючого Працюючий
Місце роботи Школа-ліцей № 67
Привід звернення лікувально-діагностичний
Тривалість лікування 1
Випадок обслуговування Закінчений
Вихід лікування одужання
Вартість 2,5
Дата
Послуги
Вартість
Діагноз
31.01.2001
Огляд порожнини рота первинного хворого.
0,15
31.01.2001
Збір анамнезу.
0,15
31.01.2001
Оформлення документації первинного хворого.
0,2
Карієс зубів не уточнений
31.01.2001
Цементна пломба на дві поверхні зуба
2
Карієс зубів не уточнений
СУМА (УЄТ) = 2,5

Додаток № 4
Найменування і структура основних довідників.
1. ORACLE: KIS.SVSCHET-довідник зведених рахунків ЛПУ
2. ORACLE: SNMDN_ST-довідник видів денного стаціонару
3. ORACLE: SNMGRAFIK-довідник графіків дн.стаціонаров ЛПУ
4. ORACLE: SNMGRUP-довідник угруповання ЛПУ.
5. ORACLE: SNMKAT-категорії населення при перевірці стаціонару
6. ORACLE: SNMKAT1-категорії населення при перевірці поліклініки
7. ORACLE: SNMMKB-довідник діагнозів
8. ORACLE: SNMMKB_N-довідник взаємозв'язків приводів і послуг
9. ORACLE: SNMMKB_O-довідник ятрогенії
10 ORACLE: SNMNAPRAV-довідник напрямків
11. ORACLE: SNMPO_TAR - тарифи поліклінік, що працюють по повній програмі
12. ORACLE: SNMPO_TAR_C-тарифи поліклінік, які працюють за неповної програмі
13. ORACLE: SNMST_TAR-тарифи стаціонарів, що працюють по повній програмі
14. ORACLE: SNMST_TAR_C-тарифи стаціонарів, які працюють за неповної програмі
15. ORACLE: SNMPROFIL-довідник профілів ліжок
16. ORACLE: SNMSCOB-довідник цілей звернення
17. ORACLE: SNMSPR_INV-довідник видів інвалідності
18. ORACLE: SNMSPR_LPU-довідник ЛПУ
19 ORACLE: SNMSPR_OTK-довідник відмов
20. ORACLE: SNMSPUSL-довідник послуг стоматології
21. ORACLE: SNMSPL-довідник результатів лікування
22. ORACLE: SNMTARIF1-довідник спеціальностей лікарів
23. ORACLE: SNMUSLUGI-довідник послуг
24. ORACLE: SNMYEAR-календар роботи 6-дн. денного стаціонару
25. ORACLE: SNMYEAR_5-календар роботи 5-дн. денного стаціонару
1.ORACLE: KIS.SVSCHET - довідник зведених рахунків ЛПУ
KOD_LPU NUMBER (3, 0) Код ЛПУ
VID NUMBER (1, 0) Вид ЛПУ
N_SCH VARCHAR2 (10) Номер рахунку
DT_SCH DATEДата формування рахунки
DT_IN DATEДата первинної обробки рахунки
COUNT NUMBER (6, 0) Кількість коректних записів
TOTAL NUMBER (10, 2) Вартість коректних записів
COUNT_BAD NUMBER (6, 0) Кількість некоректних записів
TOTAL_BAD NUMBER (10, 2) Вартість некоректних записів
DOG_YN NUMBER (1, 0) Ознака роботи по повній програмі
FIRST NUMBER (1, 0)
OMS NUMBER (1, 0) Ознака перевірки відділом ОМС
MEDEKS NUMBER (1, 0) Ознака перевірки експертами
PEO NUMBER (1, 0) Ознака обробки рахунку плановим відділом
ARX ​​NUMBER (1, 0) Ознака відправки рахунку в архів
EKSPERT NUMBER (1, 0)
2. ORACLE: SNMDOGOVOR - ЛПУ, що працюють по повній програмі
LPU NUMBER (3, 0) Код ЛПУ
DATA DATE Дата укладення договору
3. ORACLE: SNMDN_ST - довідник видів денного стаціонару
KOD NUMBER (1, 0) Код виду денного стаціонару
PROFIL CHAR (3) Профіль ліжка
NAIM VARCHAR2 (40) Найменування
GRAFIK NUMBER (1, 0) Вид графіка
4. ORACLE: SNMGRAFIK - довідник графіків дн.стаціонаров ЛПУ
KOD_LPU NUMBER (3, 0) Код ЛПУ
VID NUMBER (1, 0) Вид денного стаціонару
GRAF NUMBER (1, 0) Графік денного стаціонару
5. ORACLE: SNMGRUP - довідник угруповання ЛПУ.
GLAV CHAR (3) Код головного ЛПУ
LPU CHAR (5) Код ЛПУ в символьному форматі
LPU_N CHAR (5) Код ЛПУ в числовому форматі
PUTH1 VARCHAR2 (30) Шлях для розсилки
GLN NUMBER (3, 0) Код головного ЛПУ в числовому форматі
NLPU NUMBER (4, 0)
RAI NUMBER (3, 0) Код району
SS NUMBER (1, 0)
6. ORACLE: SNMKAT - категорії населення при перевірці стаціонару
KATEGOR NUMBER (1, 0) Категорія населення
NAIM VARCHAR2 (25) Найменування
7. ORACLE: SNMKAT1 - категорії населення при перевірці поліклініки
KATEGOR NUMBER (1, 0) Категорія населення
NAIM VARCHAR2 (25) Найменування
8. ORACLE: SNMMKB - довідник діагнозів
GRU NUMBER (3, 0)
KOD VARCHAR2 (8) Код діагнозу
NAIM VARCHAR2 (72) Найменування
HIR CHAR (2)
9. ORACLE: SNMMKB_O - довідник ятрогенії
KOD VARCHAR2 (8) Код діагнозу
NEK NUMBER (2, 0) Код відмови
10. ORACLE: SNMMKB_N - довідник взаємозв'язків приводів і послуг
COB NUMBER (1, 0) Код звернення
KOD VARCHAR2 (8) Код діагнозу
NEK NUMBER (2, 0) Код відмови
FLG NUMBER (1, 0) Прапор
11. ORACLE: SNMNAPRAV - довідник напрямків
KOD NUMBER (2, 0) Код напряму
NAIM VARCHAR2 (40) Найменування
15. ORACLE: SNMPROFIL - довідник профілів ліжок
KOD CHAR (3) Код профілю ліжка
NAIM VARCHAR2 (30) Найменування
SR_DL NUMBER (5, 2) Середня тривалість
SR_DL1 NUMBER (5, 2) Середня тривалість
16.ORACLE: SNMSCOB - довідник цілей звернення
KC NUMBER (2, 0) Код звернення
NC VARCHAR2 (25) Найменування
18. ORACLE: SNMSPR_LPU - довідник ЛПУ
KOD_LPU NUMBER (3, 0) Код ЛПУ
NAIM_LPU VARCHAR2 (45) Найменування
KOD_TMO NUMBER (2, 0)
VL NUMBER (1, 0)
ADR_LPU VARCHAR2 (50) Адреса
FIO_LPU VARCHAR2 (20) Керівник
TEL_LPU VARCHAR2 (9) Телефон
KOD_RAY NUMBER (2, 0) Код району
RAS_CH CHAR (20) Розрахунковий рахунок
BANK VARCHAR2 (50) Найменування банку
GOROD_BN VARCHAR2 (25) Місто банку
INN VARCHAR2 (15) ІПН ЛПУ
OKONX VARCHAR2 (10) Код ЗКГНГ
OKPO VARCHAR2 (8) Код ЄДРПОУ
20. ORACLE: SNMSPL-довідник результатів лікування
KRL NUMBER (2, 0) Код результату лікування
NRL VARCHAR2 (30) Найменування
21. ORACLE: SNMTARIF1 - довідник спеціальностей лікарів
KOD NUMBER (3, 0) Код спеціальності лікаря
SPEC VARCHAR2 (45) Найменування
22. ORACLE: SNMUSLUGI - довідник послуг
KODUSL NUMBER (1, 0) Код послуги
NUSL VARCHAR2 (20) Найменування
25. ORACLE: SNMYEAR_5 - календар роботи 5-дн. денного стаціонару
YEAR NUMBER (4, 0) Рік
MES_1 CHAR (42) 1-й місяць року
MES_2 CHAR (42) 2-й місяць року
MES_3 CHAR (42) 3-й місяць року
MES_4 CHAR (42) 4-й місяць року
MES_5 CHAR (42) 5-й місяць року
MES_6 CHAR (42) 6-й місяць року
MES_7 CHAR (42) 7-й місяць року
MES_8 CHAR (42) 8-й місяць року
MES_9 CHAR (42) 9-й місяць року
MES_10 CHAR (42) 10-й місяць року
MES_11 CHAR (42) 11-й місяць року
MES_12 CHAR (42) 12-й місяць року

Додаток № 5
Код основного модуля
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
StdCtrls, ComCtrls, Buttons, ExtCtrls, RxGrdCpt, Grids, DBGrids,
bdeutils, fileutil, strutils, Db, DBTables, RXCtrls, SpeedBar, vclutils, ToolWin,
ImgList, DBLists;
type
TForm1 = class (TForm)
RxGradientCaption1: TRxGradientCaption;
SpeedBar1: TSpeedBar;
SpeedbarSection1: TSpeedbarSection;
SpeedItem1: TSpeedItem;
ToolBar1: TToolBar;
tbtn1: TToolButton;
tbtn2: TToolButton;
RxGradientCaption2: TRxGradientCaption;
ImageList1: TImageList;
Panel1: TPanel;
Animate1: TAnimate;
Label1: TLabel;
ToolButton1: TToolButton;
RxGradientCaption3: TRxGradientCaption;
Label2: TLabel;
Tbtn3: TToolButton;
procedure FormShow (Sender: TObject);
procedure SpeedItem1Click (Sender: TObject);
procedure ToolButton1Click (Sender: TObject);
procedure FormCreate (Sender: TObject);
procedure FormDestroy (Sender: TObject);
private
{Private declarations}
procedure TblUpdt (s: TDatabaseItems);
public
{Public declarations}
end;
var
Form1: TForm1;
reg: Byte;
implementation
{$ R *. DFM}
uses data1, Data, main;
procedure create_msg (fi: string; n_ch: integer; d: tdatetime; cou, cou_bad: integer; tot, tot_bad: real);
const
str1: AnsiString = 'Отримано рахунок:';
str2: AnsiString = 'Рахунок:';
str3: AnsiString = 'Дата:';
str4: AnsiString = 'Результати автоматичної перевірки:';
str5: AnsiString = 'Документів без помилок';
str6: AnsiString = 'Документів з помилками';
str7: AnsiString = 'Відділ АІО ТФ ОМС г.Іваново';
str8: AnsiString = 'на суму';
var f: textFile;
begin
if fileexists (fi) then Exit;
AssignFile (f, fi);
Rewrite (f);
writeln (f, strtooem (str1));
writeln (f, strtooem (str2) + inttostr (n_ch));
writeln (f, strtooem (str3) + DateTimeToStr (d));
writeln (f, strtooem (str4));
writeln (f, strtooem (str5) + IntToStr (cou) + strtooem (str8) + floattostrF (tot, ffFixed, 10,2));
writeln (f, strtooem (str6) + IntToStr (cou_bad) + strtooem (str8) + floattostrF (tot_bad, ffFixed, 10,2));
writeln (f, strtooem (str7));
CloseFile (f);
end;
procedure create_pst (p, fi1, fi2: string);
var f: textFile;
begin
AssignFile (f, fi1);
Rewrite (f);
writeln (f, 'PATH:' + p);
writeln (f, 'FILE:' + fi2);
writeln (f, strtooem ('ХТО: decodsch.exe'));
writeln (f, strtooem ('ДАТА:' + datetimetostr (now)));
CloseFile (f);
end;
procedure ChangeLangDrv (drv: string);
var l: TStrings;
begin
Session.Close;
l: = TStringList.Create;
l.Add ('LANGDRIVER =' + drv);
Session.ModifyDriver ('DBASE', l);
Session.Open;
l.Free;
end;
procedure kod_lpu (t: TTable);
begin
t.TableName: = 'L2' + Copy (t.TableName, 3,3) + '. DBF';
t.Open;
if not (t.IsEmpty) then
with dm1.Query1 do begin
Close;
SQL.Clear;
sql.Add ('UPDATE AMB_US SET KOD_LPU =' +
t.FieldByName ('kod_lpu'). asstring + ', N_CH ='''+
t.FieldByName ('n_ch'). asstring +''', DAT_SC ='''+
t.FieldByName ('dat_sc'). AsString +'''WHERE KOD_LPU IS NULL');
ExecSQL;
end;
t.Close;
end;
procedure TForm1.TblUpdt (s: TDatabaseItems);
var t: TTable;
begin
Label1.Caption: = 'Йде підготовка таблиць ...'; delay (10);
t: = TTable.Create (self);
case reg of
1: t.DatabaseName: = 'dbSTA';
2: t.DatabaseName: = 'dbAMB';
4: t.DatabaseName: = 'dbSTO';
end;
{Створення БД переносяться 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.
Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Курсова
259.8кб. | скачати


Схожі роботи:
Проектування інформаційного забезпечення
Розробка АРМ начальника фінансового відділу
АРМ менеджера відділу продажів ТЦПУ ВАТ Центральний телеграф
Організаційне забезпечення діяльності відділу документаційного забезпечення управління Костромської
Функціональна спрямованість програмне та апаратне забезпечення АРМ Нормоконтролер
Проектування систем автоматизації
Удосконалення інформаційного забезпечення організації
Проблема автоматизації проектування в теорії систем
Статистична звітність як джерело інформаційного забезпечення
© Усі права захищені
написати до нас