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

> Як зберігати ресурси FHIR: нормалізовані таблиці проти JSON з індексами пошуку проти графа, схема PostgreSQL, яку використовує Anpheros (ресурси, історія, типізовані індекси, проєкції) та правила, що мають значення.

Source: https://developers.anpheros.com/uk/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`, а також стовпці походження |
| `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` | значення пошуку за посиланням | тип цілі та 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`, стає об'єднанням (joins) за `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/uk/guides/fhir-vs-custom-database)
- [Як зберігати медичні записи за допомогою FHIR R4](https://developers.anpheros.com/uk/guides/store-medical-records-fhir)
- [Безкоштовна база даних FHIR та пісочниця](https://developers.anpheros.com/uk/guides/free-fhir-database)
- [Як Anpheros порівнюється з іншими серверами FHIR](https://developers.anpheros.com/uk/guides/fhir-server-comparison)
- [Платформа FHIR](https://developers.anpheros.com/uk/guides/fhir)