Интеграция с ЕГИСЗ: практические сценарии маршрутизации пациентов | AdminWiki
Logo

Интеграция с ЕГИСЗ: практические сценарии маршрутизации пациентов

21 июля 2026 8 мин. чтения
Содержание статьи

Архитектура интеграции: как МИС общается с ЕГИСЗ

Единая государственная информационная система в сфере здравоохранения (ЕГИСЗ) выступает центральным хабом для обмена медицинскими данными. Медицинская информационная система (МИС) клиники подключается к ней как клиент, отправляя электронные направления, сведения о расписании и получая статусы записей. Ядро взаимодействия - два потока данных: исходящий (направления пациентов и слоты) и входящий (подтверждения, отказы, обновления статусов).

Для системного администратора или DevOps-инженера интеграция начинается с организации защищённого транспортного уровня. Без него ни один запрос не пройдёт. Далее идёт выбор протокола прикладного уровня, который определит формат ваших пакетов и методы API. Ошибка на этом этапе приводит к отклонению даже синтаксически корректных сообщений.

Типовая схема включает три компонента: вашу МИС, промежуточный шлюз с криптозащитой и API-эндпоинты ЕГИСЗ. Шлюз терминирует VPN-туннель и проверяет клиентский TLS-сертификат. После успешного рукопожатия МИС может вызывать методы для создания направлений, загрузки слотов и проверки статусов. Все вызовы журналируются на стороне шлюза - эти логи станут основным источником для диагностики.

Протоколы и форматы: что выбрать для своей МИС

ЕГИСЗ поддерживает два стека протоколов: классический SOAP с XML-сообщениями и современный FHIR (Fast Healthcare Interoperability Resources) поверх REST с JSON. Выбор зависит от возможностей вашей МИС и требований конкретного регионального сегмента ЕГИСЗ.

FHIR предпочтительнее для новых интеграций. Он работает через привычные HTTP-методы (GET, POST, PUT, DELETE), использует компактный JSON и предоставляет готовые ресурсы: Patient, Appointment, ServiceRequest, Slot. SOAP остаётся в эксплуатации у legacy-систем, которые не обновлялись последние 5-7 лет. Если ваша МИС поддерживает оба протокола, выбирайте FHIR - меньше накладных расходов на парсинг XML, проще отладка через Postman или curl.

Пример эндпоинта FHIR для создания направления:

POST https://egisz-gateway.example.gov.ru/fhir/ServiceRequest

Пример SOAP-эндпоинта:

POST https://egisz-gateway.example.gov.ru/ws/ReferralService

Заголовок Content-Type для FHIR: application/fhir+json. Для SOAP: text/xml; charset=utf-8. Не перепутайте - шлюз ЕГИСЗ отбрасывает запросы с неверным Content-Type до обработки тела.

Защищённый канал: настройка VPN и TLS

Медицинские данные относятся к категории специальных персональных данных. Передавать их через открытый интернет без шифрования запрещено регулятором. ЕГИСЗ требует организации VPN-туннеля (IPsec или WireGuard) и взаимной TLS-аутентификации.

Пошаговая настройка WireGuard до шлюза ЕГИСЗ:

  1. Получите от оператора ЕГИСЗ публичный ключ шлюза, IP-адрес эндпоинта и выделенный вам диапазон туннельных адресов.
  2. Сгенерируйте пару ключей на стороне МИС: wg genkey | tee privatekey | wg pubkey > publickey
  3. Создайте конфигурационный файл /etc/wireguard/egisz.conf: 
    [Interface]
PrivateKey = <ваш_приватный_ключ>
Address = 10.200.0.2/30
DNS = 10.200.0.1

[Peer]
PublicKey = <публичный_ключ_шлюза>
Endpoint = egisz-gw.example.gov.ru:51820
AllowedIPs = 10.200.0.0/30
PersistentKeepalive = 25
  4. Поднимите туннель: wg-quick up egisz
  5. Проверьте связность: ping 10.200.0.1

После поднятия туннеля настройте TLS. ЕГИСЗ выдаёт клиентский сертификат X.509. Проверьте его валидность и цепочку доверия:

openssl s_client -connect 10.200.0.1:443 -cert client.crt -key client.key -CAfile ca.crt -verify 2

Успешное рукопожатие подтверждает, что канал готов к передаче данных. Сохраните вывод команды - он пригодится при обращении в техподдержку ЕГИСЗ.

Электронное направление: структура и формирование

Электронное направление - структурированный документ, который МИС отправляет в ЕГИСЗ для маршрутизации пациента в другое учреждение. Отказ в приёме направления чаще всего вызван несоответствием формата или отсутствием обязательных полей. Разберём структуру, чтобы вы могли формировать корректные документы с первого раза.

