База данных бизнес-правил медицинского учреждения

Размещено на http://www.allbest.ru/

База данных бизнес-правил медицинского учреждения

Аннотация

В данном курсовом проекте рассматриваются основные концепции построения реляционных СУБД и постреляционных СУБД, базовые принципы проектирования данных. А также, какие объекты могут быть созданы в базах данных. В данной работе рассматривается БД «Бизнес-правил медицинского учреждения», которая относится к направлению медицинских информационных систем.

Введение

Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.

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

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

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

Опыт применения ЭВМ для построения прикладных систем обработки данных показывает, что самым эффективным инструментом здесь являются не универсальные алгоритмы языка высокого уровня (специализированные языки для создания систем управления данными (Fox Pro, Oracle)).

1. Анализ бизнес-правил медицинской информационной системы

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

Такая база данных является исключительно сложной так как в ней реализовано большое количество бизнес-правил.

Возможности МИС

Пациент может осуществлять в автоматическом режиме:

запись на прием к врачам поликлиник и к специалистам консультативных кабинетов стационаров;

просмотр расписания работы врачей и наличие талонов на прием;

возможность просмотра и отмены ранее произведенных записей на прием через интернет.

Эти возможности доступны пациентам в автоматическом режиме.

Участие операторов регистратур не требуется.

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

2. Инфологическая модель

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

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

R1 (Ф.И.О. пац, год рожд., дом, улица, город, учет, тел, e_mail).

R2 (№ записи на прием, рег. номер, Ф.И.О. вр, дата и время, стоимость, статус).

R3 (Рег.номер, типМЗ, дата и время созд, снимки, рез. анализа, диагноз, статус, лечение).

R4 (Рег.номер, типМЗ, дата и время созд, жалобы, болезнь, лечение, последний визит, дата и время создания, статус).

R5 (Ф.И.О. вр, год рожд, улица, дом, город, тел/e_mail, ученная степень, оборудование, направление диагностики, специализация, кабинет).

R6 (Ф.И.О. пац, Ф.И.О. вр, дата и время, стоимость, статус).

R7 (Аптека, наименование, лекарственная форма, производитель, цена).

R8 (№ заказа, Ф.И.О. пац, Ф.И.О. вр, аптека, лекарства, стоимость, оплата).

3. Задачи медицинской информационной системы

Применение МИС в медицинском учреждении позволяет решить практически весь спектр прикладных задач этого учреждения.

Задачи административно-хозяйственного и общего характера:

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

Составление отчетов об использовании врачом рабочего времени

Планирование и учет использования помещений и оборудования

Проведение анализа работы подразделения

Статистическая обработка данных. Ведение и анализ медицинских и хозяйственных статистических данных

Учет материальных ценностей

Учет услуг, выписка счетов к оплате и регистрация платежей

Задачи поддержки лечебно-диагностических мероприятий:

Регистрация пациентов

Ведение баз данных по всем аспектам пребывания пациентов в лечебном учреждении

Автоматизированное ведение медицинских карт (историй болезни, амбулаторных карт)

Хранение и предоставление результатов функциональных, лабораторных и лучевых исследований

Формирование и выдача медицинских заключений

Назначение больным времени консультаций и исследований

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

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

Задачи поддержки лабораторных и диагностических исследований:

Ввод и хранение данных лабораторных и диагностических исследований.

Анализ данных лабораторных и диагностических исследований

Обеспечение удобного доступа к данным лабораторных и диагностических исследований и результатам их обработки

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

Контроль за своевременностью диагностических исследований

Формирование перечня проводимых лечебно-профилактических мероприятий за любой временной период с указанием даты, времени начала и окончания, длительности, стоимости, места проведения, исполнителя

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

Автоматизированное формирование отчетов по различным аспектам проведения процедур, обследований и консультаций

Задачи финансово-экономического характера:

Автоматизированный расчет стоимости оказанных медицинских услуг

Выписка счетов, счетов-фактур и детализированных приложений к оплате

Регистрация платежей

Контроль балансов по пациенту, подразделению, внешней организации

