CC BY
50
УДК 004.65:004.75
Подход к построению интегрирующей системы, объединяющей медицинские базы данных
А. С. Панкратов
Кафедра информационных технологий Российский университет дружбы народов ул. Миклухо-Маклая, д. 6, Москва, 117198, Россия
Рассматривается задача интеграции информации, содержащейся в электронных медицинских картах поликлиник и прочих медицинских учреждений. Цель — построение полной клинической картины заболевания пациентов. В качестве технологии интеграции предлагается использование медиатора с участием вспомогательного хранилища данных. Данный подход описывается на конкретном примере.
Ключевые слова: базы данных, интеграция информации, мультибазовые системы, медиатор, хранилище.
1. Характеристика предметной области
Информатизация медицинского обслуживания населения представляется задачей чрезвычайно актуальной. В настоящее время спектр предлагаемых медицинских услуг достаточно широк. Существует много категорий медучреждений различного уровня и масштаба: поликлиники районные, ведомственные, диагностические центры, коммерческие и полукоммерческие лечебные центры, специализированные центры (напр. противотуберкулёзные диспансеры, гепатологический центр), стационары, наконец - частнопрактикующие специалисты. Каждый конкретный пациент может обращаться для лечения в разные медучреждения. При этом в каждом из них ведётся свой учёт пациентов, заводится своя медкарта, проводятся свои обследования и т. д. И эта информация от различных источников связана между собой весьма слабо (общепринятая практика — запрашивать выписки из других медучреждений). Однако для уяснения общей клинической картины для данного пациента в ряде случаев следует обладать информацией о всей истории посещений этим пациентом каких-либо медучреждений на протяжении либо всей жизни, начиная с раннего детства, либо за последний период, сопоставлять результаты анализов, обследований, сделанных в разное время.
В настоящее время в ряде медучреждений электронный учёт больных уже существует. Часто он не идёт дальше уровня регистратуры, в некоторых центрах поддерживается ведение электронной мед. карты, в отдельных особо крупных медицинских центрах внедряется система Интерин [1], разработанная Исследовательским центром медицинской информатики Института программных систем имени А. К. Айламазяна РАН (г. Переславль-Залесский). В связи с этим возникает задача: объединить в единое информационное пространство медицинские данные от различных источников, каждый из которых обладает собственной компьютерной системой учёта пациентов и ведения медкарт. При этом эти компьютерные системы в общем случае разнородны, поскольку могут быть выполнены различными разработчиками. Иными словами, требуется создать интегрированную (мультибазовую) систему, прозрачным образом располагающуюся поверх уже существующих баз данных о пациентах различных медучреждений и объединяющую их в единое целое [2].
Здесь следует сделать необходимую оговорку, касающуюся понятия «врачебная этика» и, как следствие, необходимости кодировать/декодировать передаваемую по сети медицинскую информацию о частных лицах, а также поддерживать в данной мультибазовой системе жёсткую регламентацию доступа к информации об истории болезни каждого из пациентов, даже более усиленную по сравнению с теми правами доступа, которые используются в упомянутых выше системах.
Статья поступила в редакцию 3 декабря 2009 г.
Однако в данной работе основной акцент будет сделан на технологии интеграции информации, а «этический аспект» выходит за рамки данной публикации и требует отдельного рассмотрения.
2. Основные технологии интеграции данных
Существует три основных подхода к интеграции баз данных [3]:
1) федеративные базы данных — источники независимы, но могут сообщаться между собой для обмена информацией (эффективно при наличии небольшого числа источников);
2) хранилища данных - данные от источников на периодической основе загружаются в централизованное хранилище, возможно, с предварительной обработкой с целью приведения их в соответствие со структурой хранилища;
3) медиаторы - программные компоненты, принимающие запросы от пользователей и затем направляющие их к соответствующим источникам, возможно, с предварительной трансляцией; полученные ответы от источников приводятся в соответствие со структурой медиатора, объединяются и выдаются пользователю.
Следует отметить, что в настоящее время лишь намечаются основные контуры обобщённого подхода к решению задачи интеграции данных из разных компьютерных систем (см., например, [4]), большинство публикаций на эту тему затрагивает лишь частные предметные области со своими специфическими особенностями [5,6]. Настоящая статья также не претендует на общность, однако представляется, что описанный ниже подход может быть применён не только в медицине, но и в других областях.
3. Предлагаемая схема решения
Для решения рассматриваемой задачи интеграции медицинских данных предлагается использовать технологию медиаторов с участием вспомогательного хранилища.
Будем предполагать, что существует несколько независимых медучреждений (в дальнейшем — источников), работа каждого из которых сопровождается собственной компьютерной системой с использованием какой-либо СУБД, поддерживающей формат SQL. В рамках каждого из источников эта система может сопровождать различные бизнес-процессы (учёт пациентов, ведение медицинских карт, внутренняя работа - кадровый учёт, бухгалтерия, закупка медикаментов и пр.) Часть информации, касающаяся лечебных процессов, передаётся через компьютерную сеть в мультибазовую систему, позволяющую считывать аналогичную информацию из других источников.
Как выше отмечалось, при обращении пациента в медучреждение для лечащего врача, с целью уяснения полной клинической картины, часто бывает важно представлять всю историю обращения данного пациента в различные медучреждения (за определённый промежуток времени, по определённому профилю и пр.) Для этого следует запросить все медучреждения (источники), куда данный пациент когда-либо обращался. При этом для оптимизации процесса (быстродействие транзакции, минимизация нагрузки на сеть) важно запрашивать только те источники, которые содержат информацию по данному пациенту и не запрашивать другие источники. Для этой цели предлагается создать медиатор с элементом хранилища. Медиатор принимает запрос от лечащего врача и переадресует его только к тем источникам, где находится интересующая его информация. Для определения того, к каким источникам следует обращаться, при медиаторе создаётся «мини-хранилище», периодически закачивающее от источников лишь краткую информацию о новых обращениях пациентов в эти медучреждения-источники (а именно: атрибуты, идентифицирующие личность пациента (ФИО, паспортные данные, дата рождения, номер полиса), предмет обращения и код медучреждения). Примерный алгоритм:
при поступлении запроса медиатору происходит формирование вспомогательного запроса хранилищу, выявляющего, в какие именно медучреждения обращался данный пациент. После составления списка этих медицинских учреждений (т. е. источников информации) исходный запрос преобразуется в серию подзапросов, каждый из которых адресуется через сеть своему источнику в терминах этого источника.
4. Проблемы интеграции информации
В мультибазовой системе каждый из источников использует специфические термины и таблицы. В общем случае данные от разных источников обычно между собой не согласованы, а сами источники могут работать под управлением различных СУБД. Вследствие этого при обращении к данным нескольких источников через единую программную компоненту возникают проблемы интеграции информации, начиная от наличия либо отсутствия каких-либо признаков в каждом источнике и заканчивая мелкими несоответствиями, например, в типах представленных численных значений. Рассмотрим более подробно основные проблемы интеграции.
1. Различия в наименованиях. Различия в обозначениях данных в разных источниках, несущих одну и ту же нагрузку на концептуальном уровне, т. е. одни и те же сущности (или поля) называются разными именами. Например, сущность «пациент» может обозначаться как «Пациент», «Patient», «Больной», поле «дата рождения» как «ДатаРождения», «Дата_рожд» и т. п.
2. Различия в типах данных. Например, номера медицинских карт в одном источнике хранятся в виде символьных строк переменной длины, в другом - как строки постоянной (причём, возможно разной) длины, в третьем - в формате целочисленных значений.
3. Различия в множестве допустимых значений. Один и тот же признак в разных источниках может определяться разными константами. Например, мужской пол пациента в одном источнике обозначается литерой «М», в другом символьной строкой «муж».
4. Семантические различия. Одно и то же понятие, описываемое в каждом из источников, может толковаться своеобразно. Например, таблица «Patients» в одном источнике (районная поликлиника) охватывает всех своих пациентов, а в другом (ведомственная поликлиника) только пациентов, к ней приписанных, а для всех прочих существует таблица «OuterPatients» - из соображений, что для собственных пациентов необходимо иметь более полную информацию, чем для пациентов сторонних. Сюда же можно отнести различия в смысловой наполненности полей MEMO (комментариев). Для примера, в двух источниках в медицинской карте есть поле «View» (осмотр врача), но в одном из источников в него заносят и жалобы пациента, и результаты осмотра, а в другом - только результаты осмотра, а для жалоб пациента существует собственное поле.
5. Отсутствующие значения. В каждом конкретном источнике может не быть такой информации, которая наличествует в других. Например, коммерческие медицинские центры могут просто не вносить в свои базы номера медицинских страховых полисов своих клиентов.
Самый распространённый метод решения проблем интеграции - это поддержка таблиц соответствия (табл. 1), описывающих взаимосвязь элементов данных из различных источников. При интеграции данных с помощью медиатора, представляющего, по сути, виртуальную базу данных (представление для пользователя), эта виртуальная база имеет свои характеристики (реквизиты), которые также заносятся в общую таблицу соответствия.
Данной таблицей решается проблема приведения наименований одинаковых сущностей в различных источниках, а также их отсутствие (в случае отсутствия в соответствующей ячейке таблицы ставится значение NULL).
Таблица 1
Простейшая таблица соответствия
Медиатор Источник 1 Источник 2 Источник 3
Реквизит 1
Реквизит 2
Реквизит 3
5. Требования к интегрирующей системе
Помимо традиционной работы с каждой из баз данных-источников на локальном уровне требуется иметь возможность исполнять следующий набор дополнительных транзакций:
— исполнять запрос, высвечивающий историю обращения данного пациента в разные медучреждения с возможностью фильтрации результата по временному периоду и по характеру заболевания;
— соответствующие подзапросы направлять не ко всем источникам, а только к тем, где имеется запрашиваемая информация; для этой цели создаётся хранилище данных, периодически закачивающая от источников информацию о всех новых (после предыдущей закачки) пациентах и поводах их обращения в медучреждение;
— подключать к системе новые источники информации.
Требуется создать рабочие интерфейсы для пользователя и администратора, последний должен иметь возможность отслеживать состояние хранилища и процесс закачки данных.
6. Описание рабочей модели
Рассмотрим модель системы, состоящей из трёх источников данных — три медучреждения, выставляющие информацию о своих пациентах в мультибазо-вую систему. Будем их условно обозначать ОБ1, ОБ2 и ОБ3 (к примеру: ОБ1 — районная поликлиника, ББ2 — ведомственная, ББ3 — коммерческий медицинский центр). Предполагается, что все источники имеют сходные концептуальные схемы, каждый содержит информацию о своих врачах, пациентах и ведёт электронные медицинские карты пациентов. В картах отражаются следующие характеристики: дата приёма, жалобы пациента, результаты осмотра, диагноз, течение заболевания, назначения, рекомендации, направления, результаты анализов и прочих обследований.
Выпишем модельную структуру источников данных: Таблицы (поля). Ключевые поля подчёркнуты. ББ1:
Врачи (ТабНомер, ФИО, Должность, Специальность);
Пациенты (НомерМедКарты, Фамилия, Имя, Отчество, Пол, НомерПолиса, ДатаРождения, АдресРегистрации, Телефон, МестоРаботы, Должность);
МедицинскаяКарта (Номер, НомВрача, ДатаПриёма, Амбулаторн/Дом, Симптомы, РезультатыОсмотра, КодДиагноза, Рекомендации, Направления, СрокПоте-риТрудоспособности);
Диагнозы (Код, Название).
ББ2:
Врач (Код, ФИО, Специализация. Должность);
Пациент (Код, Фамилия, Имя, Отчество, Пол, ДатаРожд, ДанныеПолиса, КонтТелефон, Подразделение, СлужДолжность);
ПациентВнешний (Код, Фамилия, Имя, Отчество, Пол, ДатаРожд, Дан-ныеПолиса, ПаспДанные, АдрРегистр);
ИсторияБолезни (КодПациента, КодВрача, ДатаПосещения, Жалобы/Осмотр, ДиагнКод, Лечение/Направления);
Диагнозы (Код, Название).
DB3:
Персонал (ТабНо, ФИО, Профиль. Должность);
Клиенты (Шифр, Фамилия, Имя, Отчество, Пол, ДРожд, КонтТелНо);
Приём (ШифрКл, ВрачНо, Дата, Жалобы, РезОсм, КодДиагн, Рекомендации);
Диагнозы (Код, Название).
Примечание 1. Пол пациента в DB1 и DB2 (и в медиаторе) пишется «М» и «Ж», в DB3 - «муж» и «жен».
Примечание 2. Таблица «Диагнозы», содержащая коды диагнозов и их расшифровки, — справочная, формируется и сопровождается централизованно, на уровне Министерства здравоохранения и социального развития. Обновляется она не часто, после каждого обновления на каждый источник и на медиатор вновь закачивается.
Примечание 3. Смысловое содержание полей «Рекомендации» и «Направления» (тип MEMO) таблицы «Медицинская карта» источника DB1 в источниках DB2 и DB3 сведено в одно поле (того же типа), соответственно, «Лечение/Направления» и «Рекомендации».
Описанную структуру источников можно дополнить информацией о том, какими типами данных описывается значение каждого из полей таблиц (а также объём, выделенный для этих значений), отразить впоследствии эту информацию в таблицах соответствия и решить тем самым проблему различий в типах данных. Однако в связи с тем, что простых типов данных не так уж много (в настоящей схеме их даже можно свести к пяти: строка, число, дата, булево, MEMO) и чтобы не перегружать схему, в данной работе предполагается, что при медиаторе описаны правила преобразования стандартных типов данных, на основании которых преобразование типов в случае необходимости делается автоматически.
Структура медиатора в простейшем случае объединяет все структуры источников, однако для практической задачи целесообразно использовать лишь некое подмножество этого объединения, содержащее характеристики, существенные для данной задачи.
Структура медиатора:
Врачи (Код, ФИО, Специальность);
Пациенты (НомерМедКарты, Фамилия, Имя, Отчество, Пол, ДанныеПолиса, ПаспортныеДанные, ДатаРождения, АдресРегистрации, КонтТелефон);
МедКарта (Номер, КодВрача, ДатаПриёма, Жалобы, Осмотр, КодДиагноза, Рекомендации, Направления);
Диагнозы (Код, Название).
7. Таблицы соответствий медиатора
В рассматриваемой рабочей модели все источники предполагаются со сходными концептуальными схемами и каждой таблице из структуры медиатора соответствуют по одной таблице каждого из источников (за исключением одной ситуации: таблице «Пациенты» медиатора в источнике DB2 соответствуют две таблицы — «Пациент» и «ПациентВнешний»). В связи с этим и с целью простоты процедуры подключения нового источника представляется целесообразным соответствия медиатору для каждого источника прописать в отдельной таблице. Информация о том, какая таблица к какому источнику (Source) относится, прописывается в таблице-каталоге «TableCorrCat» (табл. 2).
Таблица 2
TableCorrCat
Source SourceHa3BaH^ SourceАдрес TableCorrltem
DB1 TableCorrltem 1
DB2 TableCorrItem_2
DB3 TableCorrItem_3
Таблицы соответствия медиатора и источника (ТаЫеСоггЙеш_1, ТаЫеСоггЙеш_2 и ТаЪ1еСоп\Йеш_3) имеют сходный вид, приведём для примера одну из них (табл. 3).
Таблица 3
TableCorrltem 2
Медиатор. таблица Медиатор.таблица. поле ОБ2.таблица ОВ2.таблица.поле
Врачи Код Врач Код
Врачи ФИО Врач ФИО
Врачи Специальность Врач Специализация
Пациенты НомерМедКарты Пациент Код
Пациенты НомерМедКарты ПациентВнешний Код
Пациенты Фамилия Пациент Фамилия
Пациенты Фамилия ПациентВнешний Фамилия
Пациенты Имя Пациент Имя
Пациенты Имя ПациентВнешний Имя
Пациенты Отчество Пациент Отчество
Пациенты Отчество ПациентВнешний Отчество
Пациенты Пол Пациент Пол
Пациенты Пол ПациентВнешний Пол
Пациенты ДанныеПолиса Пациент ДанныеПолиса
Пациенты ДанныеПолиса ПациентВнешний ДанныеПолиса
Пациенты ПаспортныеДанные Пациент NULL
Пациенты ПаспортныеДанные ПациентВнешний ПаспДанные
Пациенты ДатаРождения Пациент ДатаРожд
Пациенты ДатаРождения ПациентВнешний ДатаРожд
Пациенты АдресРегистрации Пациент NULL
Пациенты АдресРегистрации ПациентВнешний АдрРегистр
Пациенты КонтТелефон Пациент КонтТелефон
Пациенты КонтТелефон ПациентВнешний NULL
МедКарта Номер ИсторияБолезни КодПациента
МедКарта КодВрача ИсторияБолезни КодВрача
МедКарта ДатаПриёма ИсторияБолезни ДатаПосещения
МедКарта Жалобы ИсторияБолезни Жалобы/Осмотр
МедКарта Осмотр ИсторияБолезни Жалобы/Осмотр
МедКарта КодДиагноза ИсторияБолезни ДиагнКод
Таблица 3
TableCorrItem 2 (окончание)
Медиатор. таблица Медиатор.таблица. поле ОБ2.таблица ОБ2.таблица.поле
МедКарта Рекомендации ИсторияБолезни Лечение/Направления
МедКарта Направления ИсторияБолезни Лечение/Направления
Соответствие доменов (в данном случае только для поля «Пол» таблицы медиатора «Пациенты» и соответствующих полей источников) прописывается в отдельной таблице «ТаЫеСогтБошат» (табл. 4).
Таблица 4
TableCorrDomain
Медиатор. таблица Медиатор. таблица. поле Медиатор. знач. DB1. знач. DB2. знач. DB3. знач.
Пациенты Пол М М М муж
Пациенты Пол Ж Ж Ж жен
8. Подключение нового источника
Эта процедура выполняется экспертом. Назовём для примера новый источник DB4. Процедура подключения состоит в следующем: при медиаторе заводится новая таблица соответствия «TableCorrItem_4» (аналогичная описанным) и прописывается в таблице-каталоге «TableCorrCat». При необходимости дополняется таблица соответствия доменов «TableCorrDomain». Вся дальнейшая работа муль-тибазовой системы (запросы, закачка данных в хранилище) производится уже с учётом нового источника.
9. Структура хранилища и закачка данных
Хранилище состоит из одной таблицы «ФактыПосещения» с полями: Пациент-Фамилия, ПациентИмя, ПациентОтчество, ПациентДанныеПолиса, ПациентПас-портныеДанные, ПациентДатаРождения, ПациентАдресРегистрации, ДатаПриёма, ВрачСпециальность, Source).
Закачка данных о фактах новых посещений от всех источников, подключённых к мультибазовой системе, производится периодически, например, раз в сутки. Закачиваются результаты следующего запроса, транслированного медиатором на каждый из источников:
SELECT Пациент.Фамилия, Пациент.Имя, Пациент.Отчество, Пациент.Данные Полиса, Пациент.ПаспортныеДанные, Пациент.ДатаРождения, Пациент.АдресРегис-трации, МедКарта.ДатаПриёма, Врачи.Специальность
FROM Пациенты, МедКарта, Врачи
WHERE (Пациенты.НомерМедКарты=МедКарта.Номер) AND (Врачи.Код= МедКарта.КодВрача) AND (ДатаПриёма=CurrentData)
Процесс преобразования запроса в термины источников будет описан далее. Результат каждого запроса (после соответствующего переименования полей) дополняется полем «Source» (источник) и записывается в таблицу-хранилище «Фак-тыПосещения».
10. Исполнение запроса к медиатору
Основной запрос, адресованный лечащим врачом к медиатору, формулируется так: вывести информацию обо всех предшествующих посещениях врачей данным пациентом с информацией о соответствующих медучреждениях и записями в медицинских картах. Предусматривается возможность фильтрации запроса по диапазону дат посещения и по специальностям врачей (в интерфейсе должны быть соответствующие опции).
Соответствующий SQL-код:
SELECT Врачи.Специальность, Врачи.ФИО, МедКарта.Жалобы, МедКар-та.Осмотр, Диагнозы.Название, МедКарта.Рекомендации, МедКарта.Направления
FROM Врачи, МедКарта, Пациенты, Диагнозы
WHERE (<заданные критерии поиска>) AND (Врачи.Код = МедКарта.КодВра-ча) AND (Пациенты.НомерМедКарты = МедКарта.Номер) AND (МедКарта.Код-Диагноза = Диагнозы.Код)
(< заданные критерии поиска > — это личные данные пациента, диапазон дат посещения и специальности врачей).
Результат дополняется полем с названием мед.учреждения (полем «SourceНа-звание» из таблицы «TableCorrCat»).
Опишем технологию исполнения данного запроса.
Пользователь мультибазовой системы (врач) вводит в форму-интерфейс критерии поиска: личные данные пациента (ФИО, дату рождения и прочее, что имеется в наличии), а также диапазон дат посещения и специальность соответствующих врачей. На первом этапе запрос адресуется таблице «ФактыПосещения» хранилища. Определяются источники, где следует искать информацию для основного запроса:
SELECT Source
FROM ФактыПосещения
WHERE <заданные критерии поиска>
Результаты записываются во временную таблицу «Sources».
На втором этапе происходит обращение с исходным запросом к каждому из найденных на первом этапе источникам. При этом для каждого источника SQL-код запроса преобразуется к виду, который данный источник способен воспринять. Преобразование запроса производится с помощью таблиц соответствия: сначала по таблице «TableCorrCat» определяется имя таблицы «TableCorrltem», затем с помощью таблицы «TableCorrItem» производится замена соответствующих операндов исходного запроса, написанного для медиатора, операндами соответствующего источника.
На третьем этапе медиатор получает ответы от источников и производит их обратное преобразование к структуре медиатора. После этого каждый ответ дополняется полем с информацией об источнике (медучреждении), все ответы объединяются и выдаются пользователю.
11. Особые ситуации
Итак, описана общая схема построения мультибазовой системы, интегрирующей информацию из медицинских баз данных. Однако при каждой конкретной реализации могут возникать особые ситуации. Каждая подобная ситуация может требовать отдельного изучения. Рассмотрим некоторые из них.
Ситуация первая. Неоднозначная идентификация пациента. Не все источники могут поддерживать атрибуты, однозначно определяющие пациента (такие как номер медицинского полиса). В рассмотренном примере на каждом источнике поддерживаются ФИО и дата рождения пациента (хотя в реальности не всегда так), однако может возникнуть прецедент, когда два или более индивида обладают одинаковыми названными атрибутами. С учётом требований конфиденциальности предлагается следующий способ. Пусть каждый пациент обладает доступом (для чтения) ко всем своим медицинским картам и имеет для этого свой пароль. Первый
этап запроса дополняется полями «ДатаПриёма» и «ВрачСпециальность» таблицы «ФактыПосещения» и полями ЯоигсеНазвание и ЯоигсеАдрес таблицы ТаЫеСоггСа^ Когда выдаётся список-ответ, при каждом элементе этого списка имеется поле для ввода пароля пациентом. В случае ошибки (запись относится к другому пациенту-тёзке) пароль не воспримется. Пароль для пациента заводится в каждом медучреждении при первом обращении.
Ситуация вторая. Изменение таблицы диагнозов. Как выше отмечалось, таблица диагнозов (содержащая коды диагнозов и их названия) формируется управляющей организацией на уровне министерства и рассылается на все источники. Обновляется она крайне редко, но всё же иногда это происходит. При её обновлении все записи в медицинских картах, предшествующие этому моменту, оказываются с устаревшими кодами диагнозов. Для разрешения этого противоречия предлагается использовать технологию поддержки версий, а именно: все прежние версии таблицы диагнозов сохраняются с фиксацией времени активизации каждой. При исполнении основного запроса к медиатору поле «Диагнозы.Название» берётся из соответствующей версии таблицы «Диагнозы» путём соотнесения времени её активизации с датой посещения.
Литература
1. Состав и функции интегрированной информационной системы «Интерин PROMIS». — http://www.interin.ru/page-id-78.html.
2. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд. — М.: Издательский дом «Вильямс», 2000. — 1120 с.
3. Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. — М.: Издательский дом «Вильямс», 2003. — 1088 с.
4. Торшин Д. В. Организация единого интегрированного пространства на основе универсального формата обмена данными // Научно-технические ведомости СПбГПУ, серия «Информатика. Телекоммуникации. Управление». — 2009. — № 2 (71). — С. 26-32.
5. Юмагужин Н. В. Сопоставление записей и интеграция данных о физических лицах // Программные системы: теория и приложения. — 2008. — Т. 1. — С. 251260.
6. Воробьёва М. С. Построение модели интеграции данных в информационно-управляющих системах // Модернизация образования в условиях глобализации: Круглый стол «Образование через науку и инновации», 14-15 сентября 2005 г. / под ред. В. Н. Кутрунова. — Тюмень: Изд-во ТюмГУ, 2005. — С. 26-28.
UDC 004.65:004.75
An Approach to Construction of Integrating System which Unites Databases in Medicine
A. S. Pankratov
Information Technologies Department Peoples' Friendship University of Russia 6, Miklukho-Maklaya str., 117198, Moscow, Russia
The problem of integration of the information contained in the electronic maps of medical clinics and other medical institutions is considered. Purpose — to build complete clinical vision of disease of patients. As integration technology is proposed to use a mediator with the auxiliary data warehouse. This approach is described by a concrete example.
Key words and phrases: databases, integration of the information, multidatabase systems, mediator, data warehouse.
