Коротка відповідь: медичні дані проходять через чотири рівні стандартів. Стандарти обміну передають дані між системами: повідомлення 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 зберігає його, API FHIR надає його пацієнтському додатку після входу через 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 та Observation FHIR однаково.
Спробуйте безкоштовно в пісочниці
Перший запит FHIR за 5 хвилин. API стандарту HL7 FHIR R4 з вбудованою згодою пацієнта: спробуйте в пісочниці, а потім підключіть власну програму чи клінічну систему.
Безкоштовно · 30 синтетичних пацієнтів · без картки
Anpheros створює медичну карту, яку пацієнт контролює та може ділитися з будь-якою клінікою, на платформі HL7 FHIR R4, розташованій в ЄС. Ці посібники допоможуть вам зрозуміти та організувати своє здоров'я; вони не замінюють вашого лікаря.
Про Anpheros →