Учет в балансах актов списания средств с выставленных счетов

Задачи оптимизации бизнес-процессов:

Работа в унифицированном интерфейсе с любыми электронными документами

Поддержка механизмов коллегиальной работы и принятия решений

Возможность рассылки электронных документов пользователям и организации документов на своем рабочем столе

Реализация произвольных оперативных схем прохождения документов

Возможность специфицировать права доступа в терминах операций над электронными документами

Возможность динамического составления прав конкретного пользователя на основе прав метапользователей, к которым данный пользователь относится

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

Возможность иметь несколько стратегий механизма контроля прав доступа

4. Классы функциональностей МИС

Офисные функции - информационная поддержка функционирования лечебного учреждения и автоматизация документооборота.

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

Мониторинг лечебно-диагностического процесса - ведение клинических записей о пациенте, их просмотр, обработка и анализ.

Лабораторно-диагностические функции - ввод и сохранение результатов диагностических исследований, обработка и анализ этих данных.

Поддержка принятия решений - экспертная оценка и контроль качества процесса лечения.

Характеристика МИС.

Архитектура

Трехуровневая архитектура: клиент - сервер приложений - сервер БД

Технологии управления данными

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

Централизованный механизм представления метаданных и описание информационной модели предметной области

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

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

Обеспечение безопасности (защита от несанкционированного доступа и авторизация)

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

Реализация всех элементов системы в виде Информационных объектов, для которых определяются режимы владения, делегирования и пересылки.

Ведение журнала транзакций для фиксирования всех действий пользователей

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

Обеспечение лечебно-диагностического процесса

Административно-хозяйственные

Экспертные (лечебно-диагностические карты, формирование плана лечения на основе стандартов оказания медицинской помощи)

Формулировка основных принципов функционирования медицинской информационной системы

Информационная система медицинского учреждения должна решать основные вопросы деятельности ЛПУ:

Ведение списков прикрепленного контингента

Ведение медицинских карт пациентов

Оформление лечебных и диагностических процедур и манипуляций

Статистический анализ деятельности медицинского учреждения по самым различным аспектам

Автоматизированное оставление отчетности ЛПУ.

Подсчет стоимости лечения

Кроме этого в зависимости от вида учреждения и комплектации ИС могут быть поддержаны специализированные и сопутствующие лечебно-диагностическому процессу области:

Лабораторные системы с подключением приборов

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

Аптечная система ЛПУ

Стоматологическое обслуживание

Система лечебного питания в стационаре и санатории

Бронирование путевок и расселение отдыхающих в санатории

Взаимоотношения со страховыми компаниями

Административная деятельность

Отдел кадров

Медицинская библиотека

Интеграция информационных потоков

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

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

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

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

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

Концентрация вокруг пациента

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

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



Автогенерация статистических отчетов

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

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

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

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

Медицинская информационная система может предоставлять статистические отчеты в нескольких видах:

Печатные документы - статистические сводки или отдельные медицинские документы - сформированные в виде, утвержденном вышестоящими инстанциями

Печатные документы, не требующие строгого форматирования

Представление информации на экране компьютера (в виде гипертекста)

Динамические отчеты по заданным пользователям характеристикам (подборки на рабочем столе)

Интерактивные сводки для анализа (сформированные и подсчитанные специализированными средствами анализа информации)

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

Финансовый учет и анализ произведенных медицинских услуг и манипуляций

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

В процессе медицинского обслуживания пациента и заполнения его медицинской карты информация обо всех медицинских манипуляциях или услугах, оказанных пациенту, заносится в БД.

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

Доступ к данным

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

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

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

Объектно-реляционный дуализм

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

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

постреляционный проектирование медицинский инормационный

алгоритмы + структуры данных = программы.

Тогда формула реляционного программирования:

реляционная модель данных +{SQL манипуляция}* + {процедура сервера}* + {клиентское приложение}* = система.

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

