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 |
πόρος, "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 σας παρέχει αποθήκευση, αναζήτηση, ιστορικό, συναίνεση και έλεγχο χωρίς να διαχειρίζεστε το σχήμα.
Σχετικά
- FHIR vs. προσαρμοσμένη ιατρική βάση δεδομένων
- Πώς να αποθηκεύσετε ιατρικά αρχεία χρησιμοποιώντας FHIR R4
- Δωρεάν βάση δεδομένων FHIR και sandbox
- Πώς συγκρίνεται το Anpheros με άλλους FHIR servers
- Πλατφόρμα FHIR
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card