98978 (Особенности в проектировании и практической разработке медицинской информационной системы)

Особенности в проектировании и практической разработке медицинской информационной системы

Гусев А.В., член-корр. РАМН Дуданов И.П., Романов Ф.А., Дмитриев А.Г., Карельский научно-медицинский центр СЗО РАМН, Петрозаводск

В последние годы в России появился целый ряд уникальных разработок в области комплексных медицинских информационных систем (МИС), предназначенных для автоматизации работы учреждений здравоохранения. Одними из самых интересных являются: ин-формационная система "Интерин" (Институт программных систем РАН), МИС "Артемида", МИС "Амулет" и некоторые другие. Эти системы не только разработаны, но и активно раз-виваются - распространения и признания в практическом внедрении они получили за по-следние 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

Использование однотипного программного кода в различных подсистемах МИС

Как представлено в таблице 1, в некоторых видах ПО доля повторяющегося кода со-ставляет значительную часть. Исключение его из этапа разработки нового приложения по-зволило сократить среднее время создания новой программы с 3,8 до 2,9 недель (на 23,68%). Кроме этого, использование проверенных библиотек позволило значительно, на 35-50%, со-кратить количество последующих исправлений ошибок. Фактически вся основная работа над ошибками была связана с исправлением уникального кода приложения, в редком случае (в среднем 5-7 ошибок на 100 исправлений) исправлением используемых middleware-сервисов.

Таблица 2

Анализ ошибок и исправлений в МИС

Дополнительно с широким применением базовых библиотек класса middleware, выпол-ненных в виде динамически подсоединяемых библиотек (dynamic link libraries DLL), было предложено встроить во все основные функции единый обработчик ошибок. В случае фа-тального прекращения работы какой-то функции middleware он пересылал системе резуль-тат, переданный по умолчанию, и дополнительно отправлял максимально возможную ин-формацию разработчику по e-mail. Это позволило сократить время, необходимое на анализ и исправление ошибки в среднем на 45-55%. Нередко исправление ошибки производилось уже до того, как пользователь сообщал об этом программистам [10, 14].

Необходимо отметить, что применение модели программного обеспечения системы на основе использования общих сервисов middleware позволяет применять эволюционный ме-тод, называемый в литературе Spiral Model [12, 18]. При этом возможно внедрение новых версий информационной системы путем простого подмена базовых сервисов на новые вер-сии. Эти версии могут работать как со старой информационной системой, так и с новой, без необходимости повторного обучения персонала или исправлений в структуре существующей базы данных.