Этот пост был написан Гитой Викрам, менеджером по интеграции в 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/web (те же шаблоны, которые разработчики используют для любого современного 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 — смотрите видео по запросу!
