А.Л. Царегородцев, Югорский научно-исследовательский институт информационных технологий, г. Ханты-Мансийск
Проблема повышения качества медицинской помощи является приоритетной задачей нашего общества и занимает одно из центральных мест в политике Российского государства. Особое значение имеет возможность интеграции информационных систем и систем телекоммуникаций как средства повышения эффективности медицины за счет более интенсивного развития телемедицинских технологий, обеспечивающих медику удаленный доступ к современным медицинским ресурсам, в том числе, международным.
Основными причинами, препятствующими очным медицинским консультациям в окружных и федеральных центрах являются: тяжелое состояние здоровья пациента, высокая стоимость проезда и проживания, невозможность длительного отсутствия на работе, отсутствие транспортного сообщения и т.д. По тем же причинам ограничены возможности в получении различных видов высокоспециализированной консультативной медицинской помощи у жителей наиболее отдаленных районов, даже если такие консультации могут быть оказаны в региональных медицинских центрах.
Одним из главных достоинств телемедицины является возможность приблизить высококвалифицированную и специализированную помощь работников ведущих медицинских центров к отдаленным районам и, тем самым, существенно сэкономить затраты пациентов. Все выше сказанное обуславливает актуальность проведения исследований и разработок региональных телемедицинских информационных систем.
Региональная Телемедицинская Информационная Система Ханты-Мансийского автономного округа (РТИС ХМАО) – это территориально распределенный программно-технический комплекс, позволяющий проводить телеконсультации медицинских видеоизображений и сопроводительной информации о пациенте в режиме отсроченных телеконсультаций посредством электронной почты.
Комплекс состоит из серверной и клиентской части. Серверная часть обеспечивает работу по организации взаимодействия между консультантами и консультируемыми. Она включает в себя СУБД «Oracle», www-сервер, почтовый модуль «Обработчик почты», сервер обновлений, АРМ «Администратор», а также web-приложения: АРМ «Координатор», АРМ «Консультант On-line» и АРМ «Статистика». Клиентская часть включает в себя АРМ «Консультант/консультируемый», подсистему «Перинатальный аудит» и аппаратную часть, комплектуемую в зависимости от потребностей консультируемого врача. Она может содержать микроскоп, видеокамеру, компьютер с платой видеозахвата, сканер, фотоаппарат и т.д.
Традиционный подход к разработке базы данных РТИС опирается на реляционную модель представления данных. Однако, как известно, реляционная модель предполагает точное знание структуры хранимых данных. При использовании реляционной модели все строки в какой-либо таблице базы всегда имеют одинаковый набор полей, кроме того, заголовки столбцов, первичные ключи в таблицах и т.д. должны быть определены заранее. При появлении данных с новой структурой, не встречавшейся в реляционной базе до этого момента, в схему базы необходимо вносить изменения или даже полностью перестраивать всю ее структуру.
Другая характерная особенность РТИС состоит в том, что она является распределенной системой, в связи с чем, возникает задача интеграции распределенных данных. Проблема заключается в том, что даже при объединении источников, данные которых хорошо структурированы, не всегда удается создать жесткую структуру для полученных суммарных данных.
Таким образом, для организации хранения и обработки медицинских данных требуется решить две проблемы:
§ проблему управление медицинскими данными, имеющими нечеткую, «размытую» структуру;
§ проблему интеграции медицинских данных из различных источников.
Рассмотрим основные особенности медицинских данных.
1.Неправильная структура. В различных источниках данных одни и те же сущности реального мира могут моделироваться с помощью разных структур и типов данных. Так, например, запись в медицинской карте для одного пациента может содержать перечень прививок, для другого - показатели роста и веса, для третьего - операции, который ему сделали. Другой пример, технические характеристики медицинских приборов описываются параметрами, качественно отличающимися у разных моделей. При объединении разнородных источников можно попытаться сконструировать новую структуру, включающую в себя все разнородные данные. Однако при большом количестве источников создание такой единой структуры может натолкнуться на непреодолимые технические трудности, либо эта структура окажется настолько сложной, что ее использование станет неэффективным. Если отказаться от попыток создания структуры, общей для всех данных, то интегрированные данные будут иметь неправильную структуру.
2.Неявная структура. Значительное количество медицинских данных, хотя и имеет некоторую структуру, но эта структура неявная. Например, медицинские данные подсистемы «Перинатальный аудит» РТИС ХМАО включают в себя очень большое число различных показателей, классификация которых не разработана. Кроме того, медицинские данные иногда имеют неизвестную структуру, примером чего могут служить мультимедийные данные или документы со структурированным текстом.
3.Частичная структурированность. В ряде случаев большая часть медицинских данных, работу с которыми необходимо автоматизировать, имеют четкую структуру. Для хранения этой части данных используют традиционные системы управления базами данных и разрабатывают методы связи структурированных данных с оставшимися данными, которые не удалось структурировать и которые приходится хранить не в базе данных, а в других системах, например, в файловой системе.
4.Частое изменение структуры. Структура медицинских данных часто меняется. Примером могут служить медицинские отчеты, в которых каждый год одни показатели добавляются, а другие исчезают.
5.Апостериорная структура медицинских данных. Как известно, традиционные СУБД используют жестко фиксированную структуру данных. В таких СУБД сначала описывается структура базы данных и только затем база наполняется данными. На наш взгляд, при работе с медицинскими данными целесообразно применять обратный подход: сначала заполняется база данных, и в процессе заполнения определяется ее структура. Системы, работающие по последнему принципу, называют системами с апостериорной схемой. Использование такого подхода, дает большую гибкость при формировании базы и предоставляет возможность свободно изменять ее структуру.
Проведенный анализ характерных особенностей структуры медицинских данных и предварительное планирование базы данных РТИС ХМАО с использованием функциональных диаграмм и диаграмм потоков данных позволяет сделать вывод о том, что медицинские данные следует рассматривать как полуструктурированные данные, которые способны динамически изменять свою структуру, свой состав и тип.
Известно, что полуструктурированные данные сложно хранить в реляционной базе данных, поскольку в этом случае возникает либо много различных таблиц, либо проектируется единственная таблица с множеством пустых колонок. И то, и другое негативно сказывается на продолжительности времени поиска данных и поддержке их целостности в базе. «Полуструктурированные данные очень легко хранить как XML, и они великолепно подходят для XML-баз данных» [1].
В связи с этим база данных РТИС ХМАО разрабатывалась нами не как реляционная, а как XML-база данных. Данный подход основан на технологии XML (eXtensible Markup Language – расширяемый язык разметки), которая, по сути, является синтаксисом, позволяющим создавать языки разметки (схемы), описывающие данные.
«Использование XML-контейнеров для хранения различных медицинских параметров приводит к резкому сокращению числа таблиц, отпадает необходимость в глубокой иерархии данных, что, в свою очередь, приводит к увеличению скорости доступа к базе данных. В целом, при выполнении запросов над иерархическими данными, в которых соединения требуются только для воссоздания иерархии, XML-СУБД являются эффективнее реляционных» [1].
В заключение хотелось бы привести пример, - диагноз пациента, находившийся в реляционной базе в нескольких десятках таблиц, при использовании XML-контейнеров принял следующий вид:
<?xml version="1.0" encoding="UTF-8"?>
<{8D4FA29A-F9D9-4C6B-99E4-D8728C8AE715} Version="1.0">
<DATA>
<DIAGNOS-ITEMS>
<DIAGNOS ID="53"/><DIAGNOS ID="56"/>
</DIAGNOS-ITEMS>
<TEK_BEREM_ITEMS>
<TEK_BEREM NN="0" SROK="10" DATA_CONS="29.08.2006" USER_CONS="1" MESTO_CONS="1" MESTO_LECH="1">
<TEK_BEREM_DIAGNOS_ITEMS>
<TEK_BEREM_DIAGNOS ID="16"/>
</TEK_BEREM_DIAGNOS_ITEMS>
<TEK_BEREM_SCHEMA_LECH_ITEMS>
<TEK_BEREM_SCHEMA_LECH ID="3"/>
</TEK_BEREM_SCHEMA_LECH_ITEMS>
</TEK_BEREM>
<TEK_BEREM NN="1" SROK="15" DATA_CONS="29.09.2006" USER_CONS="3" MESTO_CONS="5" MESTO_LECH="3">
<TEK_BEREM_DIAGNOS_ITEMS>
<TEK_BEREM_DIAGNOS ID="13"/>
</TEK_BEREM_DIAGNOS_ITEMS>
<TEK_BEREM_SCHEMA_LECH_ITEMS>
<TEK_BEREM_SCHEMA_LECH ID="4"/>
<TEK_BEREM_SCHEMA_LECH ID="6"/>
</TEK_BEREM_SCHEMA_LECH_ITEMS>
</TEK_BEREM>
</TEK_BEREM_ITEMS>
</DATA>
</{8D4FA29A-F9D9-4C6B-99E4-D8728C8AE715}>
Все XML-контейнеры строятся по общему признаку. В первой декларации указывается тип документа – XML – и приводится дополнительная информация о нем. Сначала указывается версия XML-документа, после версии документа указывается кодировка. Объявление кодировки указывает набор символов документа. По умолчанию считается, что документ XML имеет кодировку UTF-8 (8-разрядный Unicode) или UTF-16 (16-разрядный Unicode). Если у документа одна из названных кодировок, этот атрибут можно не задавать. Атрибут «encoding» должен находиться в самом начале документа. Как и весь документ, объявление чувствительно к регистру символов [2].
Вторая декларация – это идентификатор GUID (Глобальный Уникальный Идентификатор), он создается ядром таким способом, чтобы гарантировать уникальность во времени и пространстве. Последняя декларация – это тоже уникальный идентификатор GUID XML-документа, показывающий, что описание диагноза закончено. Между второй и последней декларацией указаны непосредственно данные по диагнозу пациента.