В этой статье я поделюсь нашим опытом внедрения в медицинской информационной системе детской санаторно-курортной карты (форма 076/у) в формате CDA (Редакция 1). Материал будет полезен коллегам, которые работают с детским контингентом, сталкиваются с оформлением льгот, выбором законного представителя и интеграцией с РЭМД. Расскажу, какие грабли мы собрали и как их обойти.
1. Детская карта — не уменьшенная копия взрослой
Санаторно-курортная карта для детей (форма 076/у) утверждена тем же приказом №834н, что и взрослая, но имеет свои особенности. Во‑первых, вместо «Медицинской карты амбулаторного больного» (код 41) используется «История развития ребенка» (код 63). Во‑вторых, появляются специфические разделы: анамнез жизни ребенка, наследственность, профилактические прививки, образовательная организация, место работы родителей. В‑третьих, обязательный элемент — сведения о законном представителе (мать, отец, опекун), который подписывает документ и сопровождает ребёнка.
Шаблон CDA имеет OID 1.2.643.5.1.13.13.14.50.9.1 (Редакция 1). Код документа — 50 по классификатору «Виды медицинской документации».
Мы создали отдельный тип действия CARD_SANATOR_CHILD, чтобы не путать с взрослой картой, и настроили его по аналогии, но с учётом детской специфики.
2. Настройка типа действия и свойств
2.1. Основные атрибуты
- Код для отчётов –
OtherDocuments:SANATOR_CHILD(можно простоOtherDocuments). - Вид услуги –
Прочее. - Идентификация по справочнику CDA –
1.2.643.2.69.1.1.1.195.Cda(свой идентификатор для детской карты). - Идентификация по справочнику МИС –
n3.medDocumentType.Cda.
Счётчик идентификатора документа – стандартный CDA_ID.
2.2. Свойства и секции CDA
Мы добавили в тип действия следующие свойства (все с параметром sectionCDA согласно таблице из руководства). Обязательные поля отмечены penalty=10.
| Название свойства | Код секции | Обязательность | Тип | Примечание |
|---|---|---|---|---|
| Номер санаторно-курортной карты | NUMBER_CARD | 1 | String | |
| Имеет право на получение набора социальных услуг | SOC_PRIV | 0 | Boolean | Если true – появляются поля климата, льгот |
| Климат в месте проживания | CLIMAT | 0 | Справочник | Справочник 1.2.643.5.1.13.13.99.2.685 |
| Климатические факторы в месте проживания | CL_FACTOR | 0 | Справочник | Справочник 1.2.643.5.1.13.13.99.2.684 |
| Необходимость сопровождения пациента | ESCORT | 0 | Boolean | |
| Образовательная организация | EDUCAT_ORG | 1 | String | |
| Место работы матери (отца) | WORK_PARENTS | 0 | String | Подставляется, если не заполнено у представителя |
| Анамнез жизни | LANAM | 1 | Text | Включает наследственность и прививки |
| Жалобы | COMP | 1 | Text | |
| Анамнез заболевания | ANAM | 1 | Text | |
| Название санаторно-курортной организации | SANATOR_NAME | 1 | String | |
| Рекомендовано лечение в условиях пребывания в санатории | REGIME | 0 | Boolean | |
| Продолжительность курса лечения (дней) | DURATION | 1 | Integer | |
| Номер путевки | NUMBER_PUT | 1 | String |
Важно: для CLIMAT и CL_FACTOR мы настроили выпадающие списки строго по федеральным справочникам – иначе РЭМД не пропустит.
3. Законный представитель: диалог выбора и подстановка данных
В детской карте обязательно указывается законный представитель (мать, отец, опекун). В нашей МИС в карточке ребенка есть список родственников и опекунов с указанием типа связи (код родства). Мы сделали так:
- Формируем список
presents, куда включаем всех прямых представителей (r.isDirectRepresentative), а также самого пациента (на случай, если ребёнок совершеннолетний, но карта всё равно детская – редкость, но для полноты). - Если список не пуст, показываем диалог выбора представителя (через
dialogs.dialList). - Выбранного представителя сохраняем в переменную
who. - Определяем код родственной связи
CODERELи по нему устанавливаемFAMILY_TIES_NAMEиFAMILY_TIES_CODE(мать – 1, отец – 2, родственник – 3, уполномоченное лицо – 4). - В XML заполняем блок
<guardian>: СНИЛС представителя (если есть), его документ, удостоверяющий личность, код родственной связи и ФИО.
Если представитель не выбран (например, система не смогла определить), мы всё равно пытаемся подставить данные из свойства WORK_PARENTS, но лучше не рисковать – в проверках мы требуем заполнения.
4. Образовательная организация и место работы родителей
Два важных поля, которых нет во взрослой карте.
Образовательная организация (EDUCAT_ORG) – обязательное строковое поле. Если ребёнок не посещает детский сад или школу, мы рекомендуем писать «не организован» (именно так указано в руководстве: «если ребенок не посещает образовательную организацию, заполняется текстом «не организованный»»).
Место работы матери (отца) – опционально. В шаблоне мы приоритезируем данные выбранного представителя: если у who заполнено who.work, берём его. Иначе – берём значение из свойства WORK_PARENTS. В проверках мы следим, чтобы хотя бы что-то было заполнено, иначе выдаём ошибку.
5. Льготные категории (SOC_PRIV)
Для детей, имеющих право на набор социальных услуг, работает та же логика, что и во взрослой карте, но с одной особенностью: код льготы 9 «Дети-инвалиды» используется только для детей. В маппинге мы явно проверяем L_NAME == u'Дети-инвалиды' or L_NAME == u'Дети инвалиды'.
Документ, удостоверяющий право на льготу (серия, номер, дата), берётся из социального статуса пациента с признаком classes == u'льгота'. Важно, чтобы в карточке ребёнка был заполнен хотя бы один такой статус, иначе при включённом флаге SOC_PRIV проверки не пройдут.
6. Связанные исследования (лаборатория и инструментальная диагностика)
Как и во взрослой карте, мы автоматически подбираем в текущем событии (event.actions) завершённые лабораторные и инструментальные исследования:
{: lab_list = [x for x in event.actions if x.status == 2 and x.serviceType == 10 and (x.flatCode == 'OtherDocuments:LI' or x.flatCode == 'OAK' or x.flatCode == 'OAM')]}
{: instr_list = [x for x in event.actions if x.status == 2 and (x.flatCode == 'OtherDocuments:II' or (x.serviceType == 5 and x.identify('urn:oid:1.2.643.2.69.1.1.1.195.Cda') == '148'))]}Условия те же: тип услуги 10 (лаборатория) или 5 (инструментальная диагностика) с идентификатором CDA 148. В секции LINKDOCS мы выводим их названия, даты и часть результатов, а также формируем внешние ссылки на документы для РЭМД.
Важно: если в событии нет ни одного подходящего исследования, мы не блокируем формирование карты, но показываем предупреждение (в проверках это if: not lab_list and not instr_list). По логике карта может быть оформлена и без свежих анализов, но лучше иметь хотя бы одно.
7. Анамнез жизни – отдельный раздел
В детской карте появился раздел LANAM (анамнез жизни), который включает в себя наследственность и профилактические прививки. В нашем шаблоне мы объединили всё в одно текстовое поле, но можно разбить на несколько свойств с одинаковой секцией LANAM – руководство это допускает. Мы пока оставили одно поле для свободного ввода, но в планах сделать структурированный ввод.
8. Тип медицинской карты – «История развития ребенка»
В XML-заголовке в блоке componentOf/encompassingEncounter мы явно указываем:
<medService:DocType code="63" codeSystem="1.2.643.5.1.13.13.11.1522" codeSystemVersion="7.1" codeSystemName="Виды медицинской документации" displayName="История развития ребенка"/>Это отличает детскую карту от взрослой, где используется код 41 (амбулаторная карта). Не перепутайте, иначе РЭМД может отклонить документ.
9. Региональный идентификатор пациента (MPI)
В детской карте мы используем только вызов сервиса extendedmse – для детей Санкт-Петербурга особое правило не применяется (в нашем шаблоне clientGlobalIdNetrika подставляется везде). Формирование идентификатора происходит стандартно:
{: from library.Utils import forceString}
{: clientGlobalIdNetrika = readUrl("http://"+forceString(dbServerName)+"/extendedmse/api?fromtemplate=1&clientid="+forceString(client.id), timeout=50)}И затем в <id root="...10" extension="{clientGlobalIdNetrika}"/>.
10. Проверки заполнения – детский чек-лист
Мы добавили в HTML-шаблон блок проверок. Помимо общих (СНИЛС, полис ОМС, адрес по КЛАДР, СНИЛС исполнителя, идентификация должности, состояние «Закончено», наличие диагноза), добавили специфические для детей:
- Код ОКПО организации –
if: not currentOrganisation.OKPO. В детской карте это поле обязательно. - Место работы представителя – если выбран представитель и у него не заполнено место работы, а свойство
WORK_PARENTSпустое – ошибка. - Образовательная организация – обязательное поле.
- Анамнез жизни – обязательное поле.
Для льготников те же проверки, что и во взрослой карте: климат, климатические факторы, серия/номер/дата документа льготы.
11. Вызов генерации XML
В конце HTML-шаблона мы добавляем:
{: addSupplement('xml', '\n'.join(line for line in formatByTemplate('CDA_CARD_SANATOR_CHILD', 'CDA').split('\n') if line.strip() != '')) }Шаблон CDA_CARD_SANATOR_CHILD содержит XML-код, который мы привели в примере. Удаление пустых строк – опционально, но улучшает читаемость.
12. Что может пойти не так: наш опыт
- Нет законного представителя – если в карточке ребёнка не заполнены родственные связи, диалог выбора не появится, и
whoостанетсяNone. В этом случае мы не можем заполнить блок<guardian>. РЭМД формально не требует представителя для всех детей (только если ребёнок несовершеннолетний и не дееспособен), но лучше всё же заполнять. Мы добавили проверку, но не сделали её критической. - Ошибка в ОКПО организации – детская карта требует указания кода ОКПО медицинской организации. Если он не заполнен в справочнике «Организации», документ не пройдёт контроль. Проверьте, что у вашей МО заполнено поле ОКПО.
- Неверный код медицинской карты – если по ошибке указать
41вместо63, РЭМД может отклонить документ. У нас это была частая проблема при копировании шаблона со взрослой карты. - Прививки и наследственность – их мы пока не вынесли в отдельные свойства, но руководство позволяет заполнять секцию
LANAMиз нескольких свойств. В следующей версии планируем сделать структурированный ввод. - Возраст пациента – хотя тип действия создан для детей, формально проверка возраста не выполняется. Но мы полагаемся на врача – карта заполняется только для пациентов младше 18 лет.
Детская санаторно-курортная карта – это не просто копия взрослой с заменой пары полей. Она требует работы с законными представителями, учёта образовательной организации и анамнеза жизни ребёнка. Настройка типа действия оказалась несложной, но потребовала внимания к мелочам: правильные справочники, диалог выбора представителя, проверка ОКПО. Если вы только начинаете внедрять этот CDA – советую сначала сделать макет (HTML), отладить логику выбора представителя на тестовых данных и только потом переходить к продуктивной среде.
Удачи в настройке!