# Schema bazei de date FHIR

> Cum să stocați resurse FHIR: tabele normalizate vs. JSON cu indecși de căutare vs. graf, schema PostgreSQL pe care rulează Anpheros (resurse, istoric, indecși tipizați, proiecții) și regulile care contează.

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

**O bază de date FHIR stochează resurse HL7 FHIR pentru a putea fi citite, căutate și versionate prin intermediul API-ului FHIR; cel mai comun schema păstrează fiecare resursă ca JSON și completează tabele de index separate pentru parametrii de căutare, în loc să împrăștie fiecare element în tabele relaționale normalizate.** Această pagină explică cele trei modele uzuale, schema pe care rulează Anpheros în PostgreSQL și când nu ar trebui să construiți una singur.

## Trei modalități de stocare a FHIR

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

Resursele FHIR sunt complexe, opționale și extensibile: o singură observație (Observation) are zeci de elemente, tipuri de alegere (`value[x]`), codificări repetitive și extensii. Normalizarea acestora în coloane relaționale înseamnă o migrare ori de câte ori un profil adaugă un câmp. Păstrarea resursei ca JSON stochează orice element valid neschimbat; tabelele de indexare îl fac căutabil.

## Schema Anpheros

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

| Tabelă | Un rând pentru | Coloane cheie |
|---|---|---|
| `fhir_resources` | versiunea curentă a unei resurse | `resource_type`, `id`, `patient_id`, `version`, `json` (resursa completă), `last_updated`, `deleted`, plus coloane de proveniență |
| `fhir_history` | fiecare versiune scrisă vreodată | `resource_type`, `id`, `version`, `json`, `last_updated` |
| `idx_token` | valoare de căutare codificată sau de identificare | system, code — pentru `code`, `category`, `identifier`, `status` |
| `idx_string` | valoare de căutare text | text normalizat — pentru nume și text liber |
| `idx_date` | valoare de căutare dată | început și sfârșit al intervalului — pentru `date`, `onset-date`, `birthdate` |
| `idx_reference` | valoare de căutare referință | tip țintă și id — pentru `patient`, `subject`, `encounter` |
| `idx_quantity` | valoare de căutare cantitate | value, system, unit — pentru `value-quantity` |
| `proj_observations`, `proj_conditions`, `proj_medications` | resursă, aplatizată | coloanele pe care se filtrează API-ul REST simplu |

La fiecare scriere, platforma validează resursa, scrie noua versiune în `fhir_resources` și `fhir_history`, înlocuiește rândurile indexului și proiecțiile sale și înregistrează Proveniența. O căutare precum `Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01` devine join-uri pe `idx_reference`, `idx_token` și `idx_date`; rezultatul returnează JSON-ul stocat așa cum a fost scris.

## Reguli de design importante

- **Indexați doar parametrii de căutare declarați** și refuzați-i pe cei necunoscuți cu `400`, în loc să-i ignorați silențios.
- **Nu actualizați niciodată pe loc fără istoric**: corecțiile trebuie să păstreze ceea ce era cunoscut anterior.
- **Ștergere soft (soft delete)**: o resursă ștearsă dispare din citiri și căutări, dar versiunile sale rămân pentru audit.
- **Coloana pentru compartimentul pacientului**: stocarea `patient_id` pe fiecare resursă face ca `$everything`, filtrele de consimțământ și izolarea per pacient să fie ieftine.
- **Validați înainte de stocare**: JSON-ul invalid în stocare va defecta orice cititor ulterior.

## Întrebări frecvente

### Care este cea mai bună bază de date pentru FHIR?
Majoritatea serverelor FHIR de producție utilizează o bază de date relațională, cum ar fi PostgreSQL, cu resursele stocate ca JSON (JSONB) și parametrii de căutare indexați în tabele separate. Aceasta combină stocarea flexibilă cu căutarea rapidă și standard.

### Ar trebui să normalizez resursele FHIR în tabele relaționale?
De obicei, nu pentru stocarea primară. Tabelele normalizate sunt potrivite pentru raportare; păstrați-le ca proiecții construite din resursele stocate, așa cum face Anpheros pentru API-ul său REST mai simplu.

### Cum stochează HAPI FHIR resursele?
Serverul JPA al HAPI FHIR stochează, de asemenea, fiecare versiune a resursei ca JSON serializat și păstrează parametrii de căutare în tabele de index separate. Designul Anpheros urmează același principiu.

### Trebuie să construiesc singur o bază de date FHIR?
Doar dacă aveți nevoie de control complet asupra profilurilor și tipurilor de resurse. În caz contrar, o platformă FHIR gestionată vă oferă stocare, căutare, istoric, consimțământ și audit fără a gestiona schema.

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

## Conexe

- [FHIR vs. o bază de date medicală personalizată](https://developers.anpheros.com/ro/guides/fhir-vs-custom-database)
- [Cum să stocați înregistrări medicale folosind FHIR R4](https://developers.anpheros.com/ro/guides/store-medical-records-fhir)
- [Bază de date FHIR gratuită și sandbox](https://developers.anpheros.com/ro/guides/free-fhir-database)
- [Cum se compară Anpheros cu alte servere FHIR](https://developers.anpheros.com/ro/guides/fhir-server-comparison)
- [Platformă FHIR](https://developers.anpheros.com/ro/guides/fhir)