Компьютер-Информ || Архив || Рубрики || Поиск || Подписка || Работа || О "КИ" || Карта

ИТ в медицине

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

(Окончание. Начало N23 2006г.)

Доминирующие стандарты передачи записей в электронную историю болезни

Конечно, стандарты передачи записей в электронную историю болезни разрабатывались не только в США. За последние 7 лет большая работа по стандартизации медицинской информатики была проделана Техническим комитетом ТС251 Европейского комитета по стандартизации CEN, выпустившим 39 стандартов и 6 технических отчетов, дополняющих эти стандарты. Однако в отличие от HL7 и DICOM, это были частные стандарты, например, отдельно стандартизовались передача лабораторных сообщений (заказы и результаты) и передача электронных рецептов. В результате, они оказались гораздо менее согласованными между собой, чем, скажем, отдельные главы стандарта HL7. Чтобы преодолеть эту тенденцию, в 1999 году Техническим комитетом ТС251 CEN была начата подготовительная работа по интеграции ряда европейских стандартов с американским стандартом HL7. Кроме того, этот комитет решил не разрабатывать чисто европейский стандарт передачи медицинских изображений. Поэтому в 1997 году первые 8 частей стандарта DICOM с небольшими изменениями и дополнениями были приняты им как европейский стандарт ENV 12052 (MEDICOM), а части 10 и 11, посвященные обмену изображениями на внешних носителях, после определенной доработки были приняты как стандарт ENV 12623 (MI-MEDICOM). Таким образом, в данной предметной области стандарты HL7 и DICOM, безусловно, являются доминирующими.

Проблемы сопровождения стандартов

Мало разработать стандарт и добиться его утверждения де-факто или де-юре. Стандарт надо поддерживать в актуальном состоянии, отражающем постоянный прогресс медицинской науки и практики. Чем сложнее стандарт и чем большую предметную область здравоохранения он охватывает, тем сложнее и дороже его сопровождение. Не удивительно, что в здравоохранении "выживает" относительно небольшое число информационных стандартов, однако даже те, чья история насчитывает не один десяток лет, не могут рассчитывать на спокойное существование. Интеграция является одним из основных путей обеспечения жизнеспособности разработанных стандартов. Она может принимать различные формы, которые ниже обсуждаются на конкретных примерах.

Вертикальная интеграция стандартов

Стандарты передачи записей в электронную историю болезни находятся как бы на более высоком уровне по отношению к стандартам медицинской терминологии. Первые указывают, как передавать информацию и какая информация должна передаваться при возникновении тех или иных событий. Вторые указывают, как кодировать передаваемую информацию, и как ее отдельные элементы связаны между собой. Хотя стандарты передачи записей обычно позволяют использовать любые системы кодирования за счет того, что вместе с кодом можно передать имя использованной системы кодирования, однако большая степень свободы имеет свои недостатки. Если в двух медицинских информационных системах реализован один и тот же стандарт передачи записей, но используются разные системы кодирования информации, то эти информационные системы не смогут понимать передаваемые им коды. Поэтому в последнее время, не отказываясь от возможности использования произвольных систем кодирования, стали выделять среди них рекомендованные стандарты передачи записей. Если две медицинские информационные системы используют один и тот же стандарт передачи записей и одну и ту же систему кодирования информации, то проблемы взаимопонимания существенно снижаются.

Приведем несколько примеров вертикальной интеграции стандартов, то есть интеграции стандартов разного уровня.

Интеграция стандарта HL7 и кодов LOINC

Одним из важнейших приложений стандарта HL7 является передача заказов на лабораторные анализы и результатов анализов. Естественно, в сообщениях обмена заказами и результатами центральное место занимает номенклатура лабораторных анализов и диагностических исследований. К числу наиболее развитых классификаций лабораторных анализов относятся ось Р (процедуры) номенклатуры SNOMED и коды LOINC, представляющие собой систему универсальных идентификаторов (названий и кодов), предназначенных для использования в электронных документах с результатами лабораторных и клинических исследований. Поскольку коды LOINC развиваются гораздо динамичнее оси Р номенклатуры SNOMED и отличаются большей детализацией, то начиная с версии 2.3 стандарт HL7 рекомендует коды LOINC к использованию в своих сообщениях заказов/результатов лабораторных анализов и диагностических исследований.

Интеграция стандарта DICOM и номенклатуры SNOMED

