Содержание к диссертации
Введение
Глава I. Современное состояние проблем информатизации и автоматизации в медицине 7
1.1 Проблема разнородности и стандартизации медицинской информации для разработки медицинских информационных систем 13
1.2 Направления стандартизации в медицинской информатике 14
1.3 Необходимость информационных стандартов в медицине 15
1.4 Опыт ведущих организаций по разработке информационных стандартов для медицины 17
Глава II. Новые информационные технологии и принципы построения на их основе систем обмена медицинскими сообщениями 24
2.1 WEB-сервисы, как основа информационных систем, ориентированных на обмен сообщениями 24
2.2 Технология Web-сервисов для обмена медицинскими сообщениями 36
2.3 Технологии построения иерархических систем сообщений 39
Глава III. Принципы проектирования систем обмена сообщениями для телемедицины 48
3.1 Методы разработки современных систем телемедицины 48
3.2 Информационная модель для построения систем, поддерживающих обмен сообщениями 60
3.3 Формализация данных в предметной области медицины. Онтологии 67
3.5 Принципиальный профиль системы телемедицины 77
Глава IV. Реализация принципов проектирования на примере системы удаленных консультаций в онкологии 80
4.1 Архитектура системы 82
4.2 Проектирование системы. Прецеденты в системе 86
4.3 Проектирование и реализация базы данных системы 96
4.4 Реализация клиентского приложения 104
Заключение 113
Литература 115
- Опыт ведущих организаций по разработке информационных стандартов для медицины
- Технология Web-сервисов для обмена медицинскими сообщениями
- Информационная модель для построения систем, поддерживающих обмен сообщениями
- Проектирование и реализация базы данных системы
Введение к работе
По мнению большинства экспертов, прогнозирующих развитие науки и
техники, двадцать первый век должен стать "веком коммуникаций", что подразумевает повсеместное использование глобальных информационных систем. Использование таких систем в медицине открывает качественно новые возможности:
в обеспечении взаимодействия региональных клиник с крупными медицинскими центрами;
в вопросах интеграции отечественных систем в международные медицинские ассоциации;
в оперативном получении результатов последних научных исследований;
в деле подготовки и переподготовки медицинских специалистов.
Главной задачей данной работы является апробация технологий обмена медицинской информацией. В результате проведенных исследований были изучены и проанализированы существующие стандарты и протоколы, и была предложена методика реализации протокола передачи медицинских данных посредством обмена сообщениями.
Тот факт, что именно обмен сообщениями в медицинских информационных системах является центральным, общепризнан основными мировыми разработчиками и производителями в области медицинских информационных систем HL7 и CEN/TC 251. Системы, основанные на обмене сообщениями, имеют то исключительное для телемедицины преимущество, что изначально унифицируют обмен информацией (interoperability) между разнородными пользовательскими приложениями, характеризующимися различными профилями, платформами, концепциями и т.д.
В результате исследований в рамках данной диссертационной работы были поставлены и защищаются следующие научные положения:
1. Требования для разработки стандартов сообщений:
стандарты сообщений для обмена медицинскими данными должны строиться на основе существующей концепции предметной области медицины;
стандарты медицинских сообщений должны быть адаптированы к современным коммуникационным технологиям;
стандарты сообщений должны быть масштабируемыми -иметь возможность гибкого изменения или расширения при имеющейся на то необходимости;
стандарты сообщений должны быть открытыми - любое заинтересованное лицо, принимающее правила использования системы, должно иметь возможность воспользоваться ею.
2. Структура сообщения должна быть стандартизована с целью
унификации обмена информацией.
3. Структура сообщения для передачи данных в области онкологии
должна соответствовать выбранной модели сообщения.
4. Прототип системы удаленных медицинских консультаций, основанной
на обмене сообщениями должен соответствовать тому, что:
система должна быть ориентирована на XML, что позволит создавать запросы к Web-службам настолько же оперативно, насколько быстро могут быть написаны сообщения XML для вызовов программ существующих приложений;
существует возможность многократного использования одних и тех же сервисов для различных клиентских приложений;
использование XML-стандарта гарантирует одинаковое
выполнение идентичных функций системы вне зависимости
от того, кто является пользователем системы - клиентское
приложение на любой платформе или другая служба.
С целью унификации обмена информацией структура сообщений должна быть стандартизована. Существует ряд требований, которым должны удовлетворять стандарты сообщений:
стандарты сообщений должны отражать семантику предметной области - строиться на основе понятий и концепций данной области медицины
стандарты сообщений должны быть масштабируемыми — иметь возможность гибкого изменения или расширения при имеющейся на то необходимости
стандарты сообщений должны быть открытыми — любое заинтересованное лицо, принимающее правила использования системы, должно иметь возможность воспользоваться ею.
Наиболее адекватным средством стандартизации, удовлетворяющим перечисленным требованиям, является открытая технология XML, ориентированная на протокол обмена сообщениями SOAP. Архитектура системы построена на базе современных web-технологии, таких как XML, SOAP, web services. В основе работы системы лежит обмен медицинскими сообщениями.
Информационная система удаленных медицинских консультаций в области онкологии и онкопатологии, рассмотренная в данной работе, может быть использована широким кругом специалистов региональных медицинских клиник для оперативно взаимодействия с экспертами из крупных медицинских специализированных центров, в частности Российским онкологическим центром им. Н.Н. Блохина РАМН.
Система позволяет специалистам, используя лишь стандартное программное обеспечение (web-браузеры), передавать клинические данные и предполагаемый предварительный (в случае необходимости) диагноз экспертам, обычно находящимся в удаленных медицинских центрах. Эксперты, в свою очередь, имеют возможность при помощи средств автоматизации системы быстро оформить либо собственный диагноз, либо внести уточнения в имеющийся. Достоинством системы является возможность оперативного обмена данными, что весьма существенно в экстренных клинических случаях.
При разработке данной системы были существенно использованы многолетний опыт формализации предметной области и заделы по автоматизации в онкологии специалистов Российского онкологического центра им. Н.Н. Блохина РАМН и ведущиеся в Институте радиотехники и электроники РАН исследования в области телекоммуникаций и телемедицины [11].
Опыт ведущих организаций по разработке информационных стандартов для медицины
На сегодняшний день среди довольно многочисленной группы как общественных, так и коммерческих организаций - разработчиков медицинских стандартов, следует выделить двух лидеров, стандарты которых претендуют на роль широкого международного использования - HL7 (Health Level Seven) и CEN/TC 251 (Comite Europeen de Normalisation / Comite 251) [30].
HL7 - это американская общественная организация, которая разрабатывает наиболее широко распространенный в Северной Америке стандарт для обмена медицинскими электронными данными, в то время как комитет CEN/TC 251 работает на европейском пространстве и ориентирован на разработку медицинских информационных стандартов для Европы. Стандарты HL7 и CEN/TC 251 являются основными на американском и европейском информационном медицинском пространстве, составляющем на сегодняшний день 80% мирового. На сегодняшний день эти стандарты не совместимы, но было организовано несколько встреч специалистов из HL7 и CEN/TC 251 с целью более тесного сотрудничества между этими организациями и разработки совместимых стандартов для Европы и Америки [30,31].
Организация HL7 (Health Level Seven) была основана в 1987 году для того, чтобы развить стандарты для электронного обмена клинической, финансовой и административной информацией среди независимых компьютерных медицинских систем, к которым относятся: стационарные информационные системы, клинические лабораторные системы и другие.
За последние четыре года стандарт стали поддерживать более чем 1,500 больниц, профессиональных обществ, промышленных организаций здравоохранения, включая почти всех главных консультантов по системам здравоохранения и продавцов в США. Он также используется в Австралии, Австрии, Германии, Голландии, Израиле, Японии, Новой Зеландии и Великобритании.
В июне 1994 Американский Национальный Институт Стандартов (ANSI) объявил HL7 ANSI-аккредитованным стандартом. HL7 выпустил четвертую версию стандарта (Версия 2.2) в декабре 1994, в 2000 году появилась версия 2.4. Текущая версия стандарта 3.0 находится на стадии утверждения комитетом.
В 1997 году Главный научно-исследовательский вычислительный центр Медицинского центра Управления делами Президента Российской Федерации обеспечил перевод версии 2.2 на русский язык и получил право на ее распространение в России.
Термин «Level 7» относится к верхнему уровню модели «Взаимодействия открытых систем» (Open System Interconnection (OSI)) Международной Организации по Стандартам ISO. Однако, это не означает, что стандарт полностью соответствует элементам седьмого уровня модели OSI, и он не опирается на спецификации нижних уровней, одобренные ISO. HL7, однако, соответствует концептуальному определению интерфейса приложений, соответствующему седьмому уровню этой модели. Он включает определение и структуру передаваемых данных, синхронизацию обмена и связи приложений, обнаружение и обработку ошибок передачи сообщений [32].
Стандарт в настоящее время адресует интерфейсы различных медицинских систем, которые посылают или получают миграционные данные о пациенте: прием/регистрация, выписка или направление (ADT данные) и различные запросы, осуществляют планирование ресурсов, заказы, фиксирование результатов, клинические наблюдения, расчеты за электроэнергию, сохранение и модифицирование информации, медицинские записи и контроль за пациентом. Европейский комитет CEN/TC 251 (Comitd Europeen de Normalisation / Comite 251) по разработке и внедрению стандартов обмена данными между независимыми компьютерными системами в медицине образован в 1990 г. по решению Европейской комиссии по стандартизации и имеет спектр разработок стандартов, охватывающий все стороны медицинской информатики. СЕТ/ТС 251 разрабатывает требования к медицинским информационным структурам для того, чтобы обеспечить: 1) внутренний обмен данными между устройствами и информационными системами; 2) интеграцию данных для мультимедийного представления; 3) внешний обмен данными между отделами и другими легальными пользователями в каком-либо другом медицинском секторе, а так же разрабатывает требования относительно сохранности, безопасности передачи и хранения информации [33]. В комитет входят семь рабочих групп, в работе которых принимают участие представители стран Европейского Содружества: - группа 1 - информационные модели и форматы данных в здравоохранении; - группа 2 - терминология, семантика и базы знаний в здравоохранении; - группа 3 - коммуникации и передача сообщений в здравоохранении; - группа 4 - медицинские изображения и мультимедиа; - группа 5 - передача данных между медицинскими устройствами; - группа 6 - защита, обеспечение конфиденциальности и сохранности информации в здравоохранении; - группа 7 - обмен данными со сменными устройствами (включая магнитные карты).
Технология Web-сервисов для обмена медицинскими сообщениями
Универсальность включает возможность межплатформенного обмена данными между организациями, ЭВМ и процессами. В технологии Web-сервисов универсальность определяется за счет возможностей расширения заголовков (headers) и тел сообщений (body) SOAP-конвертов. Ориентированность Web-сервисов на HTTP протокол делает их универсальными по отношению к транспортному уровню обмена.
Равноправие подсистем подразумевает возможность полной распределенности системы в целом. В частности, положительным моментом является отсутствие требования наличия централизованных серверов (и соответствующего администрирования). Вместе с тем, необходимо обратить внимание на то, что равноправие подразумевает необходимость "программных шлюзов" для подсистем - для преобразования протоколов, маршрутизации, секретности и т.д. - в конечном счете, дополнительную работу для обеспечения совместимости со стандартами обмена.
Помимо стандартных методов GET и POST протокола HTTP, Web-сервисы имеют возможность передавать и получать информацию при помощи структурированного языка SOAP, производного от XML, также являющихся де-факто стандартами в современных информационных технологиях.. Поскольку разрабатываемые в проекте совокупности функциональные стандартов также основываются на синтаксисе XML, технология SOAP представляется наиболее адекватным средством для разработки информационных систем телемедицины. На данный момент корпорацией Microsoft [42] разработаны и выпущены в составе среды разработки приложений .NET (doiNet) удобные средства создания и отладки Web-сервисов. Эти средства существенно упрощают процесс разработки сервисов, интегрированная среда Visual Studio .NET. делает процесс разработки прозрачным и доступным любому программисту среднего уровня. При работе над прототипом информационной системы формирования формализованного заключения в онкологии нами активно использовались данные средства, и они зарекомендовали себя с самой лучшей стороны.
Web-Сервисы .NET обладают весьма высокой функциональностью и позволяют разбивать обычные приложения на две стандартные части — клиентскую и серверную. Клиентская часть включает в себя средства отображения информации, а вся логика приложения может находиться в серверной части.
В общем случае, Web-сервисы принимают и передают информацию на языке XML. Этот язык, естественно, является открытым, а не проприетарным стандартом. Также следует учитывать, что XML, как и его предшественник HTML, не зависит от платформы и операционной системы. Сочетание этих двух факторов позволяет разработчикам свободно создавать самые различные клиентские приложения, функционирующие на разных компьютерных платформах. То есть, одному сервису может соответствовать несколько клиентских приложений.
XML-документы, пересылающиеся от сервера к клиенту и обратно, передаются по протоколу HTTP, который пропускается практически всеми брандмауэрами, что также прибавляет привлекательности идее Web-сервисов.
Следует отметить и тот факт, что Web-сервисы являются самодокументируемыми. То есть любое клиентское приложение может получить информацию о структуре сервиса, о его функциональности и правилах вызова функций, поддерживаемых Web-сервисом..
Web-сервисы способны передавать и получать информацию тремя способами: с применением методов GET и POST стандартного протокола HTTP или при помощи языка SOAP, который является производным от XML. Первые два варианта разрешают использовать в качестве клиентского приложения стандартный браузер, но необходимо отдавать себе отчет, что это далеко не идеальный вариант. Во-первых, при помощи браузера весьма трудно организовать вызов всех функций достаточно сложного сервиса. Разработчику необходимо исследовать структуру сервиса заранее, перед тем, как создавать Web-страницы для доступа к сервису. Так что в этом случае мы теряем преимущества самодокументируемости. Во-вторых, следует помнить, что вывод информации все равно будет идти в "чистом" XML, который браузер не сможет адекватно отобразить. Поэтому для работы с Web-сервисами, обладающими достаточно серьезной функциональностью, следует все же ориентироваться на язык SOAP.
Политика взаимодействия Web-сервиса .NET с клиентским приложением следующая. При первом обращении клиентского приложения, которое "не знает" структуры сервиса, тот передает клиенту информацию о поддерживаемых им функциях и параметрах, необходимых для вызова этих функций. Передача этой информации о структуре называется "контрактом". Подобная информация извлекается из описания сервиса, которое для каждого сервиса создается на языке WSDL [43].
После того как клиент получает этот "контракт", он анализирует полученную информацию и на ее основе формирует запросы к сервису, используя вызовы его функций. А затем идет просто обмен запросами к сервису и ответами на них, которые формируются на языке XML. Естественно, чтобы Web-сервисы могли получать и отправлять информацию, для чего, как мы знаем, используется протокол HTTP, на серверной машине должен быть установлен WWW-сервер IIS.
В силу изложенной выше аргументации следует, что для достижения поставленных целей реализации информационных систем телемедицины -технологии на основе использования Web-сервисов с SOAP обмена данными являются перспективными, и целесообразно именно в этом ключе осуществлять решение поставленной задачи.
Другой аспект создания информационных систем, основанных на обмене сообщениями - реализация на основе моделей унифицированных, стандартизованных способов хранения, обмена и поиска структурированных данных. Наиболее перспективными для данной задачи представляются языки разметки, в частности, активно развивающаяся технология XML (Extensible Markup Language) [7]. XML - универсальный, не зависящий от платформ стандарт, обеспечивающий концепции и технологии для гибких, открытых, и стандартизованных решений проблем структурирования, хранения и обмена данными. Основное достоинство (и назначение) XML заключается в разделении информационного содержания электронных документов от процедур обработки информации, в частности, способов ее представления. Достоинством XML также является его ориентация на возможность полной автоматизации обработки документов компьютерными системами.
Информационная модель для построения систем, поддерживающих обмен сообщениями
Одним из результатов анализа системы функциональных стандартов является тот факт, что недостаточно простой декларации о их структуре и содержании. При динамическом обмене сообщениями (с заданной структурой и определенным содержанием), необходимо разработать, предусмотреть дополнительные требования к процедурам, выполняемым при получении/отправке сообщений системы - определить ответственности сторон. Совокупность ответственностей в контексте всей системы определяет, в конечном счете, требования совместимости приложений с системой функциональных стандартов. Поскольку основное внимание уделяется разработке системы сообщений, а не поведению приложений, на начальном этапе Use Case анализа разрабатывается виртуальная система, в которой актерами являются абстрактные медицинские приложения способные получать/отправлять сообщения. Задачи виртуальной системы при этом - компоновка и отправление соответствующих сообщений (см. рис.12).
Для реализации данного формализма специально разработана концепция ролей приложений (Application Roles). С точки зрения диаграмм использования, роли приложений являются актерами в системе сообщений. Однако, в сравнении с общим случаем, роли приложений являются актерами со своим собственным набором ответственности.
Другой особенностью системы функциональных стандартов должно быть то, что каждый вариант ответственности в диаграммах использования подразумевает создание-передачу-прием- интерпретацию сообщений, поэтому требует для взаимодействия по крайней мере пару актеров - в ролях приложения-отправителя и приложения-получателя. Приложение-получатель в свою очередь несет ответственность за предоставление результатов пользователю приложения.
В силу того, что анализ использования и документация в виде диаграмм использования являются в сильной степени формализованными, они могут представлять трудность для понимания неспециалистами. Поэтому оправдано использование неформализованных описаний системы функциональных стандартов, дополняющих модель использования. Неформализованные описания могут оказаться полезными в частности в следующих аспектах: Анализ использования не дает временной динамики обмена сообщениями, в то время как эксперты зачастую маслят обмен как некоторый временной процесс. Поэтому целесообразно отразить это представление в неформализованном описании. Анализ использования представляет пользователей системы в виде абстрактных ролей приложений. Реальные пользователи могут существенно от них отличаться, что имеет смысл отразить в неформализованном описании. Неформализованные описания, содержащие произвольно структурированные представления экспертов о функциях системы, включая "имеющие смысл" временные последовательности сообщений, пользователей и т.д. могут быть подходящей прелюдией к формальному процессу анализа использования [61]. Методология оформления интерфейсов пользователей системы функциональных стандартов Как отмечено выше, продуктивность (формального) анализа использования будет выше, если ему предшествует процесс неформализованного описания. Подобное описание может бать результатом обсуждения требований к системе с заинтересованными специалистами и экспертами. По завершении анализа должна быть сформирована модель использования, основной целью которой является определение предметной области, т.е. тех сообщений, которые будет поддерживать система [60].
Формальный процесс анализа использования начинается с структурирования вариантов использования "верхнего уровня" и заканчивается определением недетализируемых далее вариантов использования "нижнего (leaf-level) уровня". На диаграммах использования связанные варианты могут группироваться в системы / подсистемы / пакеты / категории. Разные варианты могут быть связаны типизированными ассоциациями (стереотипы «specialize», «include», «extend»). Важно подчеркнуть, что декомпозиция сверху-вниз осуществляется не по принципу уточнения функциональности, а на основе архитектурной декомпозиции. Поэтому, как правило, варианты использования нижнего уровня ассоциируются с полными циклами изменения состояний сущностных классов модели сообщений. Это соображение вместе с анализом неформализованного описания облегчает выявление вариантов использования нижнего уровня.
Каждый вариант использования должен быть подробно документирован при помощи комментариев в виде произвольного текста, структурированных описаний действий актеров (Actor Actions), ответов системы (System Responsibilities) и нескольких поясняющих диаграмм — активности, взаимодействия и т.д. Варианты использования нижнего уровня, кроме того, должны содержать описание инициализирующих событий (initiating trigger), формальную спецификацию содержания сообщения, взаимодействующих с ними ролей приложений и ответственности при получении сообщений.
Проектирование и реализация базы данных системы
Вопрос проектирования базы данных для информационной системы является крайне важным. От того, насколько успешно будет спроектирована база данных, зависит эффективность функционирования системы в целом, ее жизнеспособность и возможность расширения и дальнейшего развития. Поэтому вопрос проектирования баз данных выделяют как отдельное, самостоятельное направление работ при разработке информационных систем.
Проектирование баз данных - это итерационный, многоэтапный процесс принятия обоснованных решений в процессе анализа информационной модели предметной области, требований к данным со стороны прикладных программистов и пользователей, синтеза логических и физических структур данных, анализа и обоснования выбора программных и аппаратных средств. Этапы проектирования баз данных связаны с многоуровневой организацией данных.
Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так называемая модель ANSI/SPARC) [16]: пользователем. Концептуальная схема является полной совокупностью всех требований к данным, полученной из пользовательских представлений о реальном мире. Внутренняя схема - это сама база данных.
Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы: 1. Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия: о обследование предметной области, изучение ее информационной структуры о выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами о моделирование и интеграция всех представлений По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь". 2. Логическое проектирование - преобразование требований к данным в структуры данных. На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей. 3. Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д. Проектирование БД- это сложный и трудоемкий процесс. Неудачно спроектированная БД может усложнить процесс разработки прикладного программного обеспечения, обусловить необходимость использования более сложной логики, которая, в свою очередь, увеличит время реакции системы, а в дальнейшем может привести к необходимости повторного проектирования логической модели БД. Реструктуризация или внесение изменений в логическую модель БД это очень нежелательный процесс, поскольку он является причиной необходимости модификации или даже перепрограммирование отдельных задач. Подходы проектирования БД
Каждый этап проектирования рассматривается как определенная последовательность итеративных процедур, в результате которых формируется определенная модель БД.
Существует много разных подходов к семантическому моделированию баз данных. Классическим подходом является моделирование с помощью модели «Сущность-Связь» (ER-модель). Однако для моделирования базы данных можно использовать UML (диаграммы классов).
Языковой механизм диаграмм классов по своей сути не отличается от существенно ранее внедренного в практику языкового механизма ER-диаграмм. Тем не менее, проектирование реляционных баз данных в среде UML дает одно существенное преимущество: можно выполнить весь проект создания информационной системы на основе одного общего инструмента.
В контексте проектирования реляционных БД структурные методы проектирования, основанные на использовании ER-диаграмм, и объектно-ориентированные методы, основанные на использовании языка UML, различаются, главным образом, лишь терминологией. ER-модель концептуально проще UML, в ней меньше понятий, терминов, вариантов использования. И это понятно, поскольку разные варианты ER-моделей разрабатывались именно для подде жки п оекти ования еля ионных Б и ER-мо ели почти не со е жат возможностей, выходящих за пределы реальных потребностей проектировщика реляционной БД.
Переход от диаграммного представления концептуальной схемы базы данных к ее реляционной схеме не зависит от разновидности используемых диаграмм. В частности, методика, разработанная для классических диаграмм «Сущность-Связь» (Entity-Relationship diagram), практически всегда пригодна для диаграмм классов UML.
Поскольку UML может использоваться для объектно-ориентированного моделирования всего, что угодно, в нем содержится масса различных понятий, терминов и вариантов использования, совершенно избыточных с точки зрения проектирования реляционных БД. Если вычленить из общего механизма диаграмм классов то, что действительно требуется для проектирования реляционных БД, то мы получим в точности ER-диаграммы с другой нотацией и терминологией.