Основная идея объектного подхода прямо противоположна: структуры данных и алгоритмы объединяются в семантически значащие сущности - объекты. Структуры данных скрываются (инкапсулируются) за интерфейсом объекта. На первый план выходят алгоритмы. Таким образом, реляционный и объектный подходы в корне своем противоречивы, поэтому прямой синтез этих подходов неэффективен. Однако в философской и естественнонаучной практике получил использование метод дуализма, который позволяет осуществлять взаимодополняющий синтез противоречивых подходов. Алгоритм использования этого метода состоит в следующем: 1) в объекте находится наиболее принципиальное противоречие; 2) на основе этого противоречия формулируется противоречивое высказывание; 3) объект рассматривается с противоположных сторон, будто этих объектов два.

В качестве наиболее принципиального противоречия среди требований, предъявляемых к большой ИС, выберем противоречие между высокими техническими характеристиками и высокой степенью гибкости. Требуемые технические характеристики:

- возможность работы с большими объемами информации,

- высокая скорость реакции системы в интерактивном режиме,

- высокая скорость обработки в пакетном режиме,

- высокие надежностные характеристики.

Требуемая степень гибкости:

высокие адаптационные возможности к особенностям конкретной инсталляции,

возможность широкого маневра на этапе внедрения системы,

высокий уровень настраиваемости системы во время эксплуатации,

высокий потенциал развития системы.

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

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

Противоречивое высказывание. Большая ИС должна быть одновременно и реляционной, и объектно-ориентированной.

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

Методологические принципы и архитектура

Для реализации подхода объектно-реляционного дуализма на практике необходимо следовать методологическим принципам.

1. Отказ от прямого синтеза объектного и реляционного подходов.

2. Оба подхода должны быть применимы на всех уровнях проектирования и быть доступны на всех этапах построения ИС.

3. Равноправие двух подходов не должно нарушаться на всех уровнях проектирования и для всех этапов построения ИС.

4. Должна быть обеспечена независимость этих двух подходов. Любые взаимозависимости препятствуют техническим средствам каждого подхода развиваться в своем направлении и темпе.

5. Технические средства каждого подхода по отношению к техническим средствам другого должны быть прозрачны.

Отличие от других подходов

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

Использование объектно-реляционных средств реляционной СУБД.

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

Нарушение равноправия двух подходов и объявление одного из них главным. Например, когда за основу берется объектный подход, а реляционная СУБД рассматривается как хранилище объектов.

Этих недостатков лишен предлагаемый в данной работе подход.

Архитектура системы

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

- Объектные средства позволяют конструировать понятия и связи между ними произвольного уровня абстракции.

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

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

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

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

Объектные средства: организация бизнес-логики системы; создание универсальных механизмов; миграция информации (экспорт, импорт); формирование объектного интерфейса системы.

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

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

- универсальная составляющая реализуется один раз, а потом многократно используется и в рамках одной системы, и от системы к системе;

- отделение универсальной составляющей функциональности позволяет более качественно реализовать специальную часть,

- универсальная составляющая представляет собой постоянно пополняющийся набор универсальных механизмов, который используется как палитра для реализации подсистем ИС,

- механизмы универсальной составляющей развиваются независимо от конкретных ИС.

В качестве использования метода объектно-реляционного дуализма приведем пример реализации административной подсистемы медицинской корпоративной ИС.

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

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

Функциональность подсистемы была изначально структурирована на две части - универсальную и специальную. Универсальная часть функциональности реализована при помощи общесистемных универсальных механизмов.

1. Механизм «Универсальный навигатор» - клиентское приложение, использующееся для реализации универсального рабочего места пользователя.

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

3. Механизм отбора объектов используется в качестве поставщика объектов для механизмов «Динамических отчетов» и «Генерации сценариев».

4. Механизм динамических отчетов используется для формирования различных представлений выборок объектов «Сотрудник» и «Приказ».

5. Механизм сценариев используется для реализации механизма приказов, который является основным способом работы с административной информацией.

6. Механизм генерации сценариев используется для генерации приказов с большим количеством однородных пунктов. На входе механизма - выборка объектов «Сотрудник», на выходе - приказ по личному составу заданного типа.

Функциональность специальной части структурируется на три составляющие.

