Обмен электронными медицинскими записями: интероперабельность

242-ФЗ о здравоохранении обязал российские медицинские организации использовать единую государственную информационную систему здравоохранения (ЕГИСЗ) для обмена медицинскими данными — однако в реальности большинство обменов по-прежнему происходит через несовместимые системы, требующие технической интеграции или ручной передачи файлов. Обмен электронными медицинскими записями через системы означает согласование как минимум четырёх стандартов: HL7 FHIR R4 для API-обмена, C-CDA R2.1 для документальной передачи, HL7 v2.x для устаревшего обмена сообщениями и DICOM для визуализации. Когда запись перемещается между системами электронных медицинских карт разных производителей, это, как правило, происходит через C-CDA-документы по профилям IHE XCA.

Стек стандартов в реальных условиях

Интероперабельность медицинских записей выглядит как смесь стандартов, потому что ею и является. Вот что делает каждый уровень:

HL7 v2.x — сообщения с разделителем вертикальной черты из 1990-х, всё ещё основная нагрузка для заказов анализов, ADT-сообщений и управления заказами внутри больницы. Не подходит для межорганизационного обмена.
C-CDA R2.1 — структурированные XML-документы, представляющие резюме пациента, выписную справку или направление. Основа обмена сообщениями Direct и большинства HIE-обменов.
HL7 FHIR R4 — RESTful ресурсы (Patient, Observation, Condition, MedicationRequest), передаваемые по HTTPS с JSON или XML. Современный слой, требуемый регуляторами для сертифицированных ЭМК.
DICOM — стандарт визуализации, проходящий через собственные каналы (DIMSE, DICOMweb).

Когда вы «делитесь ЭМК», вы на самом деле делитесь фрагментами из каждого уровня, собранными в правильный формат для получателя.

API и препятствия интероперабельности

Разработчику, интегрирующемуся с крупной ЭМК-системой, как правило, нужно:

Зарегистрировать приложение на портале разработчика вендора.
Использовать последовательность запуска SMART on FHIR с OAuth 2.0 и PKCE.
Запросить области видимости, такие как patient/*.read или конкретные ресурсы.
Получить JSON-пакеты по HTTPS.

Практическая проблема: области API, ограничения скорости и производственный доступ существенно различаются между вендорами. API для пациентов требует подписанного соглашения для многих конфигураций производственного доступа. Скорость доступа к тестовой среде у разных вендоров также различается.

C-CDA: всё ещё стандарт для межорганизационных резюме

Несмотря на рост FHIR, большинство межорганизационного обмена записями по-прежнему передаётся в виде C-CDA-документов. Документ о непрерывности помощи (CCD) по C-CDA R2.1 обычно занимает 200 КБ–2 МБ XML со встроенным HTML для удобочитаемости. Ключевые шаблоны:

CCD (Continuity of Care Document — Документ непрерывности помощи)
Discharge Summary (Выписная справка)
Referral Note (Направление)
Consultation Note (Заметка консультации)
Progress Note (Заметка прогресса)

Они проходят через Direct-обмен (S/MIME поверх SMTP) или запросный HIE-обмен. Качество парсинга варьируется — некоторые ЭМК чисто импортируют списки проблем, но теряют социальную историю. Согласование данных остаётся ручным шагом в большинстве клиник.

Когда API не справляются и нужна передача файлов

Несмотря на все стандарты, клиницисты регулярно сталкиваются с необходимостью переместить файл, который не вписывается ни в один API. Примеры:

300-мегабайтный PDF-пакет отсканированных бумажных записей, предшествующих переходу клиники на электронный документооборот
Исследовательский набор данных в формате SAS или Stata для ретроспективного обзора
Набор фотографий ран от службы домашнего медицинского обслуживания, которые не нужны на сервере изображений
Записи правового обеспечения по рассматриваемому делу о врачебной халатности

Для таких случаев используется зашифрованная передача файлов. Требования: шифрование AES-256-GCM в состоянии покоя, TLS 1.3 при передаче, журналирование аудита и истечение срока действия ссылки. То, является ли этот инструмент встроенной функцией ЭМК, одобренным больничным корпоративным сервисом или специальной браузерной передачей, зависит от вашего управления.

HexaTransfer предлагает специальный путь с клиентским шифрованием до загрузки. Попробуйте на hexatransfer.com — бесплатно, без учётной записи, максимум 50 ГБ. Зарегистрируйте передачу в стандартной записи аудита, чтобы впоследствии можно было её учесть.

Сопоставление пациентов и проблема идентификации

Обмен записью требует уверенности в том, что это запись нужного пациента. Разрешение идентификации опирается на вероятностное сопоставление по имени, дате рождения, полу, адресу и телефону. Показатели совпадения в производственных сетях составляют 70–95% в зависимости от качества данных. Ошибки в сопоставлении означают отсутствующие записи в точке помощи и дублирующиеся записи, загромождающие последующую карту.

В России использование СНИЛС (страхового номера индивидуального лицевого счёта) и номера полиса ОМС в качестве идентификаторов пациентов повышает точность сопоставления при межорганизационном обмене. Всегда включайте идентификаторы пациента в имя файла или сопроводительный лист — номер карты, дату рождения и хотя бы один дополнительный идентификатор.

Согласие, сегментация и особые категории данных

Не все записи передаются одинаково. Данные о ВИЧ-статусе, психиатрические записи, генетические данные и сведения о репродуктивном здоровье часто имеют специальные правила обмена. По 152-ФЗ и Приказу Минздрава России, сведения, составляющие врачебную тайну, требуют отдельного согласия пациента на раскрытие, за исключением случаев, прямо предусмотренных законом.

Если ваш инструмент передачи не может соблюдать сегментацию — не может пометить, какие части документа требуют дополнительного согласия, — не используйте его для психиатрических записей.

Аудит раскрытий

Пациенты имеют право на получение сведений о том, кому и когда раскрывались их медицинские данные. 152-ФЗ устанавливает право субъекта персональных данных на получение информации об операторах, обрабатывающих его данные. Журнал передач вашей системы обеспечивает этот учёт. Фиксируйте:

Временную метку в UTC
Организации отправителя и получателя
Код цели (ЛЕЧЕНИЕ, ИССЛЕДОВАНИЕ, УПРАВЛЕНИЕ и т.д.)
Категории переданных данных
Идентификатор пациента

Если вы полагаетесь на универсальный инструмент обмена файлами, регистрирующий только «пользователь X загрузил файл Y», вы окажетесь в затруднительном положении при запросе пациента.

Малые практики и разрыв в ресурсах

В небольшой врачебной практике нет ИТ-директора. Всем занимается офис-менеджер, совмещающий ИТ с выставлением счетов. При этом практика всё равно должна выдавать записи по запросу, подписывать соглашения о конфиденциальности с каждым вендором и обрабатывать жалобы пациентов на нарушения. Практический подход:

Используйте ЭМК, которая обрабатывает Direct, FHIR и API пациентов из коробки.
Выберите один специальный зашифрованный инструмент передачи для всего, что ЭМК не может отправить.
Задокументируйте рабочий процесс в одностраничном СОП.
Обучите каждого сотрудника двум инструментам, которыми они будут пользоваться еженедельно.

Обмен электронными медицинскими записями — это не проблема одного вендора. Это многоуровневый рабочий процесс для поддержания. Придерживайтесь стандартов там, где можете, и имейте чистый зашифрованный резервный вариант для случаев, которые стандарты не охватывают.