Содержание к диссертации
Введение
ГЛАВА I. Обзор требований к специализированным информационным системам и их разработке 12
1. Анализ требований к медицинской информационной системе 12
2. Обзор существующих информационных систем (ИС) 16
3. Выбор методологии разработки и среды проектирования ИС 20
4. Выводы 24
ГЛАВА II. Оптимальное проектирование концептуальной и серверной моделей с применением теории графов 26
1. Место ER- модели в процессе проектирования баз данных 27
2. Структура ER-модели 28
3. Методика проектирования концептуальной и серверной моделей медицинской информационной системы 35
4. Методика оптимизации структуры концептуальной модели на основе теории графов 39
5. Декомпозиция центрального Е-графа множеством планарных графов методом вершинной раскраски 46
6. Создание серверной модели на основе оптимизированной Е11-модели 50
7. Выводы 53
ГЛАВА III. Создание информационной системы «ариадна» на основе оптимизированной серверной модели . 55
1. Структура и характеристика разрабатываемой ИС 55
2. Фазы жизненного цикла разработки ИС 57
2.1 Фаза стратегии 61
2.2 Фаза анализа 62
2.3 Фаза разработки (создание концептуальной модели) 64
2.4 Фаза построения (создание серверной модели) 64
2.5 Фаза построения (создание пользовательских форм) 65
3. Организация отчётной информации разработанной ИС 74
4. Выводы 78
ГЛАВА IV Аналитический блок информационной системы ариадна 79
1. Аналитический блок системы 79
2. Выводы 85
Заключение 86
Библиографический список 88
Приложения 97
- Выбор методологии разработки и среды проектирования ИС
- Методика проектирования концептуальной и серверной моделей медицинской информационной системы
- Создание серверной модели на основе оптимизированной Е11-модели
- Фаза построения (создание пользовательских форм)
Введение к работе
Администрации, врачам и другим сотрудникам лечебно-профилактических медицинских учреждений (ЛПУ) приходится сталкиваться с огромными объёмами информации. Им требуется обеспечить хранение этой информации, её целостность, быстрый и контролируемый доступ, безопасность данных и возможность анализа [4, 51, 78, 30]. В информационных технологиях (ИТ) такие возможности реализуются в системах управления базами данных (СУБД). Сервер базы данных организует работу с пользователями и данными: создание мест хранения, организация доступа к данным, сохранность информации и многое другое [12, 15, 18]. В первых разработках, использовались доступные тогда базы данных, такие как FoxPro, Paradox, Access либо такого же уровня. Хранилища наполнялись информацией, увеличивался список необходимой информации, тем самым, повышая требования к базам данных. Такой же путь прошли и другие области человеческой деятельности. Известно, что наибольшее развитие информационные системы получили в финансовой и производственной деятельности человека. Были разработаны информационные инфраструктуры для больших предприятий с сотнями пользователей и едиными базами данных. Однако, для ЛПУ такие работы еще не получили должного развития.
Для успешного решения основных задач ЛПУ необходимо создание информационных систем (ИС) в медицине с применением СУБД. Одним из важнейших факторов успешного создания и последующего использования и расширения функциональности ИС является выбор среды и методологии разработки [5, 9, 21, 26, 35]. Среда разработки должна обеспечивать актуальность ядра СУБД в быстро развивающейся отрасли ИТ. Методология
разработки обязана быть такой, чтобы контролировать рост функциональности системы на протяжении всего срока её эксплуатации. Во вновь разрабатываемой рентгенологической информационной системе (РИС) «Ариадна» должен быть сделан шаг к созданию действительно эффективной, расширяемой, производительной, многопользовательской системы в среде Oracle, как в наиболее развитой и постоянно обновляемой объектно-реляционной базе данных в настоящее время [26, 41, 79, 96]. Выбранная методология разработки и сопровождения Oracle CADM уже доказала свои возможности при расширении функциональности этой системы на практике.
Поэтому актуальной стала задача проектирования такой серверной модели базы данных, которая была бы свободной от ошибок предшествующих моделей. Для этого предлагается методика проектирования серверной модели на основе концептуальной модели, которая должна базироваться на оптимизации своей структуры, представленной в виде графа по критерию минимизации времени его обхода с учетом выполнения функциональных ограничений.
Цель исследования
Целью диссертационной работы является повышение эффективности работы ЛПУ путем разработки методики проектирования оптимальной концептуальной и серверной моделей информационных систем и создание на этой базе информационной системы для ЛПУ.
Задачи исследования
Для достижения поставленной цели решался ряд последовательных и взаимосвязанных задач:
1. Систематизация и анализ существующих медицинских информационных систем, выявление их недостатков по средам
7 разработки и формулирование ряда требований к разработке ИС.
Представление концептуальной модели системы центральным ориентированным графом и разработка методики оптимизации структуры серверной модели на основе теории графов.
Создание программного продукта ИС «Ариадна», его внедрение в медицинские учреждения.
4. Создание блока аналитических исследований и визуализации
статистики для прогнозирования развития заболеваний.
Объём и структура работы
Диссертация изложена на ПО страницах машинописного текста и включает 10 таблиц, 31 рисунок. Диссертация состоит из введения, 4 глав исследований, выводов и практических рекомендаций, а также 4 приложений на 14 страницах. В списке литературы содержится ПО источников литературы.
В первой главе содержится обзор требований к специализированным информационным системам и их разработке, описаны подходы, используемые при проектировании ИС. Во второй главе даётся описание предложенной методики разработки концептуальной модели на основании теории графов, а также приводится разработанная методика оптимизации данной модели. В третьей главе приводится описание построения специализированной информационной системы на основании выявленных требований, с использованием выбранной оптимальной методологии разработки на СУБД Oracle, а также с применением разработанной методики моделирования оптимальной концептуальной модели. В четвёртой главе приводятся результаты реализации разработанной специализированной информационной системы, проводится статистический анализ данных, полученный при использовании МИС «Ариадна».
8 Научная новизна работы
1. Проведён анализ современных СУБД в соответствии с требованиями к
медицинским информационным системам. Осуществлены
количественные сравнения показателей функционирования
существующих систем. Обоснован выбор СУБД Oracle для реализации
рентгенологической информационной системы.
2. Поставлена и решена задача создания методики моделирования и
проектирования концептуальных и серверных моделей медицинских
информационных систем на основе элементов теории множеств и
теории графов.
Разработана методика оптимизации структуры концептуальной ER-модели на основе исследования математической модели с помощью теории графов.
На базе разработанных методик построены концептуальная и серверная модели системы.
Основные положения, выносимые на защиту
Методика проектирования концептуальной и серверной моделей медицинской информационной системы.
Методика оптимизации структуры концептуальной ER-модели на основе исследования математической модели в теории графов.
Математическая модель концептуального представления в разработанной медицинской информационной системе «Ариадна».
ИС «Ариадна», как пример реализации выбранных методов разработки, внедрения, расширения и сопровождения информационных систем.
Формы пользовательского интерфейса ИС «Ариадна» и настраиваемая система отчётности по МКБ-10.
Выборки из базы данных, при использовании которых пользователь получает возможность анализа информации по ЛПУ.
Методы исследования и фактический материал, используемые в работе
Методы исследования в данной работе: системный подход при анализе бизнес-процессов и составлении диаграмм функциональной модели; методы пошагового проектирования концептуальной и серверной моделей; положения и элементы теории графов при составлении адекватной концептуальной математической модели, методы нахождения кратчайшего пути обхода графа и методы его декомпозиции; теория множеств, методы оптимизации. Методы математической статистики при создании аналитического блока визуализации и оценки центральных моментов репрезентативных выборок.
Фактический материал предоставлялся работниками исследуемых ЛПУ и статистическими базами данных по городу, в котором они расположены. Был проведен троекратный опрос работников ЛПУ на фазе стратегии при определении структуры системы и ее функциональных связей. Было опрошено 80 человек, на каждого тратился один рабочий день. Получена генеральная совокупность - опрошено 100% контингента служащих ЛПУ.
Практическая значимость работы
Исследования, проведённые в работе: модели бизнес процессов и концептуальные модели могут быть использованы при создании медицинских информационных систем. Проведённые обследования медицинских учреждений также могут быть полезны в работах подобного плана. Важным фактором успешной разработки, внедрения, расширения и сопровождения системы явился
10 выбор методологии создания ИС, рекомендации по которым могут применяться для создания любых управляющих систем. Найденные технологические решения позволяют автоматизировать медицинские учреждения любого профиля.
Создана уникальная система внешней и внутренней статистической отчетности, позволяющая как генерировать стандартные формы отчетов, так и произвольные по желанию пользователя.
Проведено создание блока аналитических исследований, который визуализирует статистику и позволяет прогнозировать развитие заболеваний.
Результатом данной работы явилось создание информационной системы «Ариадна» для ЛПУ, отвечающей сформулированным требованиям к медицинским информационным системам. База данных и программы для ЭВМ системы «Ариадна» бьши запатентованы [2, 3].
Использование системы в медицинском учреждении позволяет иметь и эффективно использовать единый банк данных по всей информации, с которой приходится сталкиваться персоналу учреждения. Прежде всего, это данные по пациентам ЛПУ, необходимые врачам для успешной и более эффективной работы с людьми.
Система внедрена и используется успешно в течение нескольких лет в Государственном (федеральном) учреждении здравоохранения "Медико-санитарная часть №174" Федерального управления медико-биологических и экстремальных проблем при Министерстве здравоохранения Российской Федерации.
Апробация и публикация работы
Результаты выполненных исследований по теме диссертации опубликованы в десяти печатных работах. Основные теоретические и прикладные результаты исследования бьши представлены, докладывались и обсуждались на выставках и конференциях: Международные выставки «Здравоохранение - 2001/2002/2003» (Москва); выставки «Информационные
11 технологии в медицине - 2002/2003» (Москва); выставка «МедКомТех - 2004» (Москва); VI Международная научно-практическая конференция "Новые информационные технологии в целлюлозно-бумажной промышленности и энергетике" (Петрозаводск, 2004); Республиканская научно-практическая конференция "Инвестиционный климат и предпринимательство в регионах России" (Петрозаводск, 2004); на семинаре кафедры Математического моделирования систем управления Петрозаводского государственного университета (Петрозаводск, 2004).
Выбор методологии разработки и среды проектирования ИС
Основных методологий существует несколько. В данной главе рассмотрены методологии Oracle CADM, Microsoft MSF. Они являются одними из наиболее используемых и показательных [8, 41, 62, 80]. На их примере продемонстрирован полный цикл разработки продукта и основные составляющие успешного проектирования ИС.
Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT-решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT-проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral) [80].
Модели процессов описывают последовательность действий, осуществляемых в ходе реализации проекта. Можно сказать, что они задают тем самым жизненный цикл проекта. Спектр моделей, применяемых в настоящее время различными организациями, весьма широк. Среди них есть и модель процессов MSF, возникшая на основе используемого в Майкрософт подхода к разработке программных приложений. В результате своего развития она объединила ряд наиболее эффективных принципов других известных моделей процессов, сформировав при этом единую базу для работы над проектами любых типов: ориентированных на фазы (phase-based), основанных на вехах/контрольных точках (milestone-driven) и итеративных (iterative). Модель MSF применима к процессу разработки традиционного программного обеспечения, но также она может быть использована для разработки и внедрения решений в области электронной коммерции (e-commerce), распределенных сетевых приложений (web-distributed applications) и других сложных информационных систем, которые могут возникнуть в будущем.
Двумя наиболее популярными моделями процессов, используемыми в области информационных технологий, в настоящий момент являются каскадная и спиральная модели.
Каскадная модель. В этой модели вехи используются в качестве точек оценки и перехода от одной фазы к другой. Все задачи, относящиеся к одной фазе, должны быть завершены до того, как начнется следующая фаза. Каскадная модель работает наилучшим образом, когда на начальном этапе проекта можно четко определить неизменный набор требований к разрабатываемому решению. Фиксация переходов от одной фазы к другой облегчает распределение ответственности, отчетность и следование календарному графику проекта.
Спиральная модель. Эта модель учитывает необходимость постоянного пересмотра, уточнения и оценки проектных требований. Такой подход может быть очень эффективным при быстрой разработке небольших проектов. Он стимулирует активное взаимодействие между проектной группой и заказчиком, поскольку заказчик оценивает ход и результаты работы на протяжении всего проекта. Недостатком спиральной модели является отсутствие четких вех, что может привести к хаотизации процесса разработки.
Модель процессов MSF (схематически изображенная на рис. 4) объединяет в себе лучшие принципы каскадной и спиральной моделей. Она сохраняет преимущества упорядоченности каскадной модели, не теряя при этом гибкости и творческой ориентации модели спиральной. Детали организации вех и фаз модели процессов MSF рассматриваются далее.
Тремя особенностями модели процессов MSF являются: Подход, основанный на фазах и вехах. Итеративный подход. Интегрированный подход к созданию и внедрению решений. Итеративный подход к процессу разработки широко используется в MSF. Программный код, документация, дизайн, планы и другие рабочие материалы создаются, как правило, итеративными методами. Основными фазами CADM (CASE Application Development Method) являются стратегия, анализ, разработка, построение, тестирование, реализация и обслуживание [41, 62]. На фазе стратегии все внимание направлено на получение ясного представления о деятельности учреждения, объектах, с которыми оно работает, о направлении этих работ и области охвата для структурирования и документирования общего представления о проекте. Фаза анализа является одним из важнейших этапов в проектировании системы. Совместными усилиями пользователей и разработчиков проводится сбор всех пользовательских спецификаций проекта и полное завершение детализации рассматриваемых в проекте бизнес-процессов. На фазе разработки формируется предварительный вариант создаваемой системы: разработка плана, формирование схемы потоков процессов, разработка стандартов, создание концептуальных прототипов экранов. К фазе построения относятся две области: база данных и приложения. Конфигурируются физическая область базы данных, заносятся данные в соответствующие таблицы, создаются приложения. Тестирование - одна из наиболее важных фаз в процессе разработки систем. Основным условием правильного тестирования являются многочисленные тесты. Тестирование должно проводится при непосредственном участии пользователей системы. Одним из факторов, важных с точки зрения успешного прохождения фазы внедрения, является надлежащая поддержка со стороны пользователей системы. Составляется подробная документация для них, а также проводится обучение пользованию системой. Главной целью фазы обслуживания (сопровождения) является выявление, определение важности и управления возникающими вопросами для последующего внесения изменений в систему. Такие корпорации, разработчики программного обеспечения, как Oracle и Microsoft, пришли к одинаковому выводу, что проектирование должно проводиться каскадно-спиральным методом, который основан на фазах, также должен быть итеративным и интегрированным к созданию и внедрению решений. При анализе современных медицинских информационных систем [4, 29, 51, 68, 78], было отмечено, что в настоящее время в России нет медицинской информационной системы, которая отвечала бы всем выявленным требованиям к МИС, а также была разработана в соответствии с оптимальной методологией в объектно-реляционной СУБД.
Методика проектирования концептуальной и серверной моделей медицинской информационной системы
Проектирование реляционной базы данных - это преобразование модели в работоспособное программное решение [13, 24, 42, 106]. Сущности (или объекты), воспринимаемые пользователем, преобразуются в таблицы базы данных. Любое «ручное» проектирование - это смесь правил, суждений и здравого смысла, и проектирование реляционных баз данных не является исключением [17, 20, 26, 65].
Цель на стадии проектирования - это создание надёжных и производительных систем на основе результатов предварительного анализа [41, 50, 109]. Но нельзя исключить тот факт, что спроектированная другим разработчиком ИС не будет производительней и надёжней. Предположим, что надёжность будет обеспечиваться выбором среды разработки Oracle. Тогда возникает потребность в автоматизации проектирования ИС, а именно, в применении математических методов при выборе структуры [1], которые обеспечили бы максимальную производительность.
Рассмотрим информационную концептуальную модель - ER-модель (Entity Relationship Diagram - сущность-связь). Entity Relationship Diagrammer (диаграмматор взаимосвязи элементов в Oracle Designer). Эта логическая модель данных показывает сущности (элементы) и их атрибуты вместе с взаимосвязями. ER Diagrammer поддерживает элементы подтипов/супертипов вместе с дуговыми отношениями (взаимоисключающими) данные [17, 41]. Модель «сущность-связь» (ER-модель) создаётся на основе словесных описаний или документов, описывающих информационные потребности и правила организации. Такая модель является графическим представлением информационных потребностей и правил [48]. ER-модель отражает взаимосвязанную информацию, необходимую для ведения производственной деятельности предприятия (учреждения). Хотя производственные процессы могут со временем изменяться, используемая информация обычно довольно постоянна. Следовательно, и структура данных меняется редко [38, 56]. Преимуществами ER-модели являются [46, 67]: Документирование информационных потребностей организации в понятном и точном формате. Понятное графическое представление проекта базы данных. Простота разработки и совершенствования модели. Чёткое определение круга информационных потребностей. Эффективная среда для интеграции приложений, разрабатываемых проектов и закупаемого прикладного программного обеспечения. 2. Структура ER-модели ER-модель состоит из сущностей, атрибутов и связей [13, 41]. Сущность представляет существенный объект или факт в системе организации, дискретную категорию или совокупность взаимосвязанных данных. Для представления сущности в модели используется следующая система обозначений [27, 41, 72]: Рамка со скруглёнными углами произвольного размера. Уникальное имя сущности. Имя сущности пишется прописными буквами. Атрибут описывает сущность и содержит необходимую конкретную информацию о ней. Если сущность не имеет атрибутов, необходимых с точки зрения бизнеса, она не входит в набор требований к системе и не должна появляться в модели. Каждый атрибут или обязателен, или необязателен. Это свойство называется «опциональностью» (optionality) [41, 58]. Для представления атрибута в модели используется следующая система обозначений: Уникальное имя указывается строчными буквами. Обязательные атрибуты или значения, которые должны быть известны, помечаются символом « ». Необязательные атрибуты или значения, которые могут быть известны, помечаются символом «о». Уникальный идентификатор (UID) - это любая комбинация атрибутов, связей или того и другого, которая служит для различения экземпляров сущности. Каждый экземпляр сущности должен быть однозначно узнаваем [73, 102]. Атрибуты, входящие в UID, помечаются символом номера - #. Вторичные UID помечаются символом номера в скобках (#). Каждая сущность должна иметь связь, представляющую информационные потребности и правила организации. Связь - это двунаправленная ассоциация между двумя сущностями или между сущностью и ей самой. Если сущность связана сама с собой, такая связь называется рекурсивной. Каждое направление связи имеет: зо Имя/название. Опциональность (optionality) - должно быть или может быть. Мощность (degree) - один и только один или один или более. Синтаксис представления связей следующий (схему принято читать по часовой стрелке): каждая исходная сущность {может быть должна быть} имя связи {один и только один один или более} конечная сущность. Условные обозначения для связей представлены в Таблице 2. Типы связей бывают следующими [30, 103]: Один к одному. Мощность «один и только один» в обоих направлениях. Связи этого типа встречаются редко и в действительности могут оказаться той же сущностью или атрибутом сущности. Много к одному. Мощность «один и более» в одном направлении и «один и только один» в другом. Такие связи широко распространены. Много ко многим. Мощность «один или более» в обоих направлениях. Такие связи представляются с помощью сущности пересечения. Прежде, чем приступать к работе над проектом базы данных, можно устранить проблемы избыточности данных путём нормализации модели данных [20, 26]. Прежде, чем создавать реальную базу данных, необходимо модифицировать модель данных путём нормализации хранения данных таким образом, чтобы она удовлетворяла различным требованиям.
Создание серверной модели на основе оптимизированной Е11-модели
При проведении бизнес-анализа для создания специализированной медицинской информационной системы, а именно, рентгенологической ИС, было отмечено, что лечебно-профилактическое учреждение имеет единое информационное пространство. Первоначально была поставлена задача -организовать рабочее место врача - рентгенолога и лаборанта рентгенологического кабинета. Но при разработке системы стало ясно, что без модуля «Регистратура», информационная рентгенологическая система не будет полноценной. А для того, чтобы указывать, к какому именно врачу-рентгенологу обратился пациент и прошел обследование, необходимо использовать еще и модуль «Отдел кадров». Так, еще на стадии опроса медицинского персонала, было выявлено уже несколько рабочих мест, которые необходимо разработать. На Рис. 13 представлена структура ИС «Ариадна», на которой наглядно представлены различные автоматизированные рабочие места.
При использовании выбранной методологии CADM, существует возможность расширять систему, дополняя вновь обследованные различные процессы ЛПУ. Система является модульной, что отвечает одному из требований к МИС. При доступе к одной базе данных пользователей с различной направленностью деятельности, необходимо организовывать различные рабочие места. Например, врачу-рентгенологу не нужна такая полная информация о пациенте, как врачу-онкологу. А медицинский статистик должен видеть меньше информации, чем главный врач ЛПУ. Каждый модуль выполняет свои строго определенные функции.
В данной главе разбирается работа АРМа Медицинского статистика. В Медсанчасти №174, принадлежащей Минатому, на функционирующей системе, рассмотрим рабочее место, которое было создано специально для ведомственной поликлиники, где отчетность является более развернутой и полной, чем в стандартных ЛПУ.
Исходя из требований, которые перечислены выше, был сделан выбор базы данных Oracle, при этом использовались инструментальные средства Oracle для разработки приложений [41, 48]. Этот выбор является залогом того, что в будущем расширение или углубление системы будет возможно до тех пор, пока существует поддержка программных продуктов Oracle. Разработка программного обеспечения проходит с использованием CASE-средств в соответствии с методологией CADM [26, 41, 65].
Как было отмечено в Главе I данной работы, основными фазами такой методологии являются: стратегия, анализ, разработка, построение (базы данных и приложения), тестирование, внедрение и обслуживание (сопровождение). Для разработки приложения «Ариадна» был выбран программный продукт корпорации Oracle под названием Designer, который является CASE-средством [26, 41, 45].
Этот продукт поддерживает все фазы полного жизненного цикла разработки системы. Каждая фаза жизненного цикла программной продукции находит свою поддержку в Oracle Designer с использованием отдельного инструмента (Таблица 8) [26, 41, 54]. Oracle Designer соответствует традиционному составу компонентов. Он имеет репозиторий, реализованный системой управления реляционной базой данных Oracle [77, 98, 104]. Репозиторий состоит из объектов базы данных, хранящих информацию о системе, которую будут анализировать, проектировать и строить. Поскольку репозиторий содержится в стандартной базе данных Oracle, он обладает всеми преимуществами многопользовательской системы: защитой, связанностью, параллелизмом и доступностью. Достоинством общедоступного слоя с метаданными является то, что вся группа разработчиков может обращаться к определениям из репозитория и работать с общей моделью. Клиентский компонент Oracle Designer имеет многочисленные экраны и утилиты для манипулирования данными из репозитория. Кроме того, Oracle обеспечивает метод разработки оконечных программных продуктов для доступа к репозиторию не только инструментальными средствами Oracle Designer.
Каждая фаза жизненного цикла программной продукции находит свою поддержку в Oracle Designer с использованием отдельного инструмента (Рис. Функциональные категории Designer состоят: Моделирование требований к системе (для фаз стратегии и анализа) Генерирование предварительного решения (для фаз разработки и предварительной разработки) Разработка и генерация (для фаз разработки и построения) Утилиты (для работ во время всего жизненного цикла разработки) Для каждой функциональной категории имеются свои инструменты разработки. Process Modeller (модельер процессов), иногда именуемый ВРМ (Business Process Modeller) - отображает процессы и потоки вместе со структурными элементами, обрабатываемыми процессами. Работа с ВРМ — это анализ бизнес-процессов. Инструмент поддерживает работу по представлению процессов на фазах стратегии и анализа. Уникальным свойством этого диаграмматора является его использование для создания диаграмм, представляющих отделы или подразделения компании со свойственными им бизнес-процессами, потоками данных и операциями по сохранению данных. Кроме того, можно перейти от процессов верхнего уровня к процессам нижнего уровня и отражающим их диаграмм подпроцессов. Инструмент позволяет создать диаграмму потока данных между процессами и хранилищами данных.
Фаза построения (создание пользовательских форм)
Серверная модель информационной системы «Ариадна» представляет собой 101 связанную таблицу, в которой находится 698 полей. Центральной таблицей, хранящей данные, является таблица RISMEN. От неё идут связи к таблицам в трёх направлениях: 1. Таблицы, описывающие данные о человеке. Например, таблицы, содержащие данные о предприятии, на котором работает человек (ris_enterprises), где проживает человек (ris_admin_units) и т.д. 2. Связь с таблицей ris_employees, где содержится информация о работающих в лечебно-профилактических учреждениях. 3. Связь с таблицей ris_patients, где хранится информация о пациентах. Таблицы risemployees и ris_patients не связаны внешними ключами, но большинство запросов к базе данных использует одновременно информацию из этих таблиц. Например, выдача больничного листа (таблица ris_document_disableds), связана с таблицами risemployees, ris_patients и risdiseases. То есть, указывается - какой врач, какому пациенту и по какому заболеванию выдал больничный лист. Таблица ris_patients имеет множество связей, которые связывают её со справочниками и классификаторами, определяющими статус пациента. Примером могут служить такие таблицы, как ris_category_patients (определяет категорию пациентов - пенсионеры, учителя, пищевики и т.д.), ris_group_risks (группа риска, к которой принадлежит пациент - хронический алкоголизм, наркомания, рентгеноположительные), ris_invalids (к какой группе инвалидности принадлежит пациент, причина инвалидности, дата установления) и т.д. К другой основной таблице, ris_employees, также проходят связи к таблицам, определяющим статус человека, работающего в ЛПУ. Также имеются шаблоны расписания работы врачей (ris_schedule_time), которые устанавливаются определённому врачу (ris_doctor_schedule). Таблица ris_medical_specialities определяет медицинскую специализацию, которая присвоена врачу (хирург, терапевт, отоларинголог и т.д.), таблица risadminspecialities определяет должность работающего в ЛПУ (заведующий поликлиникой, старшая медсестра, лаборант и т.д.). В системе реализован авторизованный доступ как на уровне сервера Oracle, так и на уровне приложения «Ариадна». Несколько таблиц следят за тем, какие данные может изменять, просматривать каждый пользователь (ris_roles, ris_rights, ris_users, ris_user_parameters, ris_users_roles). На основе серверной модели создаются таблицы в базе данных. Oracle Designer создаёт DDL-скрипты для создания полной структуры, соответствующей данной серверной модели. Создаёт это утилита Design Editor. На основе созданной модели приложения (функциональной модели, ER-модели, серверной модели) создаются модули, из которых путем генерации получаются пользовательские формы. На Рис. 16 представлена диаграмма модуля - формы «Статистический талон» в представлении по составу данных, отображаемых и необходимых для связей и расчетов.
Данная форма является мастер-детальной. Мастер-блок основан на таблице PJS_PATIENTS, а детальный блок на таблице RIS_DIAGNOSYS. Связь между этими таблицами DGN_PAT_FK служит связью между двумя блоками. Чтобы показать пользователю данные в понятных ему терминах используются вторичные ключи между таблицами. Такое использование связей называется Lookup. Так, например, в таблице RISPATIENTS нет фамилии пациента. Ее требуется взять из таблицы RIS_MEN. По коду в таблице PJS_PATIENTS система должна найти ФИО пациента в таблице RIS MEN. MVJBМодуль «Статистический талон» в представлении по составу данных После генерации серверной модели дуги графов проецируются во вторичные ключи, а узлы имеют отражение на реальные таблицы. Как видно из Рис. 16, в результате проведённой оптимизации многоуровневая пользовательская форма «Статистический талон» представлена достаточно прозрачной диаграммой с максимальным числом подзапросов не более 3.
Статистический талон для регистрации заключительных (уточнённых) диагно. Из этой диаграммы получена форма «Статистический талон» (Рис. 18). Данная диаграмма создается в Oracle Designer Editor, после чего посредством генерации создается форма в соответствующих кодах (в данном случае язык PL/SQL), с которой уже работает пользователь. Пользовательская форма «Статистический талон» В пользовательской форме «Статистический талон» реализованы следующие функциональности: Реализован поиск пациентов по различным признакам, показанным на форме. После нахождения высвечивается следующая информация: ФИО, дата рождения, пол, серия и номер полиса, место работы и участок, к какому принадлежит пациент, а также группа первичного учета пациента. Если какая-то информация изменилась, то можно человека найти в форме Новый пациент и изменить о нем информацию там. Разработана форма календаря, которая может быть вызвана для заполнения соответствующих полей. Например, в данной форме, такими полями являются Дата рождения я Дата посещения. Для облегчения ввода информации и увеличения производительности в форме используются выпадающие списки для полей, которые могут приобретать только заданные значения. Это позволяет структурировать информацию и анализировать её" в будущем. Например, в поле Метод выявления по умолчанию установлено значение Обращение за лечением, но при необходимости можно его поменять на другое значение из выпадающего списка - Профосмотр. Поле Установлен также имеет значение по умолчанию — Впервые. Если диагноз установлен повторно, следует выбрать Повторно из списка.