1. Реляционная модель данных представляет собой реляционную модель предметной области без сущностей и связей, которые реализуют сервисную функциональность.

2. Базовая реляционная функциональность - это стандартный набор средств реализации функциональности: пакеты, формы, отчеты.

- Функциональность пакетов двоякая: одна часть сосредоточивается вокруг таблиц и предоставляет процедурный интерфейс, а вторая реализует бизнес-логику форм.

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

- За счет наличия универсального механизма динамических отчетов на долю реляционных отчетов достались лишь сложные аккумулирующие отчеты.

3. Базовая объектная функциональность представляет собой описание всех необходимых объектов средствами механизма «Информационных объектов».

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

Особенности в проектировании

В итоге остановились на применении принципа объектно-реляционной парадигмы в проектировании БД МИС. Кратко концепция этого подхода выражается в том, что в силу особенностей предметной области необходимо разрабатывать информационную систему на базе синтеза двух, различных по своей природе, систем управления базами данных (СУБД) - объектно-ориентированной и реляционной. Только на основе этого синтеза удается исключить недостатки обоих СУБД и использовать их достоинства. В ходе изучения эффективных способов создания приложений для системы найдено несколько интересных находок.

Во-первых, одной из самых существенных причин увеличения стоимости МИС - высокая стоимость самой разработки. Изучив причины этого явления, пришли к выводу, что не последнюю роль в этом сыграла традиция создания медицинских информационных систем на основе так называемых АРМ-ов (автоматизированных рабочих мест). Причем зачастую под АРМ-ом понимается именно клиентское программное обеспечение, хотя изначально этот термин имел более широкое толкование. Чаще всего разработка АРМ-ов ведется по следующей методике: разработчики выбирают некоторую общую задачу (например, создание электронной истории болезни для стационара), проектируют структуру базы данных, разрабатывают приложение для работы с ней. Нередко это приложение выполняется в виде нескольких версий - АРМ главного врача, АРМ регистратора, АРМ лаборанта и т.д. Разработка систем в 65% случаев ведется на Borland Delphi. При этом даже на выпуск очень сырой версии АРМа тратится 4-8 месяцев. Затем столько же времени уходит на обкатку. Вместе с тем, по нашим оценкам, разработчику приходится 10-20% времени тратить на создание специфичного для медицинской области кода. Остальная часть, причем самая трудоемкая и ответственная, приходится на разработку механизмов, обеспечивающих целостность данных, подсистему безопасности и администрирования МИС, связь с периферийным медицинским оборудованием и т.д.

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

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

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

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

1. определить, какое количество физических баз данных и их имен соответственно установлено на сервере;

2. определить возможность доступа к каждой базе данных в отдельности;

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

4. обработать и запомнить полученный ответ;

5. повторить шаги 2-4 для каждой базы данных;

6. сложить накопленные ответы и обработать их, как единый пакет информации.

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

Список литературы

1. Айламазян А.К., Гулиев Я.И. Данные, документы и архитектура медицинских информационных систем.

2. Хаткевич М.И., Матвеев Г.Н. Принцип объектно-реляционного дуализма для построения медицинских информационных систем.

3. Айламазян А.К., Гулиев Я.И., Комаров С.И., Малых В.Л., Морозов В.Ю. Информационные системы в медицине: проблемы и решения // Программные системы. - М.: Наука, Физматлит, 1999. - С. 162.

4. Андреев А.М., Березкин Д.В., Кантонистов Ю.А. Выбор СУБД для построения информационных систем корпоративного уровня на основе объектной парадигмы // СУБД 1998. - №4-5. - С. 26-50.

5. Гусев А.В., Романов Ф.А., Дуданов И.П. Опыт разработки медицинской информационной системы // Медицинский академический журнал, 2001. - №1. - Приложение 1. - С. 18.

6. Гусев А.В., Дуданов И.П. Оценка 3-летнего опыта разработки и внедрения информационной системы: выводы и перспективы // Медицинский академический журнал, 2002. - Том 2. - Приложение 2. - С. 56-57.

Размещено на Allbest.ru