# Схема базы данных FHIR

> Как хранить ресурсы FHIR: нормализованные таблицы против JSON с поисковыми индексами против графа, схема PostgreSQL, которую использует Anpheros (ресурсы, история, типизированные индексы, проекции), и важные правила.

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

**База данных FHIR хранит ресурсы HL7 FHIR, чтобы их можно было читать, искать и версионировать через FHIR API; наиболее распространенная схема хранит каждый ресурс в виде JSON и заполняет отдельные индексные таблицы для параметров поиска, вместо того чтобы распределять каждый элемент по нормализованным реляционным таблицам.** На этой странице объясняются три обычных дизайна, схема, которую Anpheros использует в PostgreSQL, и когда вам не следует создавать свою собственную.

## Три способа хранения FHIR

<!-- visual:schema-compare -->

 FHIR-ресурсы являются глубокими, опциональными и расширяемыми: один ресурс Observation имеет десятки элементов, выбор типов (`value[x]`), повторяющиеся кодировки и расширения. Нормализация этого в реляционные столбцы означает миграцию при каждом добавлении поля в профиль. Хранение ресурса в виде JSON сохраняет все допустимое без изменений; индексные таблицы делают его доступным для поиска.

## Схема Anpheros

<!-- visual:schema-stack -->

| Таблица | Одна строка на | Ключевые столбцы |
|---|---|---|
| `fhir_resources` | текущая версия ресурса | `resource_type`, `id`, `patient_id`, `version`, `json` (полный ресурс), `last_updated`, `deleted`, а также столбцы provenance |
| `fhir_history` | каждая когда-либо записанная версия | `resource_type`, `id`, `version`, `json`, `last_updated` |
| `idx_token` | значение для поиска по коду или идентификатору | system, code — для `code`, `category`, `identifier`, `status` |
| `idx_string` | значение для текстового поиска | нормализованный текст — для имен и свободного текста |
| `idx_date` | значение для поиска по дате | начало и конец диапазона — для `date`, `onset-date`, `birthdate` |
| `idx_reference` | значение для поиска по ссылке | target type и id — для `patient`, `subject`, `encounter` |
| `idx_quantity` | значение для поиска по количеству | value, system, unit — для `value-quantity` |
| `proj_observations`, `proj_conditions`, `proj_medications` | ресурс, развернутый | столбцы, по которым фильтрует простой REST API |

При каждой записи платформа проверяет ресурс, записывает новую версию в `fhir_resources` и `fhir_history`, заменяет строки индекса и проекции, а также записывает Provenance. Поиск, такой как `Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01`, становится объединением по `idx_reference`, `idx_token` и `idx_date`; результат возвращает сохраненный JSON в том виде, в котором он был записан.

## Важные правила проектирования

- **Индексируйте только объявленные параметры поиска** и отклоняйте неизвестные с кодом `400`, вместо того чтобы молча игнорировать их.
- **Никогда не обновляйте на месте без истории**: исправления должны сохранять ранее известную информацию.
- **Мягкое удаление**: удаленный ресурс исчезает из результатов чтения и поиска, но его версии остаются для аудита.
- **Столбец "пациентский отсек"**: хранение `patient_id` в каждом ресурсе удешевляет `$everything`, фильтры согласия и изоляцию по пациентам.
- **Проверяйте перед сохранением**: недопустимый JSON в хранилище нарушит работу всех последующих читателей.

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

### Какая база данных лучше всего подходит для FHIR?
Большинство продакшн-серверов FHIR используют реляционную базу данных, такую как PostgreSQL, с ресурсами, хранящимися в формате JSON (JSONB), а параметры поиска индексируются в отдельных таблицах. Это сочетает гибкое хранение с быстрым, стандартным поиском.

### Следует ли нормализовать ресурсы FHIR в реляционные таблицы?
Обычно нет для основного хранилища. Нормализованные таблицы подходят для отчетности; сохраняйте их как проекции, построенные из хранимых ресурсов, как это делает Anpheros для своего более простого REST API.

### Как HAPI FHIR хранит ресурсы?
JPA-сервер HAPI FHIR также хранит каждую версию ресурса как сериализованный JSON и хранит параметры поиска в отдельных индексных таблицах. Дизайн Anpheros следует тому же принципу.

### Нужно ли мне создавать FHIR-базу данных самостоятельно?
Только если вам нужен полный контроль над профилями и типами ресурсов. В противном случае управляемая FHIR-платформа предоставит вам хранилище, поиск, историю, согласие и аудит без необходимости управления схемой.

<!-- visual:cta-schema -->

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

- [FHIR против пользовательской медицинской базы данных](https://developers.anpheros.com/ru/guides/fhir-vs-custom-database)
- [Как хранить медицинские записи, используя FHIR R4](https://developers.anpheros.com/ru/guides/store-medical-records-fhir)
- [Бесплатная база данных FHIR и песочница](https://developers.anpheros.com/ru/guides/free-fhir-database)
- [Сравнение Anpheros с другими FHIR-серверами](https://developers.anpheros.com/ru/guides/fhir-server-comparison)
- [Платформа FHIR](https://developers.anpheros.com/ru/guides/fhir)