Несколько лет назад казалось, что по аналогичному пути пойдет стандарт DICOM: назревала его интеграция с номенклатурой SNOMED. Это было обусловлено тем, что результаты лучевого исследования, в сущности, являются мультимедийными документами, представляющими собой сочетание текстов, растровых и векторных изображений и даже звуков (надиктованных заключений). До недавнего времени в силу традиций, недостаточной компьютеризации отделений лучевой диагностики и сложности подготовки мультимедийных документов эти компоненты результата существовали отдельно друг от друга. Чтобы объединить их в единое целое, необходимо было стандартизовать структуру и содержание текстовой части результата, обеспечив в ней возможность непосредственных ссылок на изображения, на их компоненты, на звукозапись.

Хотя эта задача уже решалась в стандарте HL7, но предложенное в этом стандарте решение не обеспечивало превращение результата лучевого исследования в мультимедийный документ. Поэтому разработчики стандарта DICOM предприняли собственную попытку стандартизовать текстовую часть результата лучевого исследования. Остановимся на этой важной задаче подробнее.

Способы придания данным структуры, необходимой для последующей компьютерной обработки, существенно зависят от технологии их ввода в компьютер. Для ввода текстовой части результатов исследований используются две основные технологии, а именно, диктофонный ввод и непосредственный ввод. В первом случае врач-диагност диктует текст, который затем вводится оператором и передается врачу на подпись в бумажном или электронном виде. Во втором случае врач-диагност сам вводит текст в компьютер.

Технология диктофонного ввода значительно упрощает врачам оформление результатов исследований. Например, результаты гистологических исследований можно диктовать, не отрываясь от микроскопа. Однако сама по себе эта технология не обеспечивает возможности придания результатам структуры, пригодной для эффективной компьютерной обработки. Поэтому после ввода текста, как правило, нужно выполнить дополнительные действия, например, присвоить отдельным компонентам текста коды из определенных медицинских классификаций. Эти коды впоследствии могут использоваться в процедурах выборки данных и системах обеспечения принятия медицинских решений.

Кодирование является очень важным элементом технологии, оно позволяет избежать неоднозначности трактовки результатов исследований и значительно упростить последующую компьютерную обработку. Присваивание кодов может выполняться вручную, полуавтоматически или даже автоматически с помощью специальных и очень сложных программ семантической обработки медицинских текстов.

При непосредственном вводе текста результата исследования компьютерная программа может вести врача-диагноста по определенной схеме, тем самым придавая результату необходимую структуру. Но непосредственный ввод не всегда удобен и более трудоемок для врачей, нежели диктофонный ввод. Существует много способов снижения трудоемкости непосредственного ввода результатов исследований, которые попутно обеспечивают их структурирование. Достаточно типичен следующий сценарий: врач-диагност формирует результат исследования из заранее заготовленных шаблонов (фреймов), в пустые гнезда (слоты) которых вводятся числовые данные, например размеры или площадь выявленного образования, коды (которые можно выбирать из меню), ссылки на изображения, видеозапись и звукозапись. На всякий случай имеется вырожденный шаблон, целиком состоящий из гнезда, в которое можно ввести произвольный текст. Этот сценарий имеет следующие достоинства:
- поскольку текст результата исследования формируется из шаблонов, то тем самым контролируется используемая терминология. При наличии семантических связей между шаблонами можно упростить процедуру выбора очередного шаблона и следить за полнотой результата исследования;
- библиотеку шаблонов можно формировать постепенно. Вначале можно пользоваться только вырожденным шаблоном, а затем добавлять в библиотеку наиболее распространенные заключения и фрагменты описаний, а также меню перечисляемых значений;
- в гнезда шаблонов можно вставлять не только числа и выбор из меню, но также и ссылки на растровые изображения или их элементы, графики и кривые, аудио- и видеозаписи, что и позволяет превратить результат исследования в мультимедийный документ.

Однако у этого сценария имеются свои подводные камни:
- если библиотеки шаблонов и меню являются приватными и обновляются независимо друг от друга, то это приводит к невозможности автоматизированного сопоставления результатов исследований, оформленных с помощью одной и той же программы в разных учреждениях или даже на разных рабочих местах в одном и том же учреждении;
- централизованные библиотеки содержат гораздо больше шаблонов и меню, чем приватные. Действительно, словарь отдельного человека обычно ограничен несколькими сотнями слов. Такой словарь просто реализовать и модифицировать. Но если мы хотим объединить словари сотен и тысяч людей, то счет пойдет уже на десятки тысяч слов. При этом любое изменение централизованной библиотеки надо доводить до большого числа пользователей, что как в организационном, так и в техническом отношении представляет собой достаточно сложную задачу.

