# FHIR против пользовательской медицинской базы данных

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

Source: https://developers.anpheros.com/ru/guides/fhir-vs-custom-database

**Команда, начинающая медицинский продукт, обычно сталкивается с одним и тем же выбором на раннем этапе: спроектировать собственные таблицы для пациентов, измерений и диагнозов в PostgreSQL или другой базе данных, или с самого начала хранить медицинские данные в виде ресурсов HL7 FHIR R4.** Пользовательская схема быстрее в первый день и точно соответствует вашему продукту. FHIR требует больше размышлений на начальном этапе и окупается каждый раз, когда данные должны покинуть вашу систему, пройти аудит, быть переданы с согласия или прочитаны кем-то, кто не вы. Эта страница честно излагает компромиссы, с одним и тем же чтением, хранящимся обоими способами, и говорит, когда каждый выбор правильный.

Это отличается от вопроса о том, *какой* FHIR-сервер использовать. Для этого см. [Как Anpheros сравнивается с другими FHIR-серверами](https://developers.anpheros.com/ru/guides/fhir-server-comparison).

## Одно и то же измерение, два способа представления

Измерение артериального давления в пользовательской схеме:

```sql
CREATE TABLE bp_readings (
  id          uuid PRIMARY KEY,
  user_id     uuid REFERENCES users(id),
  systolic    int,
  diastolic   int,
  measured_at timestamptz,
  created_at  timestamptz DEFAULT now()
);
```

Просто, быстро для запросов, именно то, что нужно приложению. Затем возникают вопросы, на которые таблица не дает ответа:

- Какое устройство или человек произвел значение? Было ли оно введено пациентом, измерено манжетой или внесено медсестрой?
- Каким было значение до того, как кто-то его исправил, и кто его исправил?
- Как его прочитает системный клиник, лаборатория или страховщик? Что означает `systolic` в их системе?
- Как пациент поделится им с приложением своего врача и прекратит делиться им в следующем месяце?
- Когда вы добавляете частоту сердечных сокращений, вес, HbA1c и еще 200 измерений, это 200 таблиц или одна универсальная таблица, которую вы разрабатываете сами?

То же измерение в формате FHIR R4:

```json
{"resourceType": "Observation", "status": "final",
 "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs"}]}],
 "code": {"coding": [{"system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel"}]},
 "subject": {"reference": "Patient/d09e3942-…"}, "effectiveDateTime": "2026-10-10T08:30:00Z",
 "component": [
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}, "valueQuantity": {"value": 138, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}},
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}, "valueQuantity": {"value": 88, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}}],
 "meta": {"versionId": "1"}}
```

Более многословно, но каждая часть имеет значение, общее для любой системы FHIR: LOINC указывает, что было измерено, UCUM — единицу измерения, `meta.versionId` начинает историю, а та же форма `Observation` содержит остальные 200 измерений. С Anpheros ресурс `Provenance` также записывает, кто его создал. [Как хранить медицинские записи с использованием FHIR R4](https://developers.anpheros.com/ru/guides/store-medical-records-fhir) подробно описывает этот процесс.

## Параллельное сравнение

| | Пользовательская схема | FHIR R4 |
|---|---|---|
| Время до первого использования функции | часы | день или два на изучение ресурсов |
| Соответствие вашему продукту | точное | общее; представление вашего продукта накладывается сверху |
| Добавление нового типа данных | миграция для каждого типа | обычно новый код в существующем ресурсе |
| Значение вне вашей системы | отсутствует без сопоставления | общие коды (LOINC, ICD-10, ATC, UCUM) |
| История и исправления | вы проектируете | версии и `_history` по дизайну |
| Кто что написал | вы проектируете | `Provenance` (автоматически в Anpheros) |
| Обмен с клиниками, лабораториями, другими приложениями | индивидуальная интеграция каждый раз | FHIR R4 API, импорт HL7 v2, International Patient Summary |
| Согласие пациента на приложение | вы проектируете | области действия SMART on FHIR и OAuth |
| Запросы для аналитики | обычный SQL | поиск FHIR или экспорт в ваш склад данных |
| Регулирование (Статья 9 GDPR, EHDS) | вы документируете каждую часть | стандартные форматы, на которые ссылается регулирование |

## Когда пользовательская схема — правильный выбор

- **Данные не являются медицинскими или не относятся к одному человеку.** Планы обучения, контент, каталог продуктов: используйте свои собственные таблицы.
- **Краткосрочный прототип** для проверки спроса на продукт с использованием синтетических данных и планом миграции.
- **Данные плохо соответствуют стандартным моделям**, например, новое исследовательское измерение. FHIR все еще может их содержать (`Observation` с вашей собственной системой кодирования или `Basic`), но пользовательская таблица может быть более понятной.
- **Интенсивная аналитика.** Даже при использовании FHIR в качестве системы записи, большинство команд копируют данные в хранилище данных в собственной структуре для отчетности.

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

- Данные представляют собой медицинскую карту человека: измерения, диагнозы, лекарства, аллергии, результаты лабораторных исследований, документы.
- Данные будут покидать вашу систему: пациенту, врачу, клинике, лаборатории, страховщику, модели ИИ или конкуренту при переезде пациента.
- Вам необходимо отслеживать, кто что записал и что изменилось: аудит, клиническая безопасность, разрешение споров.
- Пациенты будут предоставлять и отзывать доступ для каждого приложения.
- Вы продаете в Европейском Союзе, где Европейское пространство данных о здоровье (European Health Data Space) ожидает, что записи будут обмениваться в стандартных форматах.

## Обычный средний путь

Большинство продуктов в итоге используют оба подхода, разделяя данные по типу:

```
your database                         FHIR record (Anpheros)
─────────────                         ──────────────────────
users, sessions, settings             Patient
subscriptions, billing                Observation, Condition, MedicationStatement
product content, feature flags        AllergyIntolerance, Immunization, DocumentReference
user id → patient id (one column)     Provenance, Consent, history
caches and analytics copies  ◄─────── webhooks
```

Ваша база данных остается небольшой и соответствует форме продукта. Медицинская карта стандартизирована, версионирована и доступна для обмена, и вам не пришлось ее создавать. [Бэкенд и база данных медицинского приложения](https://developers.anpheros.com/ru/guides/medical-app-backend) подробно описывает это разделение, а [Как создать API для здравоохранения с помощью TypeScript](https://developers.anpheros.com/ru/guides/healthcare-api-typescript) реализует его.

## Что нужно для самостоятельной разработки FHIR

Выбор FHIR не означает написание FHIR-сервера с нуля. Ваши варианты: запуск open-source сервера, использование FHIR-хранилища облачного провайдера, open-source медицинской платформы или управляемой медицинской базы данных, такой как Anpheros. Они различаются тем, кто отвечает за управление согласиями, аудитом, происхождением данных, размещением и интеграциями, что подробно описано в [Сравнение Anpheros с другими FHIR-серверами](https://developers.anpheros.com/ru/guides/fhir-server-comparison).

## Часто задаваемые вопросы

### Является ли FHIR базой данных?
Нет. FHIR — это стандарт для структуры и обмена медицинскими данными: ресурсов, кодов и REST API. FHIR-сервер или управляемая FHIR-база данных хранит ресурсы и реализует API поверх реальной базы данных.

### Могу ли я самостоятельно хранить FHIR-ресурсы в PostgreSQL?
Да, в виде JSON-колонок с вашими собственными индексами, и некоторые open-source серверы делают именно это. Работа заключается во всем, что связано с хранением: параметрах поиска, версионировании, ссылках, валидации, контроле доступа по пациентам и происхождении данных.

### Могу ли я начать с пользовательской схемы и перейти на FHIR позже?
Можете, и многие команды так делают, но миграция — это проект по сопоставлению: каждая таблица нуждается в кодах, единицах измерения и авторах, которые она никогда не записывала. Хранение медицинских данных в формате FHIR с первой же функции обходится дешевле, чем их последующее преобразование.

### Нужен ли мне FHIR для соблюдения GDPR?
Нет. GDPR не требует определенного формата. FHIR упрощает выполнение нескольких обязательств: переносимость (запись экспортируется в стандартном формате), контроль доступа по назначению и отображение того, кто обрабатывал какие данные.

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

- [Схема базы данных FHIR](https://developers.anpheros.com/ru/guides/fhir-database-schema): как ресурсы FHIR хранятся и индексируются
- [Как хранить медицинские записи с использованием FHIR R4](https://developers.anpheros.com/ru/guides/store-medical-records-fhir)
- [Платформа FHIR](https://developers.anpheros.com/ru/guides/fhir)
- [Сравнение Anpheros с другими серверами FHIR](https://developers.anpheros.com/ru/guides/fhir-server-comparison)
- [Бэкенд и база данных медицинских приложений](https://developers.anpheros.com/ru/guides/medical-app-backend)
- [API для здравоохранения](https://developers.anpheros.com/ru/guides/healthcare-api)