Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
Schemat bazy danych FHIR
Jak przechowywać zasoby FHIR: tabele znormalizowane vs JSON z indeksami wyszukiwania vs graf, schemat PostgreSQL, na którym działa Anpheros (zasoby, historia, indeksy typowane, projekcje) i zasady, które mają znaczenie.
Baza danych FHIR przechowuje zasoby HL7 FHIR, aby można je było odczytywać, przeszukiwać i wersjonować za pomocą API FHIR; najczęstszy schemat przechowuje każdy zasób jako JSON i wypełnia oddzielne tabele indeksujące dla parametrów wyszukiwania, zamiast rozpraszać każdy element w znormalizowanych tabelach relacyjnych. Ta strona wyjaśnia trzy typowe projekty, schemat, który Anpheros uruchamia w PostgreSQL, i kiedy nie należy samodzielnie tworzyć własnego.
Trzy sposoby przechowywania 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.
Zasoby FHIR są złożone, opcjonalne i rozszerzalne: sama obserwacja (Observation) ma dziesiątki elementów, typy wyboru (value[x]), powtarzające się kodowania i rozszerzenia. Normalizacja do kolumn relacyjnych oznacza migrację za każdym razem, gdy profil dodaje pole. Przechowywanie zasobu jako JSON pozwala zachować wszystko, co jest poprawne, niezmienione; tabele indeksujące umożliwiają wyszukiwanie.
Schemat 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
| Tabela | Jeden wiersz na | Kluczowe kolumny |
|---|---|---|
fhir_resources |
bieżącą wersję zasobu | resource_type, id, patient_id, version, json (cały zasób), last_updated, deleted, oraz kolumny proweniencji |
fhir_history |
każdą zapisaną wersję | resource_type, id, version, json, last_updated |
idx_token |
wartość wyszukiwania zakodowaną lub identyfikator | system, code — dla code, category, identifier, status |
idx_string |
wartość wyszukiwania tekstowego | znormalizowany tekst — dla nazw i tekstu swobodnego |
idx_date |
wartość wyszukiwania daty | początek i koniec zakresu — dla date, onset-date, birthdate |
idx_reference |
wartość wyszukiwania odniesienia | typ docelowy i id — dla patient, subject, encounter |
idx_quantity |
wartość wyszukiwania ilości | wartość, system, jednostka — dla value-quantity |
proj_observations, proj_conditions, proj_medications |
zasób, spłaszczony | kolumny, na których filtruje proste API REST |
Przy każdym zapisie platforma waliduje zasób, zapisuje nową wersję do fhir_resources i fhir_history, zastępuje wiersze indeksu i projekcje oraz rejestruje Proweniencję. Wyszukiwanie takie jak Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01 staje się złączeniami na idx_reference, idx_token i idx_date; wynik zwraca zapisane JSON w postaci, w jakiej został zapisany.
Zasady projektowania, które mają znaczenie
- Indeksuj tylko zadeklarowane parametry wyszukiwania i odrzucaj nieznane z
400, zamiast je po cichu ignorować. - Nigdy nie aktualizuj w miejscu bez historii: poprawki muszą zachować to, co było znane wcześniej.
- Miękkie usuwanie: usunięty zasób znika z odczytów i wyszukiwań, ale jego wersje pozostają do celów audytu.
- Kolumna przedziału pacjenta: przechowywanie
patient_idw każdym zasobie sprawia, że$everything, filtry zgody i izolacja per pacjent są tanie. - Waliduj przed zapisaniem: nieprawidłowy JSON w magazynie później zepsuje każdego czytelnika.
Najczęściej zadawane pytania
Jaka jest najlepsza baza danych dla FHIR?
Większość produkcyjnych serwerów FHIR używa relacyjnej bazy danych, takiej jak PostgreSQL, z zasobami przechowywanymi jako JSON (JSONB), a parametry wyszukiwania są indeksowane w oddzielnych tabelach. Łączy to elastyczne przechowywanie z szybkim, standardowym wyszukiwaniem.
Czy powinienem normalizować zasoby FHIR do tabel relacyjnych?
Zazwyczaj nie dla głównego magazynu. Znormalizowane tabele nadają się do raportowania; przechowuj je jako projekcje zbudowane z przechowywanych zasobów, tak jak robi to Anpheros dla swojego prostszego API REST.
Jak HAPI FHIR przechowuje zasoby?
Serwer JPA HAPI FHIR również przechowuje każdą wersję zasobu jako serializowany JSON i przechowuje parametry wyszukiwania w oddzielnych tabelach indeksu. Projekt Anpheros podąża za tą samą zasadą.
Czy muszę samodzielnie zbudować bazę danych FHIR?
Tylko jeśli potrzebujesz pełnej kontroli nad profilami i typami zasobów. W przeciwnym razie zarządzana platforma FHIR zapewnia przechowywanie, wyszukiwanie, historię, zgodę i audyt bez konieczności zarządzania schematem.
Powiązane
- FHIR a niestandardowa baza danych medycznych
- Jak przechowywać dokumentację medyczną przy użyciu FHIR R4
- Darmowa baza danych FHIR i piaskownica
- Jak Anpheros wypada na tle innych serwerów FHIR
- Platforma FHIR
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card