Кодирование результата исследования при непосредственном вводе обеспечивается неявным образом и не требует дополнительных трудозатрат от пользователей. Каждому элементу меню отвечает свой код, который используется при сохранении введенного результата в базе данных, но в явном виде в экранной форме не фигурирует и врачом не набирается. Смысловые группировки кодов берутся из структуры шаблонов.

Для решения задачи структурирования результатов лучевых исследований в 1996 году был разработан так называемый микроглоссарий SNOMED-DICOM (SDM), представляющий собой централизованную библиотеку шаблонов и меню, которая может использоваться как при кодировании диктофонного ввода, так и при непосредственном вводе текстовой части результатов. Он был разработан под эгидой Американского института патологоанатомов CAP (College of American Pathologists) на основе номенклатуры SNOMED International. Его основными элементами являются шаблоны (templates) и контекст кодируемых значений (context groups), то есть меню значений, допустимых в данном контексте. Сами значения берутся или из номенклатуры SNOMED, или из некоторых других медицинских классификаций и стандартов (например, HL7 или LOINC). Поэтому микроглоссарий SDM является так называемым отображающим ресурсом (mapping resource). В той версии микроглоссария SDM, которую до недавнего времени можно было получить на странице http://www.snomed.org/sdm/sdm.htm, выделялось 15 шаблонов и 705 классов контекста.

Поясним назначение этих элементов микроглоссария на примере шаблона 004, задающего структуру описания исследуемого образца биоматериала в виде ряда свойств (табл. 5). Эти свойства можно рассматривать как графы лабораторного журнала, часть которых заполняется обязательно, а часть - по мере необходимости. Для некоторых свойств указан идентификатор класса контекста (cid). Например, свойство 12, "Вид биоматериала", имеет класс контекста 37. Это означает, что данное свойство берется из меню возможных значений, которому в микроглоссарии SDM присвоен идентификатор контекста 37 (табл. 6).

Классы контекста, т. е. меню возможных значений, могут адресоваться самостоятельно, без предварительной ссылки на шаблоны. К примеру, анатомическая локализация исследуемого объекта имеет идентификатор контекста 1 и может использоваться сама по себе или, скажем, в составе шаблона 016, "Морфология биоматериала".

Хотя указанный подход производит впечатление достаточно хорошо проработанного, в настоящее время альянс DICOM-SNOMED фактически оказался свернутым, и задача стандартизации структуры текстовой части результата лучевого исследования все еще не получила удовлетворительного решения в стандарте DICOM. Произошло это, скорее всего, потому, что разрабатываемый язык шаблонов и меню оказался узкоспециальным и не смог конкурировать с универсальным языком XML (eXtensible Markup Language - расширяемый язык разметки), ставшим за последние несколько лет эпицентром внимания всех, кому приходится решать задачу структурирования документов. Он появился уже после начала работы по интеграции стандартов DICOM и SNOMED, поэтому какое-то время эта работа продолжалась по инерции. Когда же в 1999 году было решено активнее использовать язык XML, оказалось, что разработчики стандарта DICOM существенно отстали от тех, кто не был обременен подобной ношей и изначально сориентировался на использование этого языка. Наибольшего успеха к тому времени достигли авторы стандарта HL7, которые почти с самого начала разработки архитектуры истории болезни PRA (Patient Record Architecture) решили использовать этот язык. Поэтому в 2000 году разработчики стандарта DICOM решили скооперироваться с комитетом HL7, что служит примером интеграции стандартов одного уровня, то есть горизонтальной интеграции. Остановимся на этом подробнее.

Таблица 5. Состав шаблона 4 микроглоссария SDM - исследуемый образец биоматериала

Свойство

Название

Определение

Контекст

Примеры

1

Атрибуты взятия биоматериала

Административная идентификация взятия, привязка взятой ткани или жидкости к источнику (пациенту) и процедуре взятия

 

Регистрационный номер биоматериала, медицинский работник, выполнивший процедуру взятия

2

Дата взятия

Дата завершения процедуры взятия биоматериала

 

 

3

Время взятия

Время завершения процедуры взятия биоматериала

 

 

4

Взявший врач

Врач, выполнивший процедуру взятия

 

 

5

Описание биоматериала

Описание, составленное взявшим врачом

 

 

