# Сравнение Anpheros с другими FHIR-серверами

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

Source: https://developers.anpheros.com/ru/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).

## Open-source FHIR-сервер или управляемый?

Open-source серверы, такие как HAPI FHIR, работают где угодно (доступны Docker-образы) и поддерживают полную спецификацию FHIR, с вашими собственными профилями и расширениями. Запуск такого сервера в продакшене означает самостоятельное управление базой данных, обновлениями, безопасностью, резервным копированием и уровнем доступа. Управляемая платформа обменивает часть этой свободы (Anpheros хранит 26 типов ресурсов) на отсутствие необходимости в самостоятельном управлении. См. [схему базы данных FHIR](https://developers.anpheros.com/ru/guides/fhir-database-schema), чтобы узнать, что хранится под капотом такого сервера.

## Когда Anpheros — правильный выбор

- Вы создаете продукт для пациентов, клиник, лабораторий или ИИ и хотите сосредоточиться на разработке продукта, а не на работе с записями.
- Согласие пациента и возможность аудита, доступного для чтения пациентом, являются обязательными требованиями, а не желательными дополнениями (Статья 9 GDPR, EHDS).
- Ваши данные должны оставаться в Европейском Союзе.
- Вам нужен FHIR R4, а также более простой REST-интерфейс, SDK и вебхуки от одного поставщика.
- Вы хотите начать бесплатно, в песочнице с реалистичными синтетическими пациентами, и перейти на продакшн без переписывания кода.

## Когда другой вариант лучше

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

## Справедливый подход к принятию решения

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

## Связанные материалы

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