# Як Anpheros порівнюється з іншими FHIR серверами

> Самостійно розміщені FHIR сервери, хмарні сховища FHIR, відкриті медичні платформи та Anpheros пліч-о-пліч: хто авторизує доступ, згоду, походження, резидентність, ціноутворення та коли кожен з них є правильним вибором.

Source: https://developers.anpheros.com/uk/guides/fhir-server-comparison

**Команди, які обирають FHIR бекенд, зазвичай зважують чотири види варіантів: сервер з відкритим кодом, який вони розміщують самостійно, кероване сховище FHIR від хмарного провайдера, медична платформа з відкритим кодом з керованою версією, або керована медична база даних, як-от Anpheros.** Цей посібник описує, на що кожен тип придатний і де знаходиться Anpheros, на основі загальнодоступної документації станом на жовтень 2026 року. Для будь-якого згаданого тут продукту перевіряйте його власну документацію; функції змінюються.

## Чотири види

| | Самостійно розміщений FHIR-сервер (наприклад, HAPI FHIR) | Хмарне сховище FHIR (наприклад, Google Cloud Healthcare API, Azure Health Data Services, AWS HealthLake) | Платформа охорони здоров'я (наприклад, Medplum) | Anpheros |
|---|---|---|---|---|
| Що це | FHIR-сервер, який ви запускаєте | Сховище даних FHIR у хмарному обліковому записі | Платформа додатків на основі FHIR з автентифікацією, робочими процесами та розміщеною версією | Керована база даних охорони здоров'я: запис FHIR R4 на пацієнта, згода, API, аудит |
| Хто авторизує доступ | все, що ви побудуєте навколо нього | IAM хмари, за проєктом або набором даних | Політики доступу платформи, налаштовані вами | Пацієнт (згода OAuth 2.1) або організація (API ключ) |
| Згода та аудит, орієнтовані на пацієнта | ні | ні | Можна створити за допомогою моделі політик | Вбудовано, видно пацієнту |
| Походження кожного запису | якщо ви додасте | якщо ви додасте | Підтримується FHIR; ви забезпечуєте це | Вимагається та автоматично |
| Ізоляція ідентифікаторів між додатками | ні | ні | ні | Попарні ідентифікатори для кожного додатка |
| Імпорт лабораторних даних (HL7 v2) | окремі інструменти | частково (відображення v2 на FHIR у деяких сховищах) | інтеграції, які ви пишете | Вбудовано, один запит |
| Резидентність даних | де б ви його не розмістили | регіони, які пропонує провайдер | залежить від розміщення | Тільки Європейський Союз |
| Ціноутворення | ваша інфраструктура та час | на основі використання (запити, зберігання) | за планом або самостійно розміщено | за організацію, за збережених пацієнтів |
| Найкраще для | навчання, повний контроль, незвичайні моделі даних | команди, які вже використовують цю хмару і самостійно створять рівень охорони здоров'я | команди, які хочуть будувати на відкритому коді та володіти повним стеком | команди, які хочуть, щоб рівень охорони здоров'я був готовий, а продукт був їхньою роботою |

## Google Cloud Healthcare API чи керована платформа?

Продукт Google називається Cloud Healthcare API, тому він з'являється першим у багатьох пошукових запитах за запитом "healthcare API". Це хмарне сховище FHIR (плюс сховища HL7 v2 та DICOM) у вашому проєкті Google Cloud: зберігання, пошук FHIR та доступ на основі IAM, оплата за використання. Решту ви створюєте самі — згоду пацієнта та аудит, ізоляцію додатків, імпорт лабораторних даних, SDK та пісочницю з тестовими даними. Anpheros надає ці компоненти та зберігає дані в ЄС; він не надає вам сховище FHIR у вашому власному хмарному обліковому записі. Вибирайте залежно від того, хто має володіти рівнем медичних даних: ваша команда (Cloud Healthcare API) чи платформа (Anpheros).

## Відкритий FHIR-сервер чи керований?

Сервери з відкритим кодом, такі як HAPI FHIR, працюють будь-де (доступні Docker-образи) і підтримують повну специфікацію FHIR, з вашими власними профілями та розширеннями. Запуск такого сервера у виробничому середовищі означає самостійне керування базою даних, оновленнями, безпекою, резервним копіюванням та рівнем доступу. Керована платформа обмінює частину цієї свободи (Anpheros зберігає 26 типів ресурсів) на відсутність необхідності керувати ним. Дивіться [схему бази даних FHIR](https://developers.anpheros.com/uk/guides/fhir-database-schema) для розуміння того, що зберігає такий сервер під капотом.

## Коли Anpheros є правильним вибором

- Ви створюєте продукт для пацієнтів, клінік, лабораторій або ШІ, і хочете зосередитись на написанні продукту, а не на роботі з записами.
- Згода пацієнта та аудит, який пацієнт може переглядати, є обов'язковими вимогами, а не бажаними доповненнями (GDPR Стаття 9, EHDS).
- Ваші дані повинні залишатися в межах Європейського Союзу.
- Вам потрібен FHIR R4, а також простіший REST-інтерфейс, SDK та вебхуки від одного постачальника.
- Ви хочете почати безкоштовно, у пісочниці з реалістичними синтетичними пацієнтами, і перейти до продакшену без переписування.

## Коли кращий інший варіант

- Вам потрібні типи ресурсів FHIR, профілі або розширення, що виходять за межі 26, які підтримує Anpheros, або повністю власна модель даних: самостійно розміщений сервер надає вам таку свободу.
- Ваша організація вимагає, щоб усе було в одному хмарному обліковому записі з міркувань відповідності: хмарне сховище FHIR відповідає цій політиці.
- Ви хочете володіти та модифікувати весь стек, включаючи сервер авторизації та компоненти UI: платформа з відкритим кодом розроблена для цього.
- Вам потрібні EHR launch, Bulk Data export або `system/` scopes сьогодні: Anpheros їх ще не пропонує (див. [Як реалізувати згоду пацієнта за допомогою SMART on FHIR](https://developers.anpheros.com/uk/guides/smart-on-fhir-backend)).

## Справедливий спосіб прийняти рішення

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

## Пов'язане

- [Платформа API для охорони здоров'я: що вона включає та як вибрати](https://developers.anpheros.com/uk/guides/healthcare-api-platform): питання, які варто поставити будь-якому постачальнику
- [FHIR проти власної медичної бази даних](https://developers.anpheros.com/uk/guides/fhir-vs-custom-database): коли розробляти власні таблиці, а коли використовувати FHIR
- [Безкоштовна база даних FHIR та пісочниця](https://developers.anpheros.com/uk/guides/free-fhir-database)
- [Платформа FHIR](https://developers.anpheros.com/uk/guides/fhir)
- [Бекенд та база даних для медичних додатків](https://developers.anpheros.com/uk/guides/medical-app-backend)
- [Стартапи в галузі охорони здоров'я](https://developers.anpheros.com/uk/guides/healthcare-startups)
- [Безпека, конфіденційність та місцезнаходження даних](https://developers.anpheros.com/uk/guides/security)