Особенности в проектировании и практической разработке медицинской информационной системы
ГусевА.В., член-корр. РАМН Дуданов И.П., Романов Ф.А., Дмитриев А.Г.
Карельский научно-медицинский центр СЗО РАМН, Петрозаводск
В последние годы в России появился целый ряд уникальных разработок в области комплексных медицинских информационных систем (МИС), предназначенных для автома-тизации работы учреждений здравоохранения. Одними из самых интересных являются: ин-формационная система "Интерин" (Институт программных систем РАН), МИС "Артемида", МИС "Амулет" и некоторые другие. Эти системы не только разработаны, но и активно раз-виваются - распространения и признания в практическом внедрении они получили за по-следние 2-3 года. В литературе опубликованы положительные отзывы коллективов клиник самого разного профиля и масштабов об опыте применения информационных систем в рабо-те [1, 3, 5, 10, 13, 14, 17-20]. Наметилась тенденция на комплексное решение разносторонних задач лечебного учреждения, что особенно радует и свидетельствует о качественном росте отечественных разработчиков в области медицинской информатики.
Однако при более глубоком изучении этого процесса все сильнее выделяется сущест-венная проблема: несмотря на наличие глубоко проработанных программных решений, практически отсутствует опыт полного перехода на электронный принцип хранения и обра-ботки информации в лечебном учреждении [8, 11]. Имеется ряд серьезных преград, через ко-торые не могут перешагнуть даже современно оснащенные клиники в своем стремлении от-казаться от бумажных носителей информации и повысить эффективность в организации сво-ей работы. Все они могут быть объединены в несколько групп.
Во-первых, существующая в России правовая база не обеспечивает должного уровня юридической защиты медицинских работников, применяющих информационные технологии в повседневной практике. Во-вторых, финансовые ресурсы большинства учреждений здра-воохранения пока не могут позволить им приобрести достаточное количество компьютерной техники и дорогостоящего программного обеспечения для комплексной автоматизации.
По- этому этот процесс успешно протекает лишь в некоторых, зачастую далеких от медицинской направленности, разделах работы ЛПУ: статистика, бухгалтерия, автоматизация работы ад-министративного звена и т. д. В третьих, в России практически отсутствует школа, которая бы готовила профессионалов высокого уровня в области разработки и внедрения именно комплексных медицинских информационных систем, людей по определению работающих на стыке сложнейших наук - медицины и прикладной математики. Для становления отечест-венной школы в этой области творческим коллективам необходимо обмениваться наблюде-ниями и мнениями в разработке программных продуктов, накапливая тем самым специаль-ные знания и формируя потенциально выгодные направления в поиске эффективных реше-ний разработки и внедрения комплексных МИС.
Коллектив авторов имеет 5-летний опыт в разработке медицинской информационной системы. За это время изучена на практике эффективность различных подходов. Применя-лись Microsoft FoxPro разных версий, CA Clipper, Lotus Notes, начиная с версии 4.6, СУБД Microsoft SQL Server, Microsoft Access, Borland Paradox, MySQL и IBM DB2. Апробирован вариант написания программного обеспечения на Borland Delphi, сервлеты на Java, применя-лись Lotus Designer и мультиплатформенный Lotus Script и некоторые другие технологии. Серверная часть системы работала под управлением Microsoft Windows NT Server, Microsoft Windows 2000 Server и Red Hat Linux 6.0. В качестве клиентской операционной системы применялись все версии Windows, начиная с Microsoft Windows 95. Кроме инструментария, была проведена работа по изучению эффективности различных методик проектирования ба-зы данных МИС. В итоге мы остановились на применении принципа объектно-реляционной парадигмы в проектировании БД МИС [4]. Кратко концепция этого подхода выражается в том, что в силу особенностей предметной области необходимо разрабатывать информацион-ную систему на базе синтеза двух, различных по своей природе, систем управления базами данных (СУБД) - объектно-ориентированной и реляционной.
Только на основе этого синтеза удается исключить недостатки обоих СУБД и использовать их достоинства. В качестве ос-новной СУБД используется Lotus Domino Server R6.0.3 для функционирования объектной части МИС и MySQL 4.0.17 для реляционной составляющей системы. Разработка программ-ного обеспечения ведется в среде Lotus Designer R6.0.2 и Borland Delphi 6 Professional SP3. В ходе изучения эффективных способов создания приложений для системы найдено несколько, на наш взгляд, интересных находок.
Во-первых, одной из самых существенных причин увеличения стоимости МИС мы считаем высокую стоимость самой разработки. Изучив причины этого явления, мы пришли к выводу, что не последнюю роль в этом сыграла традиция создания медицинских информа-ционных систем на основе так называемых АРМ-ов (автоматизированных рабочих мест). Причем зачастую под АРМ-ом понимается именно клиентское программное обеспечение, хотя изначально этот термин имел более широкое толкование [10]. Чаще всего разработка АРМ-ов ведется по следующей методике: разработчики выбирают некоторую общую задачу (например, создание электронной истории болезни для стационара), проектируют структуру базы данных, разрабатывают приложение для работы с ней. Нередко это приложение выпол-няется в виде нескольких версий - АРМ главного врача, АРМ регистратора, АРМ лаборанта и т. д. Разработка систем в 65% случаев ведется на Borland Delphi. При этом даже на выпуск очень сырой версии АРМа тратится 4-8 месяцев. Затем столько же времени уходит на обкат-ку. Вместе с тем, по нашим оценкам, разработчику приходится 10-20% времени тратить на создание специфичного для медицинской области кода. Остальная часть, причем самая тру-доемкая и ответственная, приходится на разработку механизмов, обеспечивающих целост-ность данных, подсистему безопасности и администрирования МИС, связь с периферийным медицинским оборудованием и т. д.
Однако, не вызывает сомнений, что эти решения значительно уступают промышлен-ным решениям для корпоративного рынка, над которыми трудятся лучшие специалисты и которые прошли многолетнюю проверку.
В связи с этим вызывают недоумение подобные попытки "изобрести велосипед". На наш взгляд, разработка МИС не должна осуществляться созданием и дальнейшей интеграцией отдельных АРМов. Для создания МИС необходимо применять готовые программные платформы для групповой работы, уже имеющие в своем арсенале мощные средства для мультиплатформенной разработки программы, готовые тех-нологии для развертывания и управления подсистемой безопасности. В своей работе мы вы-брали пакет групповой работы Lotus Notes/Domino, разрабатываемый в настоящее время корпорацией IBM. Эта платформа является за рубежом стандартом "де факто" для создания мощных информационных систем, ориентированных на обработку электронных документов и мы считаем, что она наиболее подходит для создания медицинских информационных сис-тем.
Работа над созданием МИС "Кондопога" на основе Lotus Notes/Domino версии 4.6 на-чата в сентябре 1999 года. Через 2 месяца МИС, включающая подсистемы работы врача, клинической и биохимической лаборатории, функциональной и рентгенологической диагно-стики, аптеки и планирования рабочего времени была поставлена в эксплуатацию. А еще че-рез 2 месяца лечебное учреждение, использующее систему, полностью перешло на элек-тронный способ хранения информации, отказавшись от бумажных носителей.
Вторым важным решением явился отказ от проектирования базы данных МИС по функциональному назначению, когда для отдельной задачи (например, подсистема лабора-тории, функциональной диагностики, консультационная и т. д.) создавалась своя база дан-ных. Хотя такой подход имеет ряд преимуществ, главным из которого является снижение требований к аппаратной мощности сервера за счет разделения потоков пользовательских запросов к отдельным БД. Однако было избрано проектирование БД МИС таким способом, что вся информация собиралась вокруг пациента и хранилась физически в одной БД.
Однако количество таких БД в МИС является вариабельным и зависит от количества функциональных групп пользователей, имеющихся в ЛПУ.
Так, в стационаре это может быть выделенная БД для каждого отделения или корпуса. Для поликлиники - это могут быть БД, разделенные по участкам обслуживания. Кроме того, в этих БД специальным образом хра-нится только актуальная информация, а неиспользуемые данные помещаются в БД архива. Для решения ряда задач может быть принята либо связанная с объектно-ориентированным ядром реляционная БД, либо специальным образом сконструированные представления, ко-торые мы называем регистрами (рис. 1).
Рис. 1. Укрупненная схема объектно-реляционной базы данных медицинской информационной системы
Проектирование структуры БД, таким образом, позволяет достичь стабильно малого объема БД МИС в течение практически всего срока ее эксплуатации, а тем самым обеспе-чить максимально возможную производительность работы МИС. Так, начиная с 1999 года база данных историй болезни пациентов, проходящих реабилитацию в медицинском центре, имеет объем 26-29 Мбайт. При этом вся информация за время работы центра сохранена, а скорость работы остается стабильно высокой. Сложностью указанной методики является то, что программное обеспечение информационной системы должно поддерживать любое коли-чество физических баз данных в ядре системы, объединенных в одну логическую структуру.
Таким образом, необходимо разработать алгоритмы всех программ МИС так, чтобы они могли корректно работать с базой данных текущих документов, состоящей из одной или не-скольких частей. Это вызвано тем, что в некоторых случаях программам необходимо обра-ботать данные не только по отдельной части базы данных, но и по всей имеющейся в ней информации. В связи с этим необходимо перед каждым обращением к серверу выполнять ряд последовательных шагов:
определить, какое количество физических баз данных и их имен соответственно установ-лено на сервере;
определить возможность доступа к каждой базе данных в отдельности;
выполнить соответствующий запрос к каждой базе данных, указав в правильном формате полный адрес, включающий имя сервера и имя базы данных на нем;
обработать и запомнить полученный ответ;
повторить шаги 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 |
Таблица 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 |
Плановое обслуживание компьютеров, анализ журналов работы системы, чтение спе-циальной литературы являются постоянными величинами, истекающими из функциональ-ных обязанностей администратора системы.
Следовательно, управляемыми факторами, способными сократить (перераспределить) трудозатраты технического персонала на обслуживание системы являются: установка при-ложений системы, установка исправлений (в т. ч. самой ИС и общесистемного ПО), контроль за новыми версиями ПО. Причиной высоких показателей в этих категориях является тради-ционный способ установки прикладного ПО: администратор сети запускает инсталляцион-ные пакеты на компьютерах пользователей, а затем по мере появления и т. н. "заплатки" к ним. Учитывая высокие показатели в выходе новых версий отдельных программ МИС на ба-зе ООП, 1 администратор может обслуживать до 22-25 пользователей. По нашему опыту, время от появления пакета исправлений до его полной инсталляции на всех компьютерах се-ти может составлять от 2-3 суток при работе 50 станций до 4-7 суток при работе 100-150 станций. Этот факт чреват тем, что злоумышленник может воспользоваться этим промежут-ком для нарушения системы безопасности или другого нанесения вреда, если он знает меха-низм ошибки, которую планируется исправить "заплаткой".
Анализируя эти проблемы, было предложено использовать технологию установки и об-новления приложений [8, 11, 14]. Суть ее работы состоит в следующем: в системе имеется выделенная база данных дистрибутивов приложений. Все команды на запуск приложений используют в своей работе специальный сервис, предоставляемый системой. Ей передается команда на запуск приложения, содержащая код программы и параметры ее запуска. Всю необходимую работу выполняет система, используя следующий алгоритм (рис. 3).
д.
метод переустановки. Он является наиболее простым решением. При его использова-нии, однако, механизм синхронизации должен оценить следующие факторы: доступность обновленного дистрибутива, его объем и время копирования на данную рабочую станцию, права доступа данного пользователя к нужному дистрибутиву, возможные ограничения, накладываемые администратором сети на данный дистрибутив;
метод обновления. Он более трудоемкий. Его суть в том, что на данном компьютере приложение не переустанавливается целиком, а лишь перезаписывается его исправленная часть. Этот метод имеет преимущество в том, что объем данных для исправления значи-тельно меньше по сравнению с полным дистрибутивом.
метод исправления справочников. Применяется, если приложение само не изменило свою версию, однако его справочник устарел по сравнению с эталоном системы.
Если все проверки пройдены, исполняемый файл запускается.
Рис. 3. Алгоритм работы подсистемы установки и обновления программ
Применение данной технологии позволило сократить время, необходимое на обновле-ние клиентского программного обеспечения с 2-3 дней до 5-10 сек. (в среднем), снизить за-траты ЛПУ на администрирование информационной системы на 47,8% за счет снижения трудозатрат администратора системы и возможности совмещения ставок программиста и администратора. Ежегодная экономия составляет около $72 на одного пользователя.
