Краткий ответ: данные о здоровье перемещаются по четырем уровням стандартов. Стандарты обмена передают данные между системами: сообщения HL7 v2, документы CDA, ресурсы FHIR и DICOM для изображений. Стандарты моделирования и хранения определяют, как структурируется запись внутри системы: openEHR для клинических записей, OMOP для исследовательских баз данных. Терминологии присваивают каждому понятию код, понятный обеим сторонам: SNOMED CT, LOINC, ICD, ATC, UCUM, RxNorm. Стандарты идентификации и безопасности определяют, кто и что может читать: OAuth 2.0 и SMART on FHIR, а также профили IHE, которые объединяют все вышеперечисленное в проверенные решения. Никто не использует только один стандарт; больница обычно работает со всеми четырьмя уровнями одновременно.
Карта
Стандарты медицинской совместимости образуют четыре уровня. Стандарты обмена (HL7 v2, CDA, FHIR, DICOM и DICOMweb) перемещают данные между системами, а профили IHE объединяют их в проверенные решения. openEHR структурирует сохраненные записи, а OMOP — исследовательские базы данных. Внутри всех них используются терминологии, такие как SNOMED CT и LOINC, а также стандарты идентификации, такие как SMART on FHIR.
| Уровень | Стандарт | Что это | Где вы встретите в 2026 году |
|---|---|---|---|
| Обмен | HL7 v2 | Сообщения, разделенные символом " | " (ADT, ORU, ORM, SIU) через MLLP |
| Обмен | CDA / C-CDA | XML-документы с человекочитаемой частью и кодированными записями | Выписные эпикризы, направления, US C-CDA, трансграничные сводки в MyHealth@EU |
| Обмен | FHIR (R4, R4B, R5) | Веб-ресурсы (Patient, Observation, Condition…) через REST и JSON | Приложения для пациентов, национальные API, API медицинских информационных систем, US Core, формат обмена EHDS |
| Обмен | DICOM и DICOMweb | Объекты изображений со встроенными метаданными; DICOMweb — это его REST-интерфейс | Каждый сканер, PACS и средство просмотра радиологических изображений; веб-просмотрщики используют DICOMweb |
| Решения | Профили IHE | Проверенные комбинации вышеперечисленного для конкретного случая использования (XDS, PIX/PDQ, XCA, SWF) | Обмен документами между больницами и регионами, идентификация пациентов, рабочий процесс радиологии |
| Хранение | openEHR | Клиническая модель данных на основе архетипов для самой записи | Больничные и национальные платформы медицинских информационных систем в частях Европы, Скандинавии, Бразилии |
| Исследования | OMOP CDM | Общая реляционная модель для наблюдательных исследований | Исследовательские сети, данные реальной клинической практики, вторичное использование EHDS |
| Терминология | SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM | Коды для результатов, тестов, диагнозов, лекарств, единиц измерения | Внутри каждого из вышеперечисленных стандартов |
| Идентификация | OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA | Кто такой пользователь и к чему приложение имеет доступ | Каждое приложение для пациентов и каждая платформа приложений медицинских информационных систем |
Как уровни сочетаются друг с другом
Уровни стандартов медицинской совместимости работают вместе, выполняя одну задачу в одном и том же рабочем процессе: сообщение HL7 v2 передает лабораторный заказ, LOINC и UCUM кодируют результат, платформа openEHR сохраняет его, FHIR API предоставляет его приложению пациента после входа через SMART on FHIR, а документ CDA передает его в другую больницу.
Анализ крови демонстрирует все четыре уровня за один день. Заказ покидает отделение в виде сообщения HL7 v2 ORM (обмен). Результат анализатора возвращается как HL7 v2 ORU, с тестом, закодированным в LOINC, а единица измерения — в UCUM (терминология). Больница сохраняет его в своей базе данных, возможно, на платформе openEHR (хранение). Приложение пациента считывает его через API FHIR как Observation, после того как пациент вошел в систему с помощью SMART on FHIR (идентификация). Если больница передает полный отчет другой больнице, она может сделать это в виде документа CDA через реестр IHE XDS. Если результат позже попадает в исследовательскую когорту, он преобразуется в OMOP.
Стандарты не являются конкурентами. Каждый был создан для разных задач, и замена одного другим обычно означает перестройку чего-то, что уже работает.
Какой вам нужен?
Какой стандарт медицинской совместимости вам нужен, зависит от задачи: FHIR R4 с SMART on FHIR для приложений пациентов или врачей, HL7 v2 для подключения к существующим больничным системам, DICOM и DICOMweb для изображений, документы CDA или FHIR для полных документов, openEHR для долговременного хранения записей, OMOP для исследований и профили IHE, когда две системы должны работать идентично.
- Вы создаете приложение для пациентов или врачей: FHIR R4, с профилями вашего рынка (руководства по внедрению), SMART on FHIR для входа.
- Вы подключаетесь к существующим системам больницы: ожидайте в первую очередь HL7 v2; FHIR, если поставщик предлагает его. См. Сообщения HL7 v2 объяснены.
- Вы работаете с изображениями: DICOM для хранения и передачи, DICOMweb для всего, что в браузере, FHIR ImagingStudy только для метаданных. См. DICOMweb объяснен и ImagingStudy против DICOMweb.
- Вы обмениваетесь полными документами (сводки, письма): CDA, где это предписано, документы FHIR (Bundle типа
document), где вы можете выбрать. См. CDA и C-CDA объяснены. - Вы проектируете, как запись хранится десятилетиями: openEHR, с FHIR в качестве уровня обмена. См. openEHR против FHIR.
- Вы проводите исследования на множестве записей: OMOP, с FHIR в качестве источника. См. Вторичное использование медицинских данных.
- Вам нужно, чтобы две системы вели себя одинаково: выберите профиль IHE для вашего случая использования и протестируйте его.
Где находится Anpheros
Платформа Anpheros находится на уровне обмена в карте стандартов как FHIR R4 сервер с доступом OAuth 2.0 и веб-хуками для уведомлений об изменениях, получая лабораторные результаты через коннектор из HL7 v2 ORU, CSV или JSON. Она не хранит DICOM-изображения и не предлагает сервис CDS Hooks; они остаются в больничных системах.
Anpheros Platform — это сервер FHIR R4 с ресурсами, необходимыми для ориентированной на пациента записи (Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenance и другие), OAuth 2.0 для доступа и веб-хуками для уведомлений об изменениях. Результаты лабораторных исследований поступают через коннектор лаборатории из HL7 v2 ORU, CSV или JSON. Он не хранит изображения DICOM и не предлагает службу CDS Hooks; они остаются в системах больницы, а запись на них ссылается.
Порядок чтения
Хороший порядок чтения стандартов медицинской совместимости начинается с того, что такое FHIR и чем он отличается от HL7 v2, затем ресурс FHIR Observation, затем терминологии LOINC и SNOMED CT, используемые внутри него, затем DICOMweb для изображений, CDA для документов и, наконец, openEHR по сравнению с FHIR для способов хранения записей.
Если вы новичок в этой области: Что такое FHIR → HL7 против FHIR → FHIR Observation → LOINC и SNOMED CT → DICOMweb → CDA → openEHR против FHIR.
Связанные страницы
- HL7 против FHIR
- Сообщения HL7 v2 объяснены
- CDA и C-CDA объяснены
- DICOMweb объяснен
- openEHR против FHIR
- Руководства по внедрению FHIR
- FHIR R4 против R5
- Что такое код LOINC?
- Что такое SNOMED CT?
- DICOM против FHIR для разработчиков
- Профили и расширения FHIR объяснены
- Серверы терминологии FHIR объяснены
- Карта регулирования медицинских данных
- Национальные электронные медицинские карты в Европе и США
- Интеграция больничных систем объяснена
- ИИ на медицинских данных
- Вторичное использование медицинских данных
- Безопасность и идентификация в медицинских приложениях
Источники
- HL7 International: стандарты
- Спецификация HL7 FHIR R4
- Стандарт DICOM, текущая версия
- Технические фреймворки IHE
- Спецификации openEHR
- OHDSI OMOP Common Data Model
- SMART App Launch
Частые вопросы
Заменяет ли FHIR все остальные стандарты?
Нет. FHIR заменяет пользовательские API и, медленно, некоторый обмен документами CDA. HL7 v2 остается рабочим инструментом внутри больниц, DICOM остается единственным стандартом для изображений, а openEHR и OMOP отвечают на вопросы (хранение, исследования), для которых FHIR не был разработан.
В чем разница между стандартом и профилем IHE?
Стандарт, такой как FHIR или DICOM, определяет строительные блоки. Профиль IHE выбирает конкретные блоки, фиксирует их параметры и точно указывает, как системы должны их использовать для одной задачи, чтобы два поставщика, прошедшие тесты IHE, могли работать вместе без проекта.
Какие стандарты используют национальные системы здравоохранения?
Большинство европейских систем начинали с документов CDA и HL7 v2 и добавляют API FHIR; формат обмена EHDS построен на FHIR и IPS. США предписывают FHIR US Core для доступа пациентов и C-CDA для обмена документами.
Где находятся SNOMED CT и LOINC?
Это не стандарты обмена; это словари, используемые внутри всех них. Код LOINC идентифицирует тест в сегменте HL7 v2 OBX, записи CDA и FHIR Observation одинаково.
Попробуйте бесплатно в песочнице
Первый запрос FHIR за 5 минут. API HL7 FHIR R4 с встроенным согласием пациента: попробуйте в песочнице, затем подключите свое приложение или систему клиники.
Бесплатно · 30 синтетических пациентов · без карты
Anpheros создает медицинскую карту, которую пациент контролирует и может делиться с любой клиникой, на платформе HL7 FHIR R4, базирующейся в ЕС. Эти руководства помогут вам понять и организовать свое здоровье; они не заменяют вашего врача.
О Anpheros →