6

Идентификатор биоматериала

 

 

 

7

Идентификатор
биоматериала-источника

Идентификатор биоматериала, послужившего источником данного биоматериала

 

Идентификатор блока, от которого был сделан срез

8

Процедура взятия биоматериала

35

 

9

Код процедуры обработки биоматериала

36

 

10

Предосторожности при обработке биоматериала

214

 

11

Специальные требования к обработке

215

 

12

Вид биоматериала

37

Блок, срез

13

Фиксирующий агент

38

Этиловый спирт

14

Краситель биоматериала

39

 

15

Ингибитор красителя

40

 

16

Процедура экстракции биоматериала

41

 

17

Процедура гибридизации биоматериала

42

 

18

Процедура усиления гибридизации

43

 

19

Маркировка среза

 

1, 2, 3

20

Идентификатор среза

 

13211-2

21

Толщина среза

 

 

22

Толщина покровного стекла

 

 

 

Горизонтальная интеграция стандартов.
Архитектура PRA как основа интеграции стандартов HL7 и DICOM

Архитектура PRA описывает структуру аутентифицированных окончательных записей в электронную историю болезни пациента (документов PRA). Документы PRA составлены на языке XML и являются "человеко-читаемыми" и "машинно-обрабатываемыми". Первое означает, что документы PRA могут быть прочитаны пользователем с помощью широко распространенных браузеров языка XML и что для составления документов используется стандартный язык стилей оформления.

Второе означает, что документы PRA могут обрабатываться компьютером на следующих уровнях формализованной семантики:
- кодированный заголовок документа (уровень 1);
- кодированная структура документа (уровень 2);
- кодированное содержание документа (уровень 3).

Таблица 6. Кодируемые значения контекста 37, "Вид биоматериала"

Код

Значение

Y-X0688

Срез

Y-X0689

Блок

Y-X0690

Вскрытый труп

Y-X0691

Труп

Y-X0692

Культура

Y-X0693

Хроматограмма

Y-X0694

Проба

 

Документы PRA слишком велики, чтобы их можно было привести полностью, поэтому ограничимся фрагментом, взятым из презентации PRA и наглядно показывающим, как можно трактовать принципы "человеко-читаемый" и "машинно-обрабатываемый": если не обращать внимания на те части сообщения, которые набраны жирным шрифтом, то этот документ вполне может быть понят человеком. Для компьютерной программы, напротив, информативными будут как раз те части, что набраны жирным шрифтом.

 
<body>
<section>
<section.title>ФИЗИКАЛЬНОЕ ИССЛЕДОВАНИЕ ПРИ ГОСПИТАЛИЗАЦИИ </section.title> 
<section>
<section.title>ОБЩИЙ ОСМОТР</section.title> 
<paragraph>Артериальное давление 170/88, пульс 80, ритмичный <healthcare.code identifier=<9279-1> 
preferred.name = <ЧACTOTA ДЫХАНИЯ> name.of.coding.system=<LN>
local.coding.system=:<N>>Частота дыхания 
</healthcare.code>18. Beс 99 кг </paragraph> 
</section>
<section>
<section.title>OCMOTP ГОЛОВЫ</section.title> 
<paragraph>Брахицефал. Двусторонние <healthcare.code 
identifier=<F-F5480> preferred.name=<шум сонной артерии> name.of.coding.system=<SN3>
local, coding. system=<N>> шумы сонной артерии 
</healthcare.code>Яремные вены не расширены,
лимфаденопатий нет. </paragraph>
</section>
</section>
</body>
 

Архитектура PRA предполагает три уровня "машинного" понимания передаваемых документов. Первый, самый ограниченный, предполагает, что компьютерная программа способна понимать только разметку медицинских документов на отдельные разделы. На втором уровне компьютерная программа должна понимать назначение каждого раздела, а на третьем - содержание каждого раздела. Архитектура PRA организована таким образом, что удовлетворяющие ей программы успешно обработают документы любого уровня, каждая на своем уровне понимания.

В документы PRA можно вставлять ссылки на изображения и другие не текстовые объекты. Существеннее всего то, что для чтения документов PRA пользователь может применять не специализированные медицинские программы, а универсальные программы чтения языка XML (браузеры XML), что значительно облегчает разработку информационных систем и обучение пользователей, и к тому же ощутимо дешевле.

Все эти свойства документов PRA позволили разработчикам стандарта DICOM принять решение об интеграции той части своего стандарта, которая описывает структурированные результаты лучевых исследований, с архитектурой PRA и справочной информационной моделью предметной области, разрабатываемой комитетом HL7. Первый вариант интеграции предусматривает такую трансляцию DlCOM-объектов на язык XML, которая бы соответствовала принципам архитектуры PRA.

Проект SNOMED СТ

Среди всех совместных проектов международной кооперации разработчиков стандартов медицинской терминологии наиболее масштабным является недавно начатая работа Американского института патологоанатомов (САР) и Национальной службы здравоохранения Великобритании (NHS) по созданию объединенной системы медицинской терминологии SNOMED СТ. Предыдущий опыт этих организаций по разработке номенклатуры SNOMED (CAP) и системы клинических терминов СТ version 3 (NHS) показал, что существуют естественные пределы прироста базы данных медицинских терминов, который может обеспечить один коллектив разработчиков, - не более 5-10 тысяч терминов в год. А так как системы SNOMED и СТ развивались, так сказать, навстречу друг другу (истоком номенклатуры SNOMED является система кодирования патоморфологических диагнозов SNOP, а системы СТ - клинические коды Рида, ориентированные на систему первичной медицинской помощи), то пересечение этих терминологических систем оказалось не очень значительным (30-40 %). Таким образом, обе системы существенным образом дополняют друг друга.

Новая система SNOMED СТ проектируется таким образом, чтобы ее можно было сделать многоязычной, она предназначена в первую очередь для использования в клинических информационных системах и базах медицинских знаний.

Заключение

Из приведенных выше примеров интеграции стандартов можно сделать несколько важных выводов. Во-первых, начинать собственную, оригинальную разработку стандарта медицинской терминологии или стандарта передачи записей в электронную историю болезни практически бессмысленно: она займет слишком много времени и к ней нельзя будет подключить наиболее авторитетных зарубежных коллег, которые уже заняты в названных выше проектах. Следовательно, по своей полноте и качеству оригинальная разработка будет существенно отставать от описанных выше стандартов. Во-вторых, принятие оригинального стандарта затруднит обмен медицинской информацией между российскими и зарубежными медицинскими информационными системами. Поэтому наилучшим решением была бы адаптация стандартов HL7, DICOM и SNOMED СТ к российским условиям. Противники этого подхода в качестве основного возражения выдвигают наличие существенных различий в практике оказания медицинской помощи и ведения медицинской документации. Хотя такие различия действительно имеют место, однако реальный опыт применения стандарта HL7 при разработке информационных систем Центральной клинической больницы Медицинского центра Управления делами Президента РФ показал, что они не настолько существенны, чтобы адаптация стандарта потребовала слишком больших расширений.

Разработчикам можно рекомендовать обратить особое внимание на стандарты HL7, DICOM и SNOMED и использовать их в создаваемых медицинских информационных системах, не дожидаясь официального утверждения. В конце концов, из этих стандартов только HL7 получил официальный статус национального, да и то после 10 лет развития, а остальные до сих пор являются стандартами де-факто.

Не менее важно следить за дальнейшим развитием стандартизации медицинской информатики и использовать в новых разработках положения других европейских и международных стандартов, кроме названных выше. В рамках Всемирной организации по стандартизации (ISO) в 1998 году образован комитет (TC 215). Россия явилась одним из инициаторов создания данного комитета и на правах активного участника (P-member) имеет возможность включения своих представителей в рабочие группы и участия в голосовании по текущим вопросам. Комитет ПК55 "Информационные технологии в охране здоровья" уполномочен Госстандартом РФ представлять нашу страну в данном комитете ISO. Другие сведения о подкомитете 55 см. на странице http://www.spmu.runnet.ru/mirror/.

Рубрики || Работа || Услуги || Поиск || Архив || Дни рождения
О "КИ" || График выхода || Карта сайта || Подписка

Рассылка анонсов газеты по электронной почте

Главная страница

Сайт газеты "Компьютер-Информ" является зарегистрированным электронным СМИ.
Свидетельство Эл 77-4461 от 2 апреля 2001 г.
Перепечатка материалов без письменного согласия редакции запрещена.
При использовании материалов газеты в Интернет гиперссылка обязательна.

Телефон редакции (812) 718-6666, 718-6555.
Адрес: 196084, СПб, ул.Заставская, д.23, БЦ "Авиатор", 3-й этаж, офис 307
e-mail: editor@ci.ru
Для пресс-релизов и новостей news@ci.ru