Обязательные поля направления: идентификатор пациента в ЕГИСЗ (ЕНП - единый номер пациента), диагноз по справочнику МКБ-10, цель визита (консультация, диагностика, госпитализация), OID целевого учреждения. Все справочники вы получаете от регионального оператора ЕГИСЗ. Не подставляйте значения из локальной БД МИС - OID и коды должны совпадать с мастер-данными федеральной системы. Подробнее о настройке правил маршрутизации внутри МИС читайте в пошаговом руководстве по настройке маршрутизации пациентов в МИС.

Пример направления в формате FHIR

Работающий JSON-документ для ресурса ServiceRequest с комментариями к каждому блоку:

{
  "resourceType": "ServiceRequest",
  "id": "ref-2026-07-21-001",
  "status": "active",
  "intent": "order",
  "priority": "routine",
  "subject": {
    "reference": "Patient/1234567890",
    "display": "ЕНП пациента"
  },
  "code": {
    "coding": [{
      "system": "urn:oid:1.2.643.5.1.13.13.11.1005",
      "code": "Z01.7",
      "display": "Консультация кардиолога"
    }]
  },
  "reasonCode": [{
    "coding": [{
      "system": "urn:oid:1.2.643.5.1.13.13.11.1006",
      "code": "I10",
      "display": "Эссенциальная гипертензия"
    }]
  }],
  "performer": [{
    "reference": "Organization/1.2.643.5.1.13.13.12.1.100.777",
    "display": "OID целевого учреждения"
  }],
  "authoredOn": "2026-07-21T10:30:00+03:00"
}

Частые ошибки при формировании:

  • Неверный OID справочника в поле system. Каждый справочник (МКБ-10, цели визита, типы услуг) имеет уникальный OID. Сверяйтесь с реестром, полученным от оператора.
  • Отсутствие intent. Поле обязательно для ServiceRequest, допустимые значения: proposal, plan, order, original-order, reflex-order, filler-order, instance-order, option.
  • Пустой performer. Без указания целевого учреждения направление не может быть маршрутизировано.
  • Несовпадение кодировки. Все строки должны быть в UTF-8. Кириллица в cp1251 вызывает ошибку парсинга на стороне ЕГИСЗ.

Передача сведений о слотах и мощностях

Маршрутизация пациента невозможна без актуального расписания. ЕГИСЗ агрегирует слоты со всех подключённых учреждений и показывает пациенту доступные времена для записи. Ваша задача - обеспечить регулярную синхронизацию слотов из МИС в федеральную систему.

Механизм работает по принципу push: МИС отправляет изменения расписания через API ЕГИСЗ. Полная выгрузка выполняется раз в сутки, инкрементальные обновления - по факту изменений (отмена приёма, перенос, добавление нового слота). Задержка между изменением в МИС и отображением в ЕГИСЗ не должна превышать 15 минут. При превышении этого порога срабатывает алерт мониторинга.

API для загрузки расписания: эндпоинты и методы

ЕГИСЗ предоставляет REST-методы для управления слотами в формате FHIR. Основной ресурс - Slot. Доступные операции:

  • PUT /fhir/Slot/{slot_id} - создание или полное обновление слота. Тело запроса - ресурс Slot в JSON.
  • DELETE /fhir/Slot/{slot_id} - удаление слота (отмена приёма).
  • PATCH /fhir/Slot/{slot_id} - частичное обновление (изменение статуса).

Аутентификация через клиентский TLS-сертификат. Дополнительный заголовок Authorization: Bearer <токен> не требуется, если используется взаимный TLS.

Пример curl-запроса для загрузки слота:

curl -X PUT \
  https://egisz-gateway.example.gov.ru/fhir/Slot/slt-20260721-001 \
  --cert client.crt \
  --key client.key \
  -H "Content-Type: application/fhir+json" \
  -d '{
    "resourceType": "Slot",
    "id": "slt-20260721-001",
    "schedule": {"reference": "Schedule/sch-cardio-01"},
    "status": "free",
    "start": "2026-07-22T09:00:00+03:00",
    "end": "2026-07-22T09:30:00+03:00",
    "serviceType": [{
      "coding": [{
        "system": "urn:oid:1.2.643.5.1.13.13.11.1005",
        "code": "B01.015.001"
      }]
    }]
  }'

Поле schedule.reference указывает на ресурс Schedule, который описывает врача и кабинет. Его нужно предварительно зарегистрировать в ЕГИСЗ через отдельный запрос. Без привязки к Schedule слот не будет отображаться в системе записи.

Диагностика и устранение ошибок интеграции

Сбои при обмене с ЕГИСЗ делятся на три категории: транспортные (нет соединения), аутентификационные (недействителен сертификат) и прикладные (невалидные данные). Для каждой категории есть свой набор инструментов диагностики.

Транспортные ошибки выявляются через проверку VPN-туннеля и доступности эндпоинта. Аутентификационные - через анализ TLS-рукопожатия. Прикладные - через разбор кодов ответа HTTP и тела сообщения с описанием ошибки.

Базовый набор инструментов: tcpdump для захвата трафика, openssl для проверки сертификатов, curl и Postman для тестовых запросов, анализатор JSON (jq) для валидации структуры. Логи МИС и логи шлюза ЕГИСЗ сопоставляются по временным меткам - расхождение в миллисекундах указывает на задержку на конкретном узле.

Кейс: ошибка 400 Bad Request при отправке направления

Симптом: МИС отправляет направление, ЕГИСЗ возвращает HTTP 400 с телом {"issue": [{"severity": "error", "code": "invalid", "diagnostics": "Invalid JSON content"}]}.

Причина: в теле запроса присутствует невалидный JSON. В одном из кейсов проблема была в поле diagnosis - разработчик МИС использовал строку вместо массива объектов CodeableConcept. ЕГИСЗ ожидает массив, даже если диагноз один.

Диагностика: сохраните тело запроса из логов МИС в файл request.json. Прогоните через валидатор:

cat request.json | jq .

Если jq выдаёт ошибку парсинга - JSON сломан синтаксически. Если парсинг успешен - сверьте структуру с FHIR-схемой ресурса ServiceRequest. Конкретно в этом кейсе jq показал, что reasonCode - строка, а не массив. Исправление: обернули значение в квадратные скобки, отправили повторно - 201 Created.

Для системной диагностики маршрутизации в целом используйте чек-лист аудита и оптимизации схемы маршрутизации пациентов. Он поможет проверить метрики и найти узкие места за один рабочий день.

Мониторинг и проверка корректности обмена

Интеграция с ЕГИСЗ требует непрерывного мониторинга. Разовый запуск и проверка «работает - не работает» недостаточны. Нужен автоматический контроль трёх уровней: доступность канала, валидность сертификата, успешность тестовых запросов.

Настройте алерты на события в логах: ошибки TLS, таймауты соединения, коды ответов 4xx и 5xx. Порог срабатывания - три ошибки подряд за 5 минут. Инструмент алертинга можно подключить к вашей системе мониторинга (Zabbix, Prometheus + Alertmanager) через парсинг лог-файла или HTTP-эндпоинт health-check.

Сверка целостности: раз в час сравнивайте количество отправленных направлений (из логов МИС) с количеством принятых (из ответов ЕГИСЗ). Расхождение больше 1% - повод для внеплановой диагностики. Такая проверка выявляет «тихие» потери пакетов, которые не генерируют явных ошибок.

Скрипт для автоматической проверки соединения

Bash-скрипт для ежедневного контроля. Проверяет три компонента: VPN-туннель, TLS-сертификат и ответ health-check эндпоинта. Разместите в cron с запуском каждые 15 минут:

#!/bin/bash

LOG_FILE="/var/log/egisz-health.log"
GW_IP="10.200.0.1"
HC_URL="https://10.200.0.1/fhir/metadata"
CERT="/etc/ssl/egisz/client.crt"
KEY="/etc/ssl/egisz/client.key"
CA="/etc/ssl/egisz/ca.crt"

# Проверка VPN-туннеля
ping -c 3 -W 2 $GW_IP > /dev/null 2>&1
if [ $? -ne 0 ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') CRITICAL: VPN tunnel to $GW_IP is down" >> $LOG_FILE
    exit 1
fi

# Проверка срока действия сертификата
EXPIRY=$(openssl x509 -enddate -noout -in $CERT | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))

if [ $DAYS_LEFT -lt 30 ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') WARNING: TLS certificate expires in $DAYS_LEFT days" >> $LOG_FILE
fi

# Проверка health-check эндпоинта
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --cert $CERT --key $KEY --cacert $CA $HC_URL)
if [ "$HTTP_CODE" != "200" ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') CRITICAL: Health-check returned HTTP $HTTP_CODE" >> $LOG_FILE
    exit 2
fi

echo "$(date '+%Y-%m-%d %H:%M:%S') OK: All checks passed" >> $LOG_FILE
exit 0

Добавьте в cron:

*/15 * * * * /usr/local/bin/egisz-health-check.sh

Скрипт пишет результат в лог-файл. Система мониторинга забирает оттуда строки с CRITICAL и отправляет уведомление дежурному администратору. Порог срабатывания - одно событие CRITICAL, так как интеграция с ЕГИСЗ критична для работы клиники.

Если вы планируете масштабное обновление инфраструктуры, используйте готовый шаблон чек-листа для планирования миграции IT-систем в 2026 году. Он поможет синхронизировать обновление МИС с требованиями ЕГИСЗ без потери совместимости.

Поделиться:
Сохранить гайд? В закладки браузера