Этот пост написала Гита Викрам, менеджер по интеграции в Redox.

Если вы работаете в сфере медицинских технологий, вы наверняка слышали о FHIR (произносится как «файер»). Это название всплывает в любой дискуссии, связанной с медицинскими данными: в звонках по продажам, при проверках безопасности и в ветках Slack, где кто-то спрашивает: «подождите, разве мы не можем просто получить поток HL7?». FHIR — это краеугольный камень того, как работает здравоохранение, но попытка вникнуть в детали может показаться пугающей. Если это про вас, знайте: вы не одиноки, и вам не нужно инженерное образование, чтобы лучше в этом разобраться.

Вот версия на простом языке. (ПРИМЕЧАНИЕ: это краткая шпаргалка по курсу FHIR101 от Out-of-Pocket Health и Redox за август 2026 года. Начните с этого, а затем посмотрите видео по запросу для получения экспертных рекомендаций и комментариев).

Во-первых, «алфавитный суп»

У стандартов медицинских данных длинное и запутанное генеалогическое древо, и большая часть путаницы начинается именно здесь. Все восходит к одной организации: HL7 (Health Level Seven), органу по стандартизации, который с 1980-х годов определяет, как медицинские данные перемещаются между системами.

За эти годы HL7 выпустила несколько основных стандартов:

HL7v2: оригинальный стандарт обмена сообщениями. Именно так больницы десятилетиями обменивались данными, такими как поступления и выписки (сообщения ADT). Он старый, немного громоздкий, но до сих пор работает в производственных средах больниц по всему миру.

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

FHIR (Fast Healthcare Interoperability Resources): современный стандарт, созданный для веба, на котором сегодня строится большинство новых интеграционных проектов.

Итак, HL7 — это организация. HL7v2, HL7v3 и FHIR — это три разных продукта, созданных ею, каждый из которых выполняет свою задачу.

Что на самом деле означает FHIR?

FHIR — это полезная аббревиатура не только потому, что она порождает бесконечное количество мемов и каламбуров, но и потому, что каждая буква описывает нечто реальное в том, как он работает:

Fast (Быстрый): построен на стандартных REST/веб-технологиях (те же шаблоны, которые разработчики используют для любого современного API), поэтому интеграция занимает дни, а не месяцы, которые обычно требуются для создания пользовательских интерфейсов HL7v2 или разбора документов CDA.

Healthcare (Здравоохранение): разработан специально для «грязных», реальных клинических данных.

Interoperability (Интероперабельность): главная цель — системы обмениваются данными без трений.

Resources (Ресурсы): данные поступают небольшими, модульными, самодостаточными пакетами.

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

Push против pull: ментальная модель, которая важнее всего

Самый простой способ отличить эти стандарты — не по аббревиатуре, а по тому, как перемещаются данные.

HL7v2 — это push (отправка). Данные находят вас. Больничная система отправляет сообщение, когда что-то происходит (пациент поступил, готов результат анализа), а ваша система должна «слушать».

CDA — это снимок. Это документ, фиксирующий момент времени, как PDF со структурой.

FHIR — это pull (запрос). Вы запрашиваете именно то, что вам нужно, когда вам это нужно. Нужен список аллергий пациента? Запросите ресурс AllergyIntolerance. Вот и все.

FHIR совершил переход от модели «жди, пока данные придут» к модели «запрашивай то, что нужно».

10 ресурсов, которые покрывают 80% случаев использования

FHIR определяет множество типов ресурсов, но вам не нужно запоминать их все. Эти десять покрывают подавляющее большинство реальных сценариев:

Зная эти десять, вы сможете следить за подавляющим большинством разговоров об интеграции на базе FHIR.

Еще несколько терминов, которые стоит знать

Bundle (Пакет): набор из нескольких ресурсов, возвращаемых вместе, например, результат поиска. Также используется для пакетных и транзакционных запросов.

Versioning (Версионность): FHIR меняется со временем! R4 — это сегодняшний стандарт. R5 существует, но его внедрение еще на ранней стадии; R6 все еще проходит процесс голосования в HL7.

Implementation Guide (IG, Руководство по внедрению): набор правил, построенных поверх базовой спецификации FHIR для конкретного случая использования. US Core и Da Vinci — два руководства, о которых вы будете слышать чаще всего. (Стоит отметить: USCDI — это отдельный термин, который легко перепутать. Это не продукт FHIR и не IG вообще, это политика федерального правительства США, написанная простым языком, которая определяет, какие медицинские данные должны быть доступны для обмена. Люди часто предполагают, что USCDI и US Core — это одно и то же, поскольку названия выглядят связанными, но это разные проекты, которые случайно пересекаются по охвату).

Profiles (Профили): настройка ресурса для конкретного случая использования, например, профиль US Core Patient. FHIR — это строительный кодекс города. IG — это ассоциация домовладельцев, которая запрещает пластиковых фламинго во дворе и требует одинаковые почтовые ящики — более узко и специфично.

Cardinality (Кардинальность): обозначение минимума и максимума для поля, например 0..1 или 1..*. Первое число говорит вам, является ли поле обязательным; второе говорит, сколько значений разрешено. * означает необязательное, повторяемое. Профили могут еще больше ужесточить это.

Почему «одинаковый» поток FHIR везде выглядит по-разному

Вот часть, на которой все спотыкаются: две организации могут обе заявить «мы поддерживаем FHIR» и все равно потребовать индивидуальной реализации. Гибкость FHIR — это одновременно и функция, и баг. Он должен работать как для ветеринарной клиники в Новой Зеландии (да, FHIR охватывает и животных!), так и для акупунктуриста в Финляндии и травматологического центра 1-го уровня в Чикаго. Но эта гибкость может стать головной болью для тех, кто занимается внедрением.

Вариативность проявляется в трех местах:

Между EHR (электронными медицинскими картами). Epic, Oracle Health, athenahealth и т. д. — каждая из них предоставляет разные ресурсы и методы аутентификации.

Между версиями. Организации обновляются по своим собственным графикам, поэтому не все используют одну и ту же версию спецификации.

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

Это реальная причина, по которой интероперабельность в здравоохранении остается сложной задачей, даже при наличии современного стандарта, такого как FHIR. Стандарт дает всем общий язык. Он не гарантирует, что все говорят на нем одинаково.

Держите это под рукой

Все вышесказанное — краткая версия. Скачайте шпаргалку FHIR 101, чтобы иметь под рукой одностраничный справочник, который можно открыть в любой момент, когда кто-то в середине встречи бросается аббревиатурами: разбор «алфавитного супа», 10 ресурсов, которые нужно знать, и краткие факты о версионности, профилях и кардинальности — все в одном месте. Когда будете готовы к полному курсу 101 — посмотрите видео по запросу!