Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
Схема бази даних FHIR
Як зберігати ресурси FHIR: нормалізовані таблиці проти JSON з індексами пошуку проти графа, схема PostgreSQL, на якій працює Anpheros (ресурси, історія, типізовані індекси, проєкції) та правила, що мають значення.
База даних FHIR зберігає ресурси HL7 FHIR, щоб їх можна було читати, шукати та версіонувати через FHIR API; найпоширеніша схема зберігає кожен ресурс як JSON і заповнює окремі таблиці індексів для параметрів пошуку, замість того, щоб розподіляти кожен елемент по нормалізованих реляційних таблицях. Ця сторінка пояснює три типові дизайни, схему, яку Anpheros використовує в PostgreSQL, та коли вам не слід створювати власну.
Три способи зберігання FHIR
| Normalised tables | JSON + search indexes | Graph database | |
|---|---|---|---|
| Stores any valid resource unchanged | — | ✓ | ✓ |
| Standard FHIR search on any parameter | ◐ | ✓ | ◐ |
| New fields need a schema migration | ✓ | — | — |
| Easy SQL reporting | ✓ | ◐ | — |
| Used by mainstream FHIR servers | ◐ | ✓ | — |
◐ = possible with extra work. HAPI FHIR and Anpheros both keep the resource as JSON and index search parameters separately.
Ресурси FHIR є глибокими, опціональними та розширюваними: один Observation має десятки елементів, типи вибору (value[x]), повторювані кодування та розширення. Нормалізація цього в реляційні стовпці означає міграцію кожного разу, коли профіль додає поле. Зберігання ресурсу як JSON зберігає будь-що дійсне без змін; індексні таблиці роблять його доступним для пошуку.
Схема Anpheros
- APIFHIR R4 REST and the simpler /v1 REST API
- Current resourcesOne row per resource: type, id, patient, version, the full FHIR JSON (JSONB)
- Search indexesTyped tables filled on every write: token, string, date, reference, quantity
- HistoryEvery version of every resource, never overwritten
- ProjectionsFlat tables for the common REST views: observations, conditions, medications
- PostgreSQLOne database per environment; sandbox and production are separate
| Таблиця | Один рядок для | Ключові стовпці |
|---|---|---|
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 надає вам сховище, пошук, історію, згоду та аудит без необхідності керувати схемою.
Пов'язане
- FHIR проти власної медичної бази даних
- Як зберігати медичні записи за допомогою FHIR R4
- Безкоштовна база даних FHIR та пісочниця
- Як Anpheros порівнюється з іншими серверами FHIR
- Платформа FHIR
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card