CC BY
91
■■г.г
■■■■
РЧН
Стандартизация
1 и информационные
технологии
>
А.И. ГАЙДУКОВ,
к.ф.-м.н., фирма «1C», г. Москва, Россия, gaya@1c.ru
А.С. БАЛЮК,
к.ф.-м.н., доцент кафедры математической информатики ФГБОУ ВПО «ВСГАО», г. Иркутск, Россия
С.Ю. РЕЙМЕРОВ,
аспирант ФГБОУ ВПО «ВСГАО», г. Иркутск, Россия
ПОДХОД К ФОРМИРОВАНИЮ, ХРАНЕНИЮ И ОБРАБОТКЕ ЧАСТИЧНО
СТРУКТУРИРОВАННЫХ МЕДИЦИНСКИХ ДОКУМЕНТОВ В ФОРМАТЕ ISO/HL7 27932:2009 (HL7 CDA R2) В МЕДИЦИНСКИХ ИНФОРМАЦИОННЫХ СИСТЕМАХ
УДК 004.4:004.9
Гайдуков А.И., Балюк А.С., Геймеров С.Ю. Подход к формированию, хранению и обработке частично структурированных медицинских документов в ФОРМАТЕ ISO/HL7 27932:2009 (HL7 CDA R2) в медицинских информационных системах (фирма «1C», г. Москва, Россия; ФГБОУ ВПО «ВСГАО», г. Иркутск, Россия) Аннотация: В работе рассматриваются подходы к формированию, хранению и обработке, подписанию электронной подписью медицинских документов, соответствующих формату HL7 CDA R2, в информационных базах медицинских информационных систем уровня медицинской организации. В качестве примера рассматриваются методы реализации описанных подходов в программных продуктах «1С:Медицина. Поликлиника» и «1С:Медици-на. Больница».
Ключевые слова: медицинская информационная система, электронные медицинские карты, электронный медицинский документ, электронная подпись, HL7 CDA R2, ISO/HL7 27932:2009, ЮПредприятие 8.
UDC 004.4:004.9
Gaidukov A., Balyuk A., Reymerov S. Approach to forming, storage and processing partly structured medical documents in the format of ISO/HL7 27932:2009 (HL7 CDA R2) in medical informational systems
(1C COMPANY, Moscow, Russia; East-Siberian Academy of Education, Irkutsk, Russia)
Annotation: In this paper we consider approaches to creating, storing, and processing electronic medical records in healthcare information systems. Electronic medical records are suppose to confirm HL7 CDA R2 standard. The healthcare information systems «1C:Medicine. Clinic» and «1C:Medicine. Hospital» are considered as examples, implementing such approaches.
Keywords: Clinical document, Electronic medical record, Digital signature, HL7 CDA R2, ISO/HL7 27932:2009, 1C:Enterprise 8.
Введение
В последние годы стандарты информационного взаимодействия, разработанные некоммерческой организацией HL7, приобретают популярность среди разработчиков программного обеспечения и государственных органов, регулирующих вопросы стандартизации в области медицинской информатики. Один из наиболее востребованных стандартов — ISO/HL7 27932:2009 Data Exchange Standards — HL7 Clinical
© А.И. Гайдуков, А.С. Балюк, С.Ю. Реймеров, 2012 г.
Б
Стандартизация
www.idmz.ru
РЧН
Document Architecture, Release 2 [1]. Сокращенное название — HL7 CDA R2.
Обязательное требование стандарта ISO/HL7 27932:2009 — медицинский документ должен восприниматься человеком (быть человекочитаемым). При этом тело документа может содержать машинно-обрабатыва-емую часть. Для обеспечения возможности машинной обработки персональных и медицинских данных используются отраслевые классификаторы, например, библиотека медицинских терминов SNOMED CT, классификатор LOINC, идентификаторов объектов (документов, пациентов, медицинских работников, организаций и подразделений и т.д.). При этом информация представляется как в виде структурированных записей с использованием языка разметки XML, так и в виде любого MIME-закодированного объекта, включая отсканированный образ документа, текстовый или табличный документ в одном из распространенных форматов, изображение, звук или иной мультимедийный объект.
Стандартом ISO/HL7 27932:2009 предусмотрено формирование медицинских документов на 3-х уровнях совместимости со стандартом:
1. Уровень заголовка. Заголовок медицинского документа записывается в структурированном виде, тело медицинского документа записывается в свободном виде в элементе NonXMLBody. Примером документа является отсканированный документ и заголовок, содержащий структурированные данные.
2. Уровень структуры. Заголовок медицинского документа записывается в структурированном виде, тело медицинского документа структурируется разделами и записывается с помощью языка разметки XML в элементе StructuredBody.
3. Уровень данных. Документ должен быть совместим на структурном уровне, а данные медицинского документа должны быть закодированы в элементах StructuredBody/com-ponent/section/entry/observation с помощью классификаторов.
2012, N'5
На рис. 1 и 2 приведены примеры одной и той же части медицинского документа, записанного на 2 и 3-м уровнях совместимости. Из примеров видно, что отличие между уровнями заключается в наличии элементов compo-nent/section/entry в медицинском документе 3-го уровня. Именно в этом элементе записывается машино-обрабатываемая часть.
Стандартом ISO/HL7 27932:2009 предусматривается только синтаксическая совместимость при обмене электронными медицинскими документами. Для обеспечения совместимости на семантическом уровне стандартом ISO/HL7 27932:2009 рекомендовано использовать следующую нормативно-справочную информацию:
1. Классификатор LOINC. Классификатор ведется организацией Regenstrief Institute, США.
2. Кл ассификаторы стандарта HL7 v3. Классификаторы ведутся международной организацией HL7.
3. Система классификации медицинских терминов SNOMED CT. Система классификации ведется международной организацией IHTSDO.
Важно отметить, что стандарт ISO/HL7 27932:2009 дает избыточный набор синтаксических конструкций для записи данных. Это обусловливает высокую степень гибкости стандарта, но в то же время делает стандарт в чистом виде малопригодным для использования в качестве стандарта информационного обмена.
В качестве стандартов обмена используют профили. Профиль состоит из:
1. Набора синтаксических правил формирования конкретных медицинских документов.
2. Списка используемых классификаторов и правил их использования.
В качестве примера набора таких профилей можно привести профили организации IHE [5].
Шаблоны медицинских документов
Формирование медицинских документов 2-го уровня возможно с помощью текстовых
■ ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■ ■ ■■ ■■ ■ ■ ■ ■ ■ ■ ■■ ■■■ ■ ■ ■ ■■ ■■ ■■■ ■ ■ ■■ М 5 ■ ■■■ ■ ■
яя^
ВрЗЧ E3SS Стандартизация
^ и информационные
технологии
<component>
<section>
<code code=«29299-5» codeSystem=«2.16.840.1.113883.6.1»
codeSystemName=«LOINC»/>
<title>Жалобы</title>
<text>Высыпание.</text>
</section>
</component>
Рис. 1. Фрагмент медицинского документа 2-го уровня совместимости
<component>
<section>
<code code=«29299-5» codeSystem=«2.16.840.1.113883.6.1»
codeSystemName=«LOINC»/>
<title>Жалобы</title>
<text>Высыпание.</text>
<entry>
<observation classCode=«OBS» moodCode=«EVN»>
<id root=«8cfebf20-e8de-11da-8ad9-0800200c9a66»/>
<code code=«271807003» codeSystem=«2.16.840.1.113883.6.96»
codeSystemName=«SNOMED CT» displayName=«Высыпание»/> <statusCode code=«completed»/>
<effectiveTime>
<low value=«20000406»/>
</effectiveTime>
</observation>
</entry>
</section>
</component>
Рис. 2. Фрагмент медицинского документа 3-го уровня совместимости
редакторов как универсального способа формирования медицинских документов 2-го уровня. Для упрощения формирования документов можно использовать «текстовые заготовки», которые включают в себя наиболее употреби-мые предложения, фразы, слова и т.д.
В то время как формирование документов 3-го уровня невозможно без специализированных программных средств. Такие средства должны обеспечивать как минимум:
1. Сбор данных в объеме, необходимом для формирования синтаксически корректной конструкции, соответствующей медицинскому документу некоторого профиля.
2. Кодирование медицинских данных с помощью классификаторов, принятых к использованию в профиле.
Также средства могут обеспечивать следующие дополнительные функции:
1. Проверка корректности кодирования медицинских данных.
2. Проверка синтаксиса и орфографии человекочитаемой части медицинского документа.
3. Получение сведений о состоянии здоровья пациента, для которого формируется медицинский документ, из других медицинских документов с целью использовать эти сведения для информирования врача.
Для формирования медицинских документов 3-го уровня совместимости в данной работе предлагается использование шаблонов медицинских документов. Этот подход использован в подсистеме «Электронные медицинские
1 8 ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ ■
Стандартизация
www.idmz.ru
РЧВВ
2012, N'5
Типы шаблонов медицинских документов
Таблица 1
Тип ШМД Поддерживаемые уровни совместимости CDA-документов Требуемый уровень технической квалификации разработчика ШМД
ШМД в виде обработок и внешних
обработок платформы «1С:Предприятие 8» 1, 2, 3 Средний
ШМД в виде HTML документов 1, 2, 3 Средний
ШМД в виде табличного документа платформы «1С:Предприятие 8» 2 Начальный
карты» программных продуктов «ЮМедицина. Поликлиника» и «ЮМедицина. Больница».
Шаблон медицинского документа (ШМД) — программный модуль с экранной формой, который позволяет медицинскому работнику формировать и редактировать медицинские документы, при этом шаблон может выполнять сервисные функции: оказывать интеллектуальную поддержку врачу, следить за правильностью формирования медицинского документа, проверять орфографию и т.д. В качестве входных и выходных данных ШМД выступают XML файлы, синтаксис которых приближен к формату стандарта ISO/HL7 27932:2009.
ШМД может формировать медицинские документы на основании интерактивного взаимодействия пользователя с некоторой векторной схемой (рисунком) или текстовым интеллектуальным шаблоном. Для формирования электронных медицинских карт в медицинской организации уровня городской больницы или центральной районной больницы необходимо несколько сотен шаблонов. ШМД должны максимально ускорять процесс формирования медицинских документов, поэтому ШМД должны быть интуитивно понятны медицинским работникам.
Так как ШМД используются для формирования электронных медицинских карт, то использовать шаблоны будет значительная часть медицинского персонала медицинской организации. ШМД часто требуют «тонкой» настройки под предпочтения конкретного
пользователя, что выдвигает особые требования к удобству и скорости их формирования и изменения. Формирование новых ШМД или корректировка существующих не должна требовать значительных трудозатрат и предъявлять высокие требования к квалификации персонала, который будет их выполнять.
Шаблон медицинского документа может содержать следующие объекты:
1. Обязательные для заполнения поля, включая формализованные поля (с использованием классификаторов).
2. Формализованные поля, которые не являются обязательными для заполнения.
3. По заполненным формализованным полям подставлять значения классификаторов, которые будут использоваться в дальнейшей машинной обработке.
4. Поля свободного ввода.
5. Графические редакторы (например, на основе HTML5), которые могут использоваться как формализованные модели медицинского документа или его частей.
Каждой медицинской услуге может соответствовать один или несколько ШМД. Перед началом формирования медицинского документа медицинский работник может выбрать тот ШМД, который наиболее подходит для конкретного случая.
Программные продукты «1 С:Медицина. Поликлиника» и «1 С:Медицина. Больница» поддерживают несколько типов ШМД (табл. 1).
■ ■ ■ ■ ■ ■■ ■ ■ ■ ■ ■■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■■ ■ ■ ■ ■ ■ ■ ■ ■ ■■ ■ ■ ■ ■ ш ■ ■ ■■■ ■ ■
РЧН
Стандартизация
1 и информационные
технологии
Рис. 3. Шаблон медицинского документа «Зубная карта», разработанный на базе HTML5
Для создания каждого из типов ШМД используются различные технологии. Выбор технологии создания ШМД зависит от сложности структуры, поведения ШМД и уровня технической квалификации разработчика ШМД.
На рис. 3 приведен пример пользовательского интерфейса ШМД в виде HTML документа со встроенными элементами SVG.
Структура формируемого медицинского документа целиком зависит от ШМД. Перед сохранением медицинского документа в информационной базе производится проверка на синтаксическую корректность сформированного XML файла. Схемы потоков данных при формировании, редактировании и сохранении медицинских документов приведены на рис. 4 и 5.
Некоторые ШМД логически состоят из нескольких частей. В качестве примера можно привести ШМД для формирования
протокола эзофагогастродуоденоскопии (ЭГДС). Помимо текстового описания исследования в протоколе может присутствовать схема желудка, на которой врач-эндоскопист оставляет заметки и записи. В ШМД ЭГДС можно выделить две составные части:
• текстовое описание;
• графическая схема.
Для формирования ШМД, состоящих из нескольких частей предлагается использовать многокомпонентные ШМД — ШМД которые содержат в себе другие ШМД (вложенные ШМД). Созданные вложенными ШМД медицинские документы являются составными частями медицинского документа многокомпонентного ШМД. На рисунках 6-8 показан пример последовательности использования многокомпонентного ШМД «Протокол ЭГДС», состоящего из 2 вложенных ШМД.
10- ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ ■
Стандартизация
www.idmz.ru
РЧН
2012, N'5
Шаблон
медицинского
документа
Загрузка сохраненного ранее медицинского документа (для случая редактирования документа)
Информация о медицинской услуге, пациенте, исполнителях
Медицинские документы в формате, основанном на CDA
ШМД, хранящиеся в информационной базе
Визуализаторы
Информационная база
Рис. 4. Формирование нового медицинского документа или редактирование существующего
Шаблон
медицинского
документа
ПрОЕ XML до на синтак коррек ерка сумента .сическую стность
* Г
Информация о медицинской услуге, пациенте, исполнителях Медицинские документы в формате, основанном на CDA ШМД, хранящиеся в информационной базе Визуализаторы
S Информационная база j
Рис. 5. Сохранение медицинского документа
■ ■ ■ ■ ■ ■■ ■ ■ ■ ■ ■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ 11 ■
■■г.г
■■■■
РЧН
Стандартизация
1 и информационные
технологии
Складки продольные до 0,4 см. Перистальтика правильная по всем кривизнам.
Слизистая умеренно гиперемирована во всех отделах, больше в теле и антруме.
Пилорус округлый, зияет, не смыкается. Луковица ДПК не деформирована, просвет свободен.
Слизистая луковицы ДПК розовая, с небольшой лимфофоликулярной гиперплазией. Нисходящая ветвь ДПК не изменена. Слизистая ее розовая. БДС не визуализирован. Взята биопсия со слизистой тела и антрального отделов желудка.
Заключение
Поверхностный гастрит. Легкая лимфофоликулярная гиперплазия луковицы ДПК. pH желудочного содержимого - 2,35.
Локальный статус: Верхняя часть желудка.
Рис. 6. Фрагмент ШМД для формирования текстового описания протокола ЭГДС (Шаг 1)
Рис. 7. Формирование графической схемы (Шаг 2)
Язвенная болезнь желудка? Пищевод свободно проходим, стенки ровные, перистальтика розовая, блестящая. Кардиальный жом на 38 см. от резцов перистальтирует. Смыкается Желудок обычных размеров, хорошо расправляется воздухом, в просвете небольшое продольные до 0,4 см. Перистальтика правильная по всем кривизнам. Слизистая умер в теле и антруме. Пилорус огруглый, зияет, не смыкается. Луковица ДПК не деформи ДПК розовая, с небольшой лимфофоликулярной гиперплазией. Нисходящая ветвь ДПК визуализирован. Взята биопсия, сделан мазок-отпечаток со слизистой теля и антрально
Заключение
Поверхностный гастрит. Легкая лимфофоликулярная гиперплазия луковицы ДПК. pH часть желудка
Подпись врача:
1. сделан мазок отпечаток
Рис. 8. Фрагмент протокола ЭГДС (Шаг 3)
1 12 ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ ■
Стандартизация
www.idmz.ru
РЧН
Для отображения данных медицинских документов (просмотр врачом документа, печать документа) стандарт ISO/HL7 27932:2009 подразумевает использование XSLT — языка трансформации XML документов. В программных продуктах «ЮМедицина. Поликлиника» и «1 С:Медицина. Больница» для выполнения XSLT трансформации из XML в HTML используется механизм визуализато-ров. На рис. 8 представлен протокол ЭГДС, подготовленный к печати с помощью визуали-затора.
Хранение медицинских документов в информационной базе
Для хранения сложно структурированных данных в реляционных базах данных, запись которых основана на XML, можно выделить два основных подхода:
1. Хранение данных в реляционных таблицах, построение таблиц соответствует описанию структуры XML документов.
2. Хра нение данных в исходном виде (в виде XML), сохранение части медицинских документов в реляционных таблицах.
Многие программные продукты для построения медицинских информационных систем для хранения медицинских данных используют первый подход, так как его реализация не сложна — ISO/HL7 27932:2009 имеет реляционную структуру. Из недостатков этого подхода можно выделить следующие:
1. Высокие накладные расходы (место на носителях информации) на хранение данных (CDA-документов). Причина в том, что реляционные таблицы хранят много избыточной информации.
2. Сложность применения электронной подписи (ЭП) к данным. Так как ISO/HL7 21731:2006 служит для информационного обмена медицинскими документами, в которых содержатся сведения о состоянии здоровья пациентов, то важно, чтобы существовал механизм, позволяющий проверять подлин-
2012, N'5
ность данных на всех этапах жизненного цикла медицинского документа. Исходные данные поступают в виде XML-файлов (в том числе и от внешних информационных систем) и при хранении данных в реляционных таблицах файл разбирается по составным частям. А ЭП применяется ко всему XML-файлу. При сборке файла из реляционных таблиц сложно гарантировать посимвольную идентичность оригиналу.
Второй метод хранения не имеет описанных выше недостатков — исходный XML файл сохраняется в первозданном виде (включая ЭП при ее наличии), а в реляционные таблицы записываются только самые необходимые данные. В качестве примера реализации метода можно привести проект IBM RIMon — открытый проект IBM Haifa Research, реализованный на программном продукте IBM DB2 pureXML [3].
В подсистеме «Электронные медицинские карты» программных продуктов «ЮМедицина. Поликлиника» и «ЮМедицина. Больница» также используется второй из описанных подходов (рис. 9).
1. Медицинский документ поступает из ШМД или внешнего источника в виде XML файла. Медицинский документ может быть подписан ЭП.
2. Медицинский документ сохраняется в информационной базе в неизменном виде.
3. Сохраняется ЭП документа при ее наличии.
4. При сохранении медицинского документа вызываются обработчики подписок на события, которые из сохраненного XML файла выбирают сведения и сохраняют их в реляционном виде в объектах конфигурации.
Применение электронной подписи к медицинским документам
В стандарте ISO/HL7 27932:2009 указано, что электронная цифровая подпись не включается в CDA-документ, есть только элемент,
■ ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ 13 ■
яя^
ВрЗЧ E3SS Стандартизация
^ и информационные
технологии
Пополнение 1
Регистры
Справочники
Рис. 9. Схема сохранения медицинских документов в виде XML с сохранением дополнительных данных в реляционных таблицах
позволяющий сказать, была ли подпись наложена на документ или нет (signatureCode).
Конкретный механизм электронной цифровой подписи не включен в спецификацию и остается на усмотрение разработчиков.
Спецификации W3C XMLDSIG [4] описывает формат XML, который сохраняет ЭП. Спецификация предусматривает несколько вариантов сохранения ЭП:
• Detached — подписываемое содержимое и ЭП находятся в разных файлах XML;
• Enveloped — ЭП включена в подписываемый XML и распространяется только на содержимое XML (то есть не распространяется на ту часть XML, где находится ЭП);
• Enveloping — ЭП включена в подписываемый XML и распространяется на весь XML.
Необходимо отметить, что применение вариантов Enveloped и Enveloping формирует XML, который формально не соответствует стандарту ISO/HL7 27932:2009, но тривиальными XSLT-преобразованиями из этого XML можно получить корректный с точки зрения ISO/HL7 27932:2009 XML файл.
В программных продуктах линейки «1С:Ме-дицина» для передачи медицинских документов при информационном обмене между программными продуктам линейки используется ориентация на вариант Detached. В качестве примера можно привести организацию обмена данными между решениями «1С:Медицина. Поликлиника» и «1 С:Медицина. Клиническая лаборатория». Информационный обмен между этими двумя программными продуктами
14 ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ ■
Стандартизация
www.idmz.ru
РЧН
реализован на базе стандарта ISO/HL7 21731:2006 Health informatics — HL7 version 3 — Reference information model — Release 1 (HL7 v3) [2].
Согласно рекомендациям стандарта ISO/HL7 27932:2009, медицинский документ записывается в элемент text тела любого HL7 v3 сообщения. Так, сведения о результатах лабораторных исследований можно передать в сообщении POLB_IN224100UV01 (Процесс выполнения лабораторного исследования завершен, не ожидается изменений статуса исследования, за исключением сообщения о внесении изменений в протоколе исследования). Документ преобразуется в строку с кодировкой BASE64 (RFC 2557). Для передачи медицинских документов, которые
2012, N'5
не привязаны к событиям, предусмотренными HL7 v3 можно использовать специальное сообщение RCMRJN000002UV02 (Передача медицинского документа).
Файлы, на которые ссылается медицинский документ (элементы linkHTML), записываются в этом же элементе text тела сообщения.
Для записи ЭП медицинского документа можно использовать описанную выше стратегию — записывать ЭП отдельным файлом в тело HL7 v3 сообщения, содержащего медицинский документ в формате стандарта ISO/HL7 27932:2009.
Работа выполнена при поддержке Министерства образования и науки РФ по государственному контракту № 07.5J4.JJ.405J от 13 октября 2011 г.
ЛИТЕРАТУРА
1. HL7 Clinical Document Architecture, Release 2. ISO/HL7 27932:2009 Data Exchange Standards.
2. HL7 version 3, Reference information model, Release 1. ISO/HL7 21731:2006
3. Use DB2 pureXML to implement a healthcare industry data solution. [Электронный ресурс]. Режим доступа: http://www.ibm.com/developerworks/data/library/techarticle /dm-1002purexmlqed/, свободный. Яз. англ.
4. XML Signature Syntax and Processing, W3C, 2008. [Электронный ресурс]. Режим доступа: http://www.w3.org/TR/xmldsig-core/, ограниченный. Яз. англ.
5. Integrating the Healthcare Enterprise. [Электронный ресурс]. Режим доступа: http://ihe.net, свободный. Яз. англ.
6. Емелин И.В. Компьютеризованная история болезни и системы классификации медицинских терминов//Компьютерные технологии в медицине. — 1997. — №2. — С. 12-15.
7. Столбов А.П, Кузнецов П.П. Некоторые проблемы сбора и компиляции данных для персональной электронной медицинской карты//Информационные технологии и общество 2010: Международный симпозиум, 1-8 октября 2010, Кемер. — Москва: Форсикон, 2010. —С. 42-43.
■ ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ 15 ■
