Настройка CDA «Протокол лабораторного исследования» в МИС: опыт внедрения

В этой статье я поделюсь практическим опытом настройки в медицинской информационной системе формирования структурированного электронного медицинского документа (СЭМД) «Протокол лабораторного исследования» в формате CDA (Release 2, уровень 3, редакция 4). Материал будет полезен специалистам, которые отвечают за интеграцию МИС с РЭМД и хотят избежать типичных ошибок при конфигурации типов действий, справочников и шаблонов печати.

1. Для чего нужен CDA «Протокол лабораторного исследования»

Этот документ предназначен для передачи в реестр электронных медицинских документов (РЭМД) результатов диагностических исследований биоматериала пациента, выполненных в клинико-диагностической лаборатории. В отличие от бумажных форм (224/у, 210/у, 228/у), CDA позволяет машиночитаемо кодировать каждый лабораторный показатель, оборудование, материал и исполнителей.

Требования к документу описываются в «Руководстве по реализации CDA (Release 2) уровень 3 Протокол лабораторного исследования. Редакция 4» (OID шаблона 1.2.643.5.1.13.2.7.5.1.7.9.4). Документ состоит из заголовка и структурированного тела, включающего три обязательные секции:

SPECIMENS – информация об исследованных материалах (биоматериал, контейнер, штрихкод, забор)
ANALYSERS – оборудование и расходные материалы
RESLAB – результаты проведённых исследований (с возможностью группировки, комментариев, заключения)

Опционально можно добавить секцию SERVICES с перечнем оказанных медицинских услуг.

2. Настройка типа действия в МИС

Первым делом мы создали отдельный тип действия для лабораторного исследования (в нашей системе он уже был, но мы доработали его под требования CDA). Главное, на что обратили внимание:

2.1. Идентификатор документа и счётчик

Для автоматической генерации уникального номера документа мы использовали счётчик с кодом CDA_ID. В свойствах типа действия настроили свойство «Идентификатор документа», указав этот счётчик. В XML-шаблоне это свойство подставляется в элемент <id root="...100.1.1.51" extension="..."/>.

2.2. Код для отчётов и вид услуги

У типа действия обязательно должен быть указан «Код для отчётов» – OtherDocuments. «Вид услуги» выставили в Прочее.

2.3. Идентификация типа действия по справочнику CDA

Для того чтобы РЭМД правильно распознал документ, мы добавили типу действия идентификацию по справочнику 1.2.643.2.69.1.1.1.195.Cda с идентификатором 75 (именно для протокола лабораторного исследования).

2.4. Секция CDA у свойств

Лабораторные показатели (результаты анализов) мы храним в свойствах действия. Чтобы эти свойства попали в машиночитаемую часть CDA, в их настройках мы указали параметр «Секция CDA» равный KODREZ. Это ключевой момент – именно по этому значению система понимает, что свойство является результатом лабораторного теста.

Также для удобства мы сделали эти свойства видимыми при выполнении работ (чек-бокс «Видимость при выполнении работ»), чтобы врачи лаборатории могли их заполнять.

3. Обязательные проверки в шаблоне печати

В основной шаблон печати (из которого формируется PDF и который вызывает генерацию XML) мы добавили две критически важные проверки.

Проверка идентификатора заявки – в нашей МИС идентификатор заявки хранится в action.takenTissueJournal.externalId. Без него документ не может быть однозначно идентифицирован в лабораторной информационной системе.

Проверка наличия диагноза в случае обслуживания – если лабораторное исследование выполняется в рамках обращения, обязательно должен быть заполнен диагноз (хотя бы один элемент event.diagnosises). Это требование валидации РЭМД.

Обе проверки прерывают формирование документа и показывают врачу понятное сообщение.

Также в шаблон печати нужно добавить вызов генерации XML:
{: addSupplement('xml', formatByTemplate('CDA_ProtocolLab', 'CDA')) }

Где CDA_ProtocolLab – имя шаблона, в котором хранится XML-код (у нас это отдельный шаблон с контекстом CDA).

4. Настройка справочников и идентификаций

Без правильной идентификации справочников CDA не пройдёт контроль в РЭМД. Мы проверили следующие моменты.

4.1. Организация (MDR308)

У нашей организации (и у каждого структурного подразделения, где выполняется исследование) должна быть настроена идентификация по справочнику с кодом MDR308. В XML это значение используется в корнях идентификаторов (например, root="1.2.643.5.1.13.13.12.2.77.8312"). Для структурного подразделения используется OID из справочника 1.2.643.5.1.13.13.99.2.114 (ФРМО. Справочник структурных подразделений).

4.2. Типы документов (ДУЛ пациента)

Для документа, удостоверяющего личность, мы настроили двойную идентификацию:

OID 1.2.643.5.1.13.13.99.2.48 – для кода типа документа
OID 1.2.643.5.1.13.13.99.2.48* – для наименования

Версию справочника используем последнюю (на момент настройки была 6.2, но лучше брать актуальную).

4.3. Должности

У всех исполнителей (врач КЛД, лаборант, заведующий лабораторией) должность должна быть идентифицирована по справочнику 1.2.643.5.1.13.13.11.1002. Мы проверили, что у каждого сотрудника в карточке заполнен код должности из этого справочника.

4.4. Идентификация типа действия по n3.medDocumentType.Cda

Помимо OID 1.2.643.2.69.1.1.1.195.Cda, сам тип действия должен иметь идентификацию по справочнику с кодом n3.medDocumentType.Cda. Это помогает системе классифицировать документ как CDA.

5. Формирование регионального идентификатора пациента (MPI)

Для выгрузки в РЭМД необходим глобальный идентификатор пациента. Мы реализовали его получение через сервис extendedmse. В шаблоне печати добавили строку:

{: from library.Utils import forceString}
{: clientGlobalIdNetrika = readUrl("http://"+forceString(dbServerName)+"/extendedmse/api?fromtemplate=1&clientid="+forceString(client.id), timeout=50)}

При этом нужно убедиться, что:

ревизия ИЭМК не ниже 28080;
в глобальных настройках есть запись с кодом ExtendedMseUrl (URL сервиса http://${dbServerName}/extendedmse/api);
в конфигурации ИЭМК прописаны gDefaultMpiUrl и gMpiToken, а также есть доступ к MPI.

Для Санкт-Петербурга (и некоторых других регионов) используется своя логика: если код КЛАДР начинается с 78, то идентификатор строится как {OID_MDR308[26:]}.17.1.{client.id}. Это мы тоже учли.

6. Заполнение секции SPECIMENS (исследованные материалы)

Секция SPECIMENS – одна из самых сложных, потому что в ней нужно детально описать взятие биоматериала. В нашей МИС данные о материале берутся из журнала забора (action.takenTissueJournal). Мы настроили автоматическое заполнение:

Тип материала (кровь венозная, моча и т.д.) – идентифицируем по справочнику 1.2.643.5.1.13.13.11.1081 (Федеральный справочник лабораторных материалов и образцов). Код материала подставляется в <code code="108" .../>.
Количество и единицы – заполняем в <quantity> с переводом единиц через справочник 1.2.643.5.1.13.13.11.1358.
Идентификатор образца (штрихкод) – передаём в <id root="...100.1.1.66" extension="..."/>.
Процедура взятия – код услуги из Номенклатуры медицинских услуг (OID 1.2.643.5.1.13.13.11.1070). Если точного кода нет, используем nullFlavor="OTH" с текстовым описанием в <originalText>.
Исполнитель забора – ссылаемся на сотрудника через его идентификатор в МИС (root ...100.1.1.70, extension – ID сотрудника).

Если материал после взятия подвергается дополнительной обработке (например, приготовление мазков), мы добавляем вложенную процедуру через <entryRelationship typeCode="REFR">.

7. Секция ANALYSERS (оборудование и расходные материалы)

Здесь мы описываем анализаторы, тест-системы, расходники. Для каждого оборудования мы завели в ЛИС свой идентификатор (root ...100.1.1.67). В секции достаточно указать этот идентификатор и наименование модели. Например:

<participant typeCode="DEV">
  <participantRole classCode="ROL">
    <id root="...100.1.1.67" extension="1234"/>
    <playingDevice>
      <manufacturerModelName>Гематологический анализатор Sysmex KX21</manufacturerModelName>
    </playingDevice>
  </participantRole>
</participant>

Если расходные материалы (гелевые карты, реагенты) – используем typeCode="CSM".

8. Секция RESLAB – результаты исследований

Секция организуется в виде иерархии: CLUSTER → BATTERY → OBSERVATION. Группировка BATTERY позволяет объединить показатели, полученные на одном анализаторе или имеющие общий смысл (например, «Общий анализ крови»).

Для каждого лабораторного показателя (свойства с секцией KODREZ) мы генерируем элемент <observation> с:

кодом теста из справочника 1.2.643.5.1.13.13.11.1080 (ФСЛР. Справочник лабораторных тестов);
значением (число, диапазон, строка, код);
единицей измерения (справочник 1.2.643.5.1.13.13.11.1358);
референтным интервалом (если есть);
датой выполнения;
ссылкой на исполнителя (через ID);
ссылкой на образец (из секции SPECIMENS);
ссылкой на оборудование (из ANALYSERS).

Также можно добавить комментарий к показателю (entryRelationship c act с code=»10000″) и общее заключение по всей секции (act с code=»901″).

Важный момент: в XML-примерах (максимальном, общем анализе крови, микробиологическом исследовании) хорошо показаны различные варианты кодирования – числовые значения, порядковые шкалы, качественные результаты со справочниками, вложения BASE64.

9. Источник оплаты (participant typeCode=»IND»)

В документе обязательно должен быть указан источник оплаты. Мы сделали выбор из справочника «Источники оплаты медицинской помощи» (OID 1.2.643.5.1.13.13.11.1039). В зависимости от выбранного кода (1 – ОМС, 3 – ДМС, 4 – средства пациента, 11 – бюджет МО) заполняются соответствующие элементы (документ-основание, полис, договор и т.д.). При оплате по ОМС мы дополнительно указываем страховую компанию из справочника «Реестр страховых медицинских организаций» (OID 1.2.643.5.1.13.13.99.2.183).

10. На что ещё обратить внимание

10.1. Версии справочников

Многие справочники (например, «Должности», «Виды медицинской помощи», «ФСЛР. Тесты») имеют постоянно обновляемые версии. В атрибуте codeSystemVersion мы указываем последнюю версию на момент формирования документа. Для небольших статичных справочников (виды полиса ОМС, типы документов оснований) версия фиксирована.

10.2. Поддержка микробиологических исследований

В примере «микробиологическое исследование» показана работа с культурами микроорганизмов: первичный материал (моча), затем посев (получены производные образцы – культуры), и для каждой культуры – отдельные результаты и антибиотикограмма. Это требует правильной связки через entryRelationship в секции SPECIMENS.

10.3. Использование nullFlavor

Если какое-то обязательное поле не может быть заполнено (например, нет лицензии), мы указываем nullFlavor="NI" или "NAV" с соответствующим объяснением. Однако для критических элементов (номер заявки, диагноз, СНИЛС пациента) nullFlavor недопустим – они должны быть заполнены обязательно.

10.4. Переход на редакцию 4

Если вы ранее использовали редакцию 3, обратите внимание на изменения:

добавилась поддержка структурных подразделений (extension в id организации);
изменился подход к указанию источника оплаты (вместо элемента participant с полисом ОМС теперь универсальный participant typeCode=»IND» с кодом источника);
обновлены версии многих справочников;
появились макеты (HTML) для визуализации.

11. Типичные ошибки и как их избежать

Нет идентификатора заявки – документ не пройдёт контроль. Проверяйте externalId в журнале взятия материала.
Диагноз не заполнен – особенно если исследование выполняется в рамках амбулаторного/стационарного случая. Настройте автоматическое копирование диагноза из случая в лабораторный протокол.
Отсутствует региональный идентификатор пациента – без него не сформируется правильный <id root="...10" extension="..."/>. Проверьте работу сервиса extendedmse.
Неверный код OID оборудования – используйте единый справочник оборудования в ЛИС и сверяйте OID с секцией ANALYSERS.
Забыли про структурное подразделение – если лаборатория является подразделением больницы, обязательно укажите extension в providerOrganization и других местах.

Заключение

Настройка CDA «Протокол лабораторного исследования» – задача нетривиальная, но выполнимая, если системно подойти к конфигурации типа действия, справочников и шаблонов печати. Главное – не забыть про идентификатор заявки, диагноз, региональный идентификатор пациента и правильную привязку лабораторных тестов к федеральным справочникам. Используйте приведённые в статье рекомендации и примеры, и ваша МИС начнёт формировать корректные CDA, которые успешно пройдут валидацию в РЭМД.