# Σχήμα βάσης δεδομένων FHIR

> Πώς να αποθηκεύσετε πόρους FHIR: κανονικοποιημένοι πίνακες έναντι JSON με δείκτες αναζήτησης έναντι γράφου, το σχήμα PostgreSQL που εκτελεί η Anpheros (πόροι, ιστορικό, τυποποιημένοι δείκτες, προβολές) και οι κανόνες που έχουν σημασία.

Source: https://developers.anpheros.com/el/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` | πόρος, "flattened" | οι στήλες στις οποίες φιλτράρει το απλό 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` αντί για σιωπηλή αγνόηση.
- **Ποτέ ενημέρωση επί τόπου χωρίς ιστορικό**: οι διορθώσεις πρέπει να διατηρούν ό,τι ήταν γνωστό προηγουμένως.
- **Μαλακή διαγραφή (Soft delete)**: ένας διαγραμμένος πόρος εξαφανίζεται από τις αναγνώσεις και τις αναζητήσεις, αλλά οι εκδόσεις του παραμένουν για έλεγχο.
- **Στήλη διαμερίσματος ασθενούς (Patient compartment column)**: η αποθήκευση του `patient_id` σε κάθε πόρο καθιστά φθηνές τις `$everything`, τα φίλτρα συναίνεσης και την απομόνωση ανά ασθενή.
- **Επικύρωση πριν την αποθήκευση**: άκυρο JSON στο κατάστημα (store) θα προκαλέσει προβλήματα σε κάθε αναγνώστη αργότερα.

## Συχνές ερωτήσεις

### Ποια είναι η καλύτερη βάση δεδομένων για FHIR;
Οι περισσότεροι FHIR servers παραγωγής χρησιμοποιούν μια σχεσιακή βάση δεδομένων όπως η PostgreSQL, με τους πόρους να αποθηκεύονται ως JSON (JSONB) και τις παραμέτρους αναζήτησης να ευρετηριάζονται σε ξεχωριστούς πίνακες. Συνδυάζει ευέλικτη αποθήκευση με γρήγορη, τυπική αναζήτηση.

### Πρέπει να κανονικοποιήσω τους FHIR πόρους σε σχεσιακούς πίνακες;
Συνήθως όχι για την κύρια αποθήκευση. Οι κανονικοποιημένοι πίνακες είναι κατάλληλοι για αναφορές· κρατήστε τους ως προβολές που δημιουργούνται από τους αποθηκευμένους πόρους, όπως κάνει η Anpheros για το απλούστερο REST API της.

### Πώς αποθηκεύει πόρους η HAPI FHIR;
Ο JPA server της HAPI FHIR αποθηκεύει επίσης κάθε έκδοση πόρου ως σειριοποιημένο JSON και διατηρεί τις παραμέτρους αναζήτησης σε ξεχωριστούς πίνακες ευρετηρίου. Ο σχεδιασμός της Anpheros ακολουθεί την ίδια αρχή.

### Πρέπει να φτιάξω μόνος μου μια FHIR βάση δεδομένων;
Μόνο αν χρειάζεστε πλήρη έλεγχο των προφίλ και των τύπων πόρων. Διαφορετικά, μια διαχειριζόμενη πλατφόρμα FHIR σας παρέχει αποθήκευση, αναζήτηση, ιστορικό, συναίνεση και έλεγχο χωρίς να διαχειρίζεστε το σχήμα.

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

## Σχετικά

- [FHIR vs. προσαρμοσμένη ιατρική βάση δεδομένων](https://developers.anpheros.com/el/guides/fhir-vs-custom-database)
- [Πώς να αποθηκεύσετε ιατρικά αρχεία χρησιμοποιώντας FHIR R4](https://developers.anpheros.com/el/guides/store-medical-records-fhir)
- [Δωρεάν βάση δεδομένων FHIR και sandbox](https://developers.anpheros.com/el/guides/free-fhir-database)
- [Πώς συγκρίνεται το Anpheros με άλλους FHIR servers](https://developers.anpheros.com/el/guides/fhir-server-comparison)
- [Πλατφόρμα FHIR](https://developers.anpheros.com/el/guides/fhir)