Особенности в проектировании и практической разработке медицинской информационной системы (стр. 2 из 3)
определить, какое количество физических баз данных и их имен соответственно установ-лено на сервере;
определить возможность доступа к каждой базе данных в отдельности;
выполнить соответствующий запрос к каждой базе данных, указав в правильном формате полный адрес, включающий имя сервера и имя базы данных на нем;
обработать и запомнить полученный ответ;
повторить шаги 2-4 для каждой базы данных;
сложить накопленные ответы и обработать их, как единый пакет информации.
Доказано [5, 10, 16, 17, 19, 20, 22], что для эффективного решения такой задачи необхо-димо исключить в текстах программ МИС прямое обращение к базам данных. Взамен этого предложено использовать специальное промежуточное программное обеспечение, называе-мое сервисами middleware. Схема работы МИС на базе сервисов middleware показана на ри-сунке 2. С целью определения эффективности разработки системы с применением объектно-ориентированной технологии на основании использования сервисов middleware, авторами был выполнен анализ работы по созданию информационной системы в период 1999-2001 гг. Были получены следующие данные (таблица 1).
Таблица 1
Использование однотипного программного кода в различных подсистемах МИС
| Подсистема | Общий код | Уникальный код | ||
| % от всего | % времени на разработку | % от всего | % времени на разработку | |
| Документы ИБ и АК | 45 | 10 | 55 | 90 |
| Лабораторная подсистема | 74 | 38 | 26 | 62 |
| Статистика | 17 | 9 | 83 | 91 |
Как представлено в таблице 1, в некоторых видах ПО доля повторяющегося кода со-ставляет значительную часть. Исключение его из этапа разработки нового приложения по-зволило сократить среднее время создания новой программы с 3,8 до 2,9 недель (на 23,68%). Кроме этого, использование проверенных библиотек позволило значительно, на 35-50%, со-кратить количество последующих исправлений ошибок. Фактически вся основная работа над ошибками была связана с исправлением уникального кода приложения, в редком случае (в среднем 5-7 ошибок на 100 исправлений) исправлением используемых middleware-сервисов.
Таблица 2
Анализ ошибок и исправлений в МИС
| Подсистема | До применения middleware | После применения middleware | ||
| Количество ошибок в неделю | Время ис-правления ч/неделю | Количество ошибок в неделю | Время ис-правления ч/неделю | |
| Микроядро системы | 26 | 4,5 | 2,9 | 3,5 |
| Статистика | 8 | 6,2 | 1,3 | 0,8 |
| Лабораторная подсистема | 1,2 | 3,4 | 0,2 | 1,2 |
| Внешние программы | 13 | 14,2 | 2,5 | 6,5 |
| Календари | 3 | 4,4 | 0,4 | 1,2 |
Дополнительно с широким применением базовых библиотек класса middleware, выпол-ненных в виде динамически подсоединяемых библиотек (dynamic link libraries DLL), было предложено встроить во все основные функции единый обработчик ошибок. В случае фа-тального прекращения работы какой-то функции middleware он пересылал системе резуль-тат, переданный по умолчанию, и дополнительно отправлял максимально возможную ин-формацию разработчику по e-mail. Это позволило сократить время, необходимое на анализ и исправление ошибки в среднем на 45-55%. Нередко исправление ошибки производилось уже до того, как пользователь сообщал об этом программистам [10, 14].
Необходимо отметить, что применение модели программного обеспечения системы на основе использования общих сервисов middleware позволяет применять эволюционный ме-тод, называемый в литературе Spiral Model [12, 18]. При этом возможно внедрение новых версий информационной системы путем простого подмена базовых сервисов на новые вер-сии. Эти версии могут работать как со старой информационной системой, так и с новой, без необходимости повторного обучения персонала или исправлений в структуре существующей базы данных.
Таким образом, применение сервисов middleware позволило в среднем увеличить появ-ление новых версий программ с 4 до 7 в месяц (на 75%), снизив удельную стоимость каждой новой версии на 22%. Применение указанных технологий позволило разработать систему со значительной экономией. Так, разработка крупнейшей отечественной МИС "Интерин" длит-ся 9 лет, штат разработчиков насчитывает 25 человек. Разработка ИС, в которой принимают участие авторы, осуществляется 4 года и только 2 последних из них в ней постоянно участ-вует 2 программиста. Приняв, что данная МИС содержит только 50% от возможностей МИС "Интерин", зарплата одного программиста составляет около $300 (долл. США), а работа ве-дется 11 месяцев в году, получена экономия по сравнению с традиционными технологиями около $75900 в год. Таким образом, за 4 года работы стоимость разработки МИС на основе объектно-реляционного подхода составила 5,3% от суммы, которая потребовалась бы для создания МИС с применением традиционного подхода.
Рис. 2. Схема работы промежуточного программного обеспечения и его место в структуре программ медицинской информационной системы
На этапе, когда ИС становится пакетом многочисленных программ, остро встает вопрос их поддержки. Актуальность ее растет вместе со сроком эксплуатации и ростом количества пользователей. Наряду с начальными капитальными затратами, администрирование инфор-мационной системы составляет значительную цифру в смете расходов ЛПУ [3, 5, 10, 14]. Применение сложных комплексных информационных систем требует высококвалифициро-ванного штата программистов и администраторов [12, 15]. С ростом количества подключен-ных к базе данных системы пользователей растет и сложность ее обслуживания. В таблице 3 приведены средние еженедельные затраты времени работы администратора МИС, получен-ные в результате хронометрических исследований в медицинском центре.
Таблица 3
Трудозатраты администратора МИС
| № | Вид деятельности | % общего времени | Примечание |
| 1 | Обслуживание вызовов пользователей на местах | 38 | |
| 2 | Установка пакетов исправлений | 17 | |
| 3 | Отправка сообщений об ошибках разработчикам системы | 7.8 | |
| 4 | Плановое обслуживание клиентских ПК (дефраг-ментация диска, проверка на вирусы) | 6,9 | |
| 5 | Знакомство с литературой | 5 | |
| 6 | Анализ журналов безопасности | 4 | |
| 7 | Установка новых приложений | 3,5..45,7 | 45,7% при вне-дрении системы |
| 8 | Контроль за новыми версиями ПО и публикация-ми исправлений | 3,2 | |
| 9 | Исправление сбоев в клиентских операционных системах | 0,1-2,1 | Максимум при Windows 95/98 |
| 10 | Внесение исправлений в системные справочники, текущие изменения настроек приложений | 0,3-8,6 | Максимум - при внедрении |
| 11 | Прочие | 14,2 |
Использование встроенных в middleware-приложений глобальных обработчиков оши-бок позволяет сократить время по п. 3 (отправка отчетов об ошибках) практически до нуля, т. к. вся ключевые отчеты система формирует и отправляет автоматически. Обслуживание вызовов пользователей, исправление локальных сбоев на компьютерах пользователей и вне-сение исправлений в справочники системы являются практически неуправляемыми факто-рами. Плановое обслуживание компьютеров, анализ журналов работы системы, чтение спе-циальной литературы являются постоянными величинами, истекающими из функциональ-ных обязанностей администратора системы.
Следовательно, управляемыми факторами, способными сократить (перераспределить) трудозатраты технического персонала на обслуживание системы являются: установка при-ложений системы, установка исправлений (в т. ч. самой ИС и общесистемного ПО), контроль за новыми версиями ПО. Причиной высоких показателей в этих категориях является тради-ционный способ установки прикладного ПО: администратор сети запускает инсталляцион-ные пакеты на компьютерах пользователей, а затем по мере появления и т. н. "заплатки" к ним. Учитывая высокие показатели в выходе новых версий отдельных программ МИС на ба-зе ООП, 1 администратор может обслуживать до 22-25 пользователей. По нашему опыту, время от появления пакета исправлений до его полной инсталляции на всех компьютерах се-ти может составлять от 2-3 суток при работе 50 станций до 4-7 суток при работе 100-150 станций. Этот факт чреват тем, что злоумышленник может воспользоваться этим промежут-ком для нарушения системы безопасности или другого нанесения вреда, если он знает меха-низм ошибки, которую планируется исправить "заплаткой".
Анализируя эти проблемы, было предложено использовать технологию установки и об-новления приложений [8, 11, 14]. Суть ее работы состоит в следующем: в системе имеется выделенная база данных дистрибутивов приложений. Все команды на запуск приложений используют в своей работе специальный сервис, предоставляемый системой. Ей передается команда на запуск приложения, содержащая код программы и параметры ее запуска. Всю необходимую работу выполняет система, используя следующий алгоритм (рис. 3).
Определяется, имеется ли описание программного продукта с переданным кодом в цен-тре программ. Если описание не найдено, выдается сообщение об ошибке.
Вычисляются из описания программы необходимые данные, в частности: номер версии ПО, имя исполняемого файла и т. д.
Проверяется, имеется ли вызываемое ПО на компьютере пользователя: если нет, произ-водится инсталляция программного обеспечения - из базы данных извлекаются необхо-димые файлы и настройки, создается программная папка и выполняется копирование файлов и т. д. После окончания процесса установки исполняемый файл запускается.
Если вызываемое ПО имеется на компьютере пользователя, проверяется его версия и сравнивается с версией в центре программ. В случае, если на локальном компьютере со-держится устаревшая версия, производится обновление программных файлов в зависимо-сти от настроек одним из следующих способов: