Настройка CDA «Выписка из истории болезни» в МИС: амбулаторная и стационарная версии

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

1. Зачем нужна выписка и чем она отличается от других CDA

Выписка из истории болезни (код документа 350 по классификатору «Виды медицинской документации») предназначена для обмена данными между медицинскими учреждениями, а также для предоставления информации о состоянии здоровья пациента по месту требования (например, при переводе в другую больницу, для представления в учебное заведение, на работу). Руководство по реализации CDA для этого документа имеет OID шаблона 1.2.643.5.1.13.13.14.350.9.1 (Редакция 1).

В отличие от многих других СЭМД, выписка может формироваться как для амбулаторного, так и для стационарного случая. В зависимости от этого меняются заголовок документа («Выписка из медицинской карты амбулаторного больного» или «Выписка из медицинской карты стационарного больного») и коды видов медицинской карты (41 – амбулаторная, 94 – стационарная). Также выписка может содержать сведения о законном представителе пациента (для детей или недееспособных лиц), что требует дополнительной логики в шаблоне.

Мы настроили этот документ в нашей МИС, и я расскажу, с какими трудностями столкнулись и как их преодолели.

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

2.1. Основные атрибуты

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

Код для отчётов – OtherDocuments.
Вид услуги – Прочее.
Идентификация по справочнику CDA – 1.2.643.2.69.1.1.1.195.Cda (идентификатор уточните в вашем классификаторе, у нас он соответствовал выписке).
Идентификация по справочнику МИС – n3.medDocumentType.Cda.

Также в типе действия на вкладке «Умолчания» можно задать значения по умолчанию, например, для поля «Лечебные и трудовые рекомендации» – пустую строку.

2.2. Свойства типа действия (секции CDA)

В типе действия мы добавили следующие свойства (каждому указали параметр «Секция CDA» согласно таблице из руководства):

Название свойства	Код секции CDA	Обязательность	Тип	Примечание
Идентификатор документа	–	0	Счётчик	Используем счётчик CDA_ID
Жалобы	LAMENT	1	String/Text/Constructor
Объективно	OBJECTIVELY	1	String/Text/Constructor
Лечебные и трудовые рекомендации	RECOMMENDATIONS	0	String/Text/Constructor	Опционально

Важно: свойства «Жалобы» и «Объективно» обязательны (penalty = 10). Без них документ не сформируется. «Лечебные и трудовые рекомендации» – опциональны.

Свойство «Идентификатор документа» мы настроили со счётчиком CDA_ID, предварительно созданным в разделе «Настройки – Счётчики».

2.3. Оформление выписки в МИС

Врач должен зарегистрировать мероприятие (тип действия) в случае обслуживания пациента, заполнить поля «Жалобы», «Объективно» и при необходимости «Лечебные и трудовые рекомендации», затем нажать кнопку «Печать». Сформированный PDF подписывается электронной подписью, после чего автоматически генерируется XML-документ для отправки в РЭМД.

3. Проверки в HTML-шаблоне – чтобы не ушёл неполный документ

В шаблон печати (EXCERPT_FROM_MED_CARD.html) мы добавили блок проверок. Критические ошибки (без них документ не может быть отправлен):

СНИЛС пациента – обязателен.
СНИЛС исполнителя (врача, оформившего выписку) – обязателен.
Идентификация должности исполнителя – должна быть по справочнику 1.2.643.5.1.13.13.11.1002.
Состояние документа – должно быть «Закончено».
Для стационарного случая – обязательно заполнена дата «Выполнено» на вкладке «Стат.учет»/«Стат.талон» (используем event.execDate).
Обязательные свойства (с penalty > 0) – проверяем на пустоту.

Если какая-то из этих проверок не проходит, пользователь видит диалоговое окно с перечнем ошибок, формирование прерывается.

Дополнительно мы добавили проверку на наличие места работы и род занятий (client.work.shortName) – это не критично, но выводим предупреждение, если не заполнено.

4. Определение типа случая: амбулатория или стационар

В нашем HTML-шаблоне мы определили переменную ambul (1 – амбулатория, 0 – стационар) на основе типа медицинской помощи из события:

{: ambul = -1}
{: strInput = event.eventType.medicalAidType.name.lower()}
{if: strInput.find(u'амб') != -1}
  {: ambul = 1}
{elif: strInput.find(u'стац') != -1}
  {: ambul = 0}
{end:}

В зависимости от значения ambul:

Заголовок документа (<title>) в XML становится либо «Выписка из медицинской карты амбулаторного больного», либо «Выписка из медицинской карты стационарного больного».
В секции componentOf (случай оказания медицинской помощи) меняется код и вид медицинской карты:
Для амбулатории: code code="1" (Амбулаторная медицинская карта), medService:DocType code="41".
Для стационара: code code="2" (Стационарная медицинская карта), medService:DocType code="94".
В секции DOCINFO меняется текст «Даты по амбулатории» на «Даты по стационару», и для стационара обязательно заполняется дата окончания.

5. Работа с законным представителем

Если пациент – ребёнок или недееспособный, в выписке должны быть указаны сведения о законном представителе. В нашем шаблоне мы реализовали:

Формируем список presents, включающий всех прямых представителей (r.isDirectRepresentative), а также самого пациента.
Если список не пуст, показываем диалог выбора представителя через dialogs.dialList.
Для выбранного представителя определяем код родственной связи (FAMILY_TIES_CODE) и наименование (FAMILY_TIES_NAME) по справочнику «Родственные и иные связи» (OID 1.2.643.5.1.13.13.99.2.14):

Мать – код 1
Отец – код 2
Родственник – код 3
Уполномоченное лицо – код 4

В XML заполняем блок <guardian>: СНИЛС представителя, его документ, удостоверяющий личность, документ, удостоверяющий полномочия (например, свидетельство о рождении), тип связи и ФИО.

Если представитель не выбран, блок <guardian> не формируется.

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

Как и для всех CDA, нам нужен глобальный идентификатор пациента. В конце HTML-шаблона мы добавили вызов:

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

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

Не забудьте проверить, что в глобальных настройках есть ExtendedMseUrl и в конфигурации ИЭМК прописаны gDefaultMpiUrl и gMpiToken.

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

Для успешного формирования выписки мы проверили следующие настройки.

7.1. Справочник «Организации»

У текущей медицинской организации должна быть настроена идентификация по справочнику MDR308 (OID 1.2.643.5.1.13.2.1.1.178). При наличии структурного подразделения (например, отделение, в котором работает врач) указываем его OID из справочника «ФРМО. Справочник структурных подразделений» (OID 1.2.643.5.1.13.13.99.2.114).

7.2. Тип действия – идентификация

Тип действия должен иметь идентификацию по справочнику с кодом n3.medDocumentType.Cda.

7.3. Справочник «Типы документов» (ДУЛ пациента)

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

OID 1.2.643.5.1.13.13.99.2.48 – идентификатор типа документа;
OID 1.2.643.5.1.13.13.99.2.48* – наименование типа документа.

Версия справочника – не ниже 7.1.

7.4. Справочник «Должности»

У должности исполнителя (врача, выдавшего выписку) должна быть настроена идентификация по справочнику «Должности работников организаций здравоохранения» с OID 1.2.643.5.1.13.13.11.1002. Версия справочника – 7.6.

Кроме того, в настройках типа действия мы добавили идентификацию по справочнику с OID 1.2.643.5.1.13.13.11.1002* для указания наименования должности.

7.5. Код ОКПО организации

В HTML-шаблоне мы проверяем наличие ОКПО у текущей организации (currentOrganisation.OKPO). Для детской выписки (если пациент младше 18 лет) это поле обязательно. Для взрослой – не критично, но лучше заполнить.

8. Источник оплаты и страховая компания

В XML-шаблоне мы использовали стандартный блок <participant typeCode="IND"> с выбором источника оплаты. Для ОМС обязательно указываем страховую компанию из справочника «Реестр страховых медицинских организаций (ФОМС)» (OID 1.2.643.5.1.13.13.99.2.183). Если оплата по ДМС или платная, заполняем соответствующие поля.

9. Вызов генерации XML

В HTML-шаблоне после всех проверок и перед закрывающими тегами мы добавили:

{: addSupplement('IdMedDocType_209.xml', '\n'.join(line for line in formatByTemplate('CDA_EXCERPT_FROM_MED_CARD', 'CDA').split('\n') if line.strip() != '')) }

Обратите внимание: мы удаляем пустые строки, чтобы XML был компактнее. Имя файла IdMedDocType_209.xml – это внутреннее соглашение, вы можете использовать любое.

10. Пример заполненной выписки

В руководстве по реализации приведён пример выписки для амбулаторного больного (ребёнок с пневмонией). Документ содержит:

Общие сведения: место, куда направлена выписка («По месту требования»), место работы и род занятий (школьник), даты заболевания, жалобы, объективный статус, лечебные рекомендации.
Диагноз: основное заболевание – пневмония неуточненная (J18.9).
Связанные документы: ссылка на протокол консультации педиатра.

Этот пример хорошо показывает, как должны быть заполнены поля и как выглядит XML.

11. Что важно помнить при эксплуатации

Проверка даты выполнено для стационара – если случай стационарный, обязательно нужно указать дату выписки (дату окончания случая), иначе документ не сформируется.
Законный представитель – если пациент – ребёнок, но в карточке не заполнены родственные связи, диалог выбора не появится. Рекомендуем заранее заполнять информацию о родителях в регистрационной карте.
Место работы и род занятий – это поле не обязательно, но без него выписка будет неполной. Врач может ввести его вручную в свойстве «Место работы и род занятий», которое мы не вынесли в отдельное свойство, а берём из карточки пациента (client.work). Если в карточке не заполнено, выводим предупреждение.
Код ОКПО – для детской выписки проверяем его наличие. Если ОКПО не заполнен в справочнике «Организации», РЭМД может отклонить документ.
Версии справочников – регулярно обновляйте справочники (должности, типы документов, МКБ-10) до последних версий.

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