Привет, коллеги! Команда разработки медицинской информационной системы рассказывает о своём опыте внедрения структурированного электронного медицинского документа «Заключение об установлении факта поствакцинального осложнения» (Редакция 1). Если ваша МИС отправляет данные в РЭМД, этот материал поможет вам настроить тип действия, шаблон печати и правильно сформировать CDA-документ. Поехали!
📌 Оглавление
- Что такое СЭМД «Заключение о поствакцинальном осложнении»
- Какие задачи мы решали
- Настройка типа действия в МИС
- Идентификатор документа и счётчик
- Секции CDA и их связь со свойствами
- Код для отчётов и идентификация
- Прочие обязательные настройки (справочники, подписи, прививочная карта)
- Шаблон печати (HTML) — как мы его сделали
- Формирование CDA-документа: разбор XML
- Частые ошибки и как их избежать
- Чек-лист для интегратора
1. Что такое СЭМД «Заключение о поствакцинальном осложнении»
Это структурированный электронный медицинский документ, который создаётся при выявлении поствакцинального осложнения (ПВО). Документ формируется на основании протокола врачебной комиссии и передаётся в РЭМД (реестр электронных медицинских документов).
- Основание: Приказ Минздрава РФ № 972н.
- Шаблон CDA: закрытый (только разрешённые элементы).
- Версия: Редакция 1 (использует справочник «Поствакцинальные осложнения» OID
1.2.643.5.1.13.13.99.2.960). - OID шаблона:
1.2.643.5.1.13.13.14.368.9.1(указан в XML-примере).
2. Какие задачи мы решали
При внедрении этого документа мы столкнулись с типовыми проблемами:
- ✅ Автоматически заполнять идентификатор документа.
- ✅ Связывать свойства протокола (осложнение, комментарий) с секциями CDA.
- ✅ Настроить справочники для идентификации (организация, должности, типы документов, вакцины).
- ✅ Сформировать печатную форму и CDA-файл с тремя подписями.
- ✅ Валидировать данные перед отправкой (СНИЛС, должности, заполнение полей).
Ниже расскажем, как мы это сделали.
3. Настройка типа действия в МИС
Всё начинается с типа действия (мероприятия) в МИС. Пользователь регистрирует заключение, заполняет свойства, и система генерирует CDA.
3.1 Идентификатор документа и счётчик
Для уникального id документа и setId мы использовали счётчик с кодом CDA_ID.
Как настроить:
- В разделе «Настройки → Счётчики» создайте новый счётчик с кодом
CDA_ID. - В свойстве «Идентификатор документа» укажите, что его значение берётся из этого счётчика.
<!-- В итоговом CDA будет так: -->
<id root="1.2.643.5.1.13.13.12.2.70.7232.100.1.1.51" extension="123456"/>
<setId root="1.2.643.5.1.13.13.12.2.70.7232.100.1.1.50" extension="123456"/>
3.2 Секции CDA и их связь со свойствами
В типе действия мы создали свойства и указали для них параметр «Секция CDA»:
| Название свойства | Секция CDA | Обязательность | Тип | Примечание |
|---|---|---|---|---|
| Поствакцинальное осложнение | VAC_COMP | Да (1) | String | Выбор из справочника ПВО (7 значений) |
| Заключение | (пусто) | Да | String | Фиксированное: «Установлен факт поствакцинального осложнения» |
| Комментарий | COMMENT | Нет | String/Text | Свободный текст |
Важно: поле «Заключение» мы сделали нередактируемым (право редактирования — «Никто») и установили значение по умолчанию.
3.3 Код для отчётов и идентификация
- Код для отчётов у типа действия должен быть
OtherDocuments(см. рисунок 4 в документации). - Идентификация по справочнику «Классификатор электронных медицинских документов. Формат Cda» (код
n3.medDocumentType.Cda).
4. Прочие обязательные настройки
Без этих настроек CDA не пройдёт валидацию:
| Что настраиваем | Как / OID | Версия справочника |
|---|---|---|
| Организация (МО) | Идентификация по коду MDR308 (Реестр мед.организаций) | последняя |
| Должность исполнителя | OID 1.2.643.5.1.13.13.11.1002 | 7.6 |
| Тип документа, удостоверяющего личность (ДУЛ) | OID 1.2.643.5.1.13.13.99.2.48 и 1.2.643.5.1.13.13.99.2.48* | 7.2 |
| Вакцины | OID 1.2.643.5.1.13.13.11.1078 | 4.5 |
| Подписи | Значение 231 в параметре gIdMedDocumentTypeList конфига ИЭМК | — |
Проверьте: у пациента должна быть заполнена прививочная карта (вакцинация), иначе секция «Иммунобиологический препарат» не сформируется.
5. Шаблон печати (HTML) — как мы его сделали
Мы использовали HTML-шаблон (CERT_VAC_COMPLICATIONS_R1.html) на встроенном языке шаблонизатора (PyQt4/QtCore). Основные блоки:
5.1 Проверка данных перед печатью
{: error_log = ''}
{if: not client.SNILS}{: error_log += u'Не заполнен СНИЛС пациента<br>'}{end:}
{if: not action.person.SNILS}{: error_log += u'Не заполнен СНИЛС врача<br>'}{end:}
{if: action.status != 2}{: error_log += u'Протокол должен иметь состояние "Закончено"<br>'}{end:}
{if: error_log != ''}
{mb.critical(None, u'Проверка', u'<b>ВНИМАНИЕ!</b><br>' + error_log, mb.Ok, mb.Ok)}
{exit(0)}
{end:}
5.2 Выбор вакцины, если их несколько
{if: len(vacList) > 1}
{: vac = vacList[dialogs.dialList(u"Выберите вакцину", vacList_str).getVar()]}
{elif: len(vacList) == 1}
{: vac = vacList[0]}
{else:}
{: vac = ''}
{end:}
5.3 Определение типа иммунобиологического препарата (туберкулёз / Манту / прочие)
{if: infectionItem.name.lower().find(u'туберкул') != -1}
{: VAC_TYPE_NAME = u'Прививки против туберкулеза'}{: VAC_TYPE_CODE = u'1'}
{elif: infectionItem.name.lower().find(u'манту') != -1}
{: VAC_TYPE_NAME = u'Реакция Манту'}{: VAC_TYPE_CODE = u'2'}
{else:}
{: VAC_TYPE_NAME = u'Прививки против других инфекций'}{: VAC_TYPE_CODE = u'3'}
{end:}
5.4 Добавление CDA-документа
{: addSupplement('IdMedDocType_231.xml', '\n'.join(line for line in formatByTemplate('CDA_CERT_VAC_COMPLICATIONS_R1', 'CDA').split('\n') if line.strip() != '')) }
6. Формирование CDA-документа: разбор XML
Файл CDA_CERT_VAC_COMPLICATIONS_R1.xml — это основа для генерации. Разберём ключевые блоки.
6.1 Заголовок (Header)
| Элемент | Значение | Источник данных |
|---|---|---|
<templateId root="..."/> | 1.2.643.5.1.13.13.14.368.9.1 | фиксированное |
<id root="...51" extension="..."/> | корень: {MDR308}.100.1.1.51extension: из счётчика CDA_ID | настройки МИС |
<code code="368" codeSystem="...1522"/> | вид документа (Заключение) | справочник видов мед.документации |
<effectiveTime value="..."/> | дата+время окончания действия + часовой пояс | action.endDate |
<confidentialityCode code="N"/> | обычный уровень | фиксированно |
<setId root="...50" extension="..."/> | тот же extension, что у id | счётчик |
<versionNumber value="1"/> | первая версия | фиксированно |
6.2 Пациент (recordTarget)
- СНИЛС:
root="1.2.643.100.3" extension="{client.SNILS}" - Документ, удостоверяющий личность: серия, номер, кем выдан, код подразделения, дата выдачи (берутся из картотеки).
- Полис ОМС: тип полиса (код
1/2/3/4из справочника 1.2.643.5.1.13.13.11.1035), номер, серия (только для старого образца). - Адрес: текстовый адрес + код субъекта РФ (первые 2 цифры КЛАДР). ФИАС-идентификаторы пока не обязательны (ставятся
nullFlavor="NI").
6.3 Автор и лицо, придавшее юридическую силу (author / legalAuthenticator)
Оба блока содержат:
- Уникальный ID сотрудника:
root="{MDR308}.100.1.1.70" extension="{personId}" - СНИЛС сотрудника
- Код должности из справочника 1.2.643.5.1.13.13.11.1002
- ФИО
В legalAuthenticator дополнительно есть time nullFlavor="NI" и signatureCode nullFlavor="NI" (факт подписи проверяется в ИЭМК).
6.4 Источник оплаты (participant)
В зависимости от action.finance.code подставляются разные блоки:
2→ ОМС (документ-основание — полис ОМС)3→ ДМС (полис ДМС)4→ средства пациента (договор)- иначе → бюджет МО (код 11)
В блоке ОМС мы также определяем тип полиса и подставляем срок действия.
6.5 Документируемое событие (documentationOf)
- Тип события:
code="5"(Врачебная комиссия) - Даты: начало и окончание действия
- Форма помощи (
medService:serviceForm), вид помощи (medService:serviceType), условия (medService:serviceCond) — вычисляются на основе кодов из МИС. - Участник (
performer typeCode="PPRF"): роль «Председатель» (functionCode="CHAIRMAN"), те же данные сотрудника.
6.6 Тело документа (structuredBody)
Секция DOCINFO (обязательная) включает:
- Сведения о введении иммунобиологического препарата (
entryсsubstanceAdministration) — если выбрана вакцина и у неё есть идентификация по справочнику 1078. - Поствакцинальное осложнение (
entryсobservation code="8014") — значение берётся из свойстваVAC_COMP, код подставляется из массиваVAC_COMP_CODE_ARR(1..7). Справочник:1.2.643.5.1.13.13.99.2.960. - Заключение (фиксированное,
code="44"из справочника 1.2.643.5.1.13.13.99.2.725). - Комментарий — если заполнен.
📌 Обратите внимание: в Редакции 1 секция LINKDOCS (связанные документы) не используется.
7. Частые ошибки и как их избежать
Мы собрали топ-5 проблем при внедрении:
| Ошибка | Решение |
|---|---|
| Не заполнен СНИЛС пациента или врача | Добавить проверку в шаблон (как у нас) и выводить сообщение. |
| Должность врача не идентифицирована по справочнику 1002 | Настроить идентификацию должности в справочнике «Должности». |
| Вакцина не найдена в справочнике 1078 | Проверяем vac.vaccine.identify(...) и выводим предупреждение с возможностью продолжить. |
| Нет трёх подписей в ИЭМК | Убедиться, что 231 есть в gIdMedDocumentTypeList. |
| В протоколе не указано поствакцинальное осложнение | Сделать свойство обязательным (penalty > 0) и проверять в шаблоне. |
8. Чек-лист для интегратора
Перед тем как сдавать внедрение, проверьте:
- [ ] Тип действия имеет код отчёта
OtherDocuments. - [ ] Идентификация типа действия по CDA настроена.
- [ ] Счётчик
CDA_IDсоздан и подключён к свойству «Идентификатор документа». - [ ] У организации заполнена идентификация
MDR308. - [ ] Должность исполнителя идентифицирована по OID 1002.
- [ ] ДУЛ пациента идентифицирован по OID 48 (и 48*).
- [ ] Вакцины в прививочной карте имеют код по OID 1078.
- [ ] В конфиге ИЭМК прописан
231. - [ ] Шаблон печати содержит проверки СНИЛС, статуса протокола и обязательных свойств.
- [ ] CDA-файл проходит валидацию на тестовом РЭМД.
Заключение
Мы показали на примере Редакции 1, как настроить МИС для формирования СЭМД «Заключение об установлении факта поствакцинального осложнения». Главные выводы:
- Используйте счётчик для уникальных идентификаторов.
- Связывайте свойства протокола с секциями CDA через параметр
Секция CDA. - Все справочники должны быть идентифицированы корректными OID и версиями.
- В шаблоне печати обязательно делайте предварительные проверки данных.
Если вы переходите на Редакцию 2 — учтите, что там изменён справочник осложнений, добавлен translation в <code> и новая секция LINKDOCS. Но об этом — в следующей статье.
Вопросы? Пишите в комментариях — поможем разобраться с любыми граблями!



