# FHIR adatbázisséma

> Hogyan tároljuk a FHIR erőforrásokat: normalizált táblák vs. JSON keresési indexekkel vs. gráfon, az Anpheros által használt PostgreSQL séma (erőforrások, előzmények, típusú indexek, kivetítések) és a fontos szabályok.

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

**Egy FHIR adatbázis HL7 FHIR erőforrásokat tárol, hogy azok a FHIR API-n keresztül olvashatók, kereshetők és verziózhatók legyenek; a leggyakoribb séma minden erőforrást JSON formátumban tart, és külön index táblákat tölt fel a keresési paraméterekhez, ahelyett, hogy minden elemet normalizált relációs táblákba szórna szét.** Ez az oldal a három szokásos tervet, az Anpheros által PostgreSQL-ben használt sémát, és azt magyarázza el, mikor ne építsen sajátot.

## Három módja a FHIR tárolására

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

A FHIR erőforrások mélyek, opcionálisak és bővíthetők: egyetlen megfigyelés (Observation) is több tucat elemet, választási típusokat (`value[x]`), ismétlődő kódolásokat és kiterjesztéseket tartalmaz. Ennek relációs oszlopokba normalizálása azt jelenti, hogy minden alkalommal migrálásra van szükség, amikor egy profil mezőt ad hozzá. Az erőforrás JSON formátumban tartása bármi érvényes dolgot változatlanul tárol; az index táblák kereshetővé teszik.

## Az Anpheros séma

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

| Tábla | Egy sor per | Kulcs oszlopok |
|---|---|---|
| `fhir_resources` | egy erőforrás aktuális verziója | `resource_type`, `id`, `patient_id`, `version`, `json` (a teljes erőforrás), `last_updated`, `deleted`, valamint a származási oszlopok |
| `fhir_history` | minden valaha írt verzió | `resource_type`, `id`, `version`, `json`, `last_updated` |
| `idx_token` | kódolt vagy azonosító keresési érték | system, code — `code`, `category`, `identifier`, `status` esetén |
| `idx_string` | szöveges keresési érték | normalizált szöveg — nevek és szabad szöveg esetén |
| `idx_date` | dátum keresési érték | a tartomány kezdete és vége — `date`, `onset-date`, `birthdate` esetén |
| `idx_reference` | referencia keresési érték | cél típus és azonosító — `patient`, `subject`, `encounter` esetén |
| `idx_quantity` | mennyiség keresési érték | érték, rendszer, egység — `value-quantity` esetén |
| `proj_observations`, `proj_conditions`, `proj_medications` | erőforrás, lapított | az oszlopok, amelyekre az egyszerű REST API szűr |

Minden írásnál a platform érvényesíti az erőforrást, megírja az új verziót a `fhir_resources` és `fhir_history` táblákba, kicseréli az index sorait és kivetítéseit, és rögzíti a Provenance-t. Egy keresés, mint például a `Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01`, illesztésekké válik a `idx_reference`, `idx_token` és `idx_date` táblákon; az eredmény visszaadja a tárolt JSON-t, ahogy írva volt.

## Fontos tervezési szabályok

- **Csak a deklarált keresési paramétereket indexelje**, és az ismeretleneket `400` hibával utasítsa el ahelyett, hogy csendben figyelmen kívül hagyná őket.
- **Soha ne frissítsen helyben előzmények nélkül**: a javításoknak meg kell őrizniük a korábban ismert információkat.
- **Puha törlés**: a törölt erőforrás eltűnik az olvasásokból és keresésekből, de verziói megmaradnak audit céljából.
- **Beteg-kompartment oszlop**: minden erőforrásra `patient_id` tárolása olcsóvá teszi a `$everything`, a hozzájárulási szűrőket és a betegspecifikus izolációt.
- **Validálás tárolás előtt**: az érvénytelen JSON a tárolóban minden későbbi olvasót tönkretesz.

## Gyakran ismételt kérdések

### Mi a legjobb adatbázis a FHIR számára?
A legtöbb éles FHIR szerver relációs adatbázist használ, például PostgreSQL-t, ahol az erőforrásokat JSON (JSONB) formátumban tárolják, és a keresési paramétereket külön táblákban indexelik. Ez egyesíti a rugalmas tárolást a gyors, szabványos kereséssel.

### Normalizáljam a FHIR erőforrásokat relációs táblákba?
Általában nem az elsődleges tárolóhoz. A normalizált táblák alkalmasak jelentéskészítésre; ezeket a tárolt erőforrásokból felépített projekciókként érdemes kezelni, ahogyan az Anpheros is teszi az egyszerűbb REST API-ja esetében.

### Hogyan tárolja az erőforrásokat a HAPI FHIR?
A HAPI FHIR JPA szervere is minden erőforrás verziót szerializált JSON-ként tárol, és a keresési paramétereket külön index táblákban tartja. Az Anpheros kialakítása ugyanezt az elvet követi.

### Kell-e saját FHIR adatbázist építenem?
Csak akkor, ha teljes körű vezérlésre van szüksége a profilok és erőforrás-típusok felett. Ellenkező esetben egy felügyelt FHIR platform biztosítja a tárolást, keresést, előzményeket, hozzájárulást és auditálást a séma futtatása nélkül.

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

## Kapcsolódó

- [FHIR vs. egyedi orvosi adatbázis](https://developers.anpheros.com/hu/guides/fhir-vs-custom-database)
- [Orvosi rekordok tárolása FHIR R4 használatával](https://developers.anpheros.com/hu/guides/store-medical-records-fhir)
- [Ingyenes FHIR adatbázis és sandbox](https://developers.anpheros.com/hu/guides/free-fhir-database)
- [Az Anpheros összehasonlítása más FHIR szerverekkel](https://developers.anpheros.com/hu/guides/fhir-server-comparison)
- [FHIR platform](https://developers.anpheros.com/hu/guides/fhir)