Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
Schéma databáze FHIR
Jak ukládat FHIR zdroje: normalizované tabulky vs. JSON s indexy pro vyhledávání vs. graf, schéma PostgreSQL, na kterém Anpheros běží (zdroje, historie, typované indexy, projekce) a pravidla, na kterých záleží.
Databáze FHIR ukládá zdroje HL7 FHIR tak, aby je bylo možné číst, vyhledávat a verzovat prostřednictvím API FHIR; nejběžnější schéma udržuje každý zdroj jako JSON a vyplňuje samostatné indexovací tabulky pro vyhledávací parametry, místo aby každý prvek rozprostřelo napříč normalizovanými relačními tabulkami. Tato stránka vysvětluje tři obvyklé návrhy, schéma, na kterém Anpheros běží v PostgreSQL, a kdy byste si neměli vytvářet vlastní.
Tři způsoby ukládání 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.
Zdroje FHIR jsou hluboké, volitelné a rozšiřitelné: samotné Observation má desítky prvků, typy s volbou (value[x]), opakující se kódování a rozšíření. Normalizace do relačních sloupců znamená migraci pokaždé, když profil přidá pole. Uložení zdroje jako JSON uchovává cokoliv platného beze změny; indexovací tabulky jej činí prohledávatelným.
Anpheros schéma
- 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
| Tabulka | Jeden řádek pro | Klíčové sloupce |
|---|---|---|
fhir_resources |
aktuální verzi zdroje | resource_type, id, patient_id, version, json (celý zdroj), last_updated, deleted a sloupce pro provenance |
fhir_history |
každou dosud zapsanou verzi | resource_type, id, version, json, last_updated |
idx_token |
kódovaná nebo identifikační hodnota pro vyhledávání | system, code — pro code, category, identifier, status |
idx_string |
textová hodnota pro vyhledávání | normalizovaný text — pro názvy a volný text |
idx_date |
datum pro vyhledávání | začátek a konec rozsahu — pro date, onset-date, birthdate |
idx_reference |
referenční hodnota pro vyhledávání | cílový typ a id — pro patient, subject, encounter |
idx_quantity |
hodnota pro vyhledávání typu quantity | value, system, unit — pro value-quantity |
proj_observations, proj_conditions, proj_medications |
zdroj, zploštělý | sloupce, podle kterých se filtruje jednoduché REST API |
Při každém zápisu platforma validuje zdroj, zapíše novou verzi do fhir_resources a fhir_history, nahradí jeho indexové řádky a projekce a zaznamená Provenance. Vyhledávání jako Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01 se stane spojením tabulek idx_reference, idx_token a idx_date; výsledek vrátí uložený JSON tak, jak byl zapsán.
Pravidla návrhu, na kterých záleží
- Indexujte pouze deklarované vyhledávací parametry a odmítejte neznámé s
400namísto jejich tichého ignorování. - Nikdy neaktualizujte na místě bez historie: opravy musí zachovat to, co bylo známo dříve.
- Měkké smazání: smazaný zdroj zmizí ze čtení a vyhledávání, ale jeho verze zůstanou pro audit.
- Sloupec přihrádky pacienta: ukládání
patient_idna každý zdroj umožňuje levné$everything, filtry souhlasu a izolaci na pacienta. - Validujte před uložením: neplatný JSON v úložišti později rozbije každý čtečku.
Často kladené dotazy
Jaká je nejlepší databáze pro FHIR?
Většina produkčních FHIR serverů používá relační databázi, jako je PostgreSQL, s prostředky uloženými jako JSON (JSONB) a vyhledávacími parametry indexovanými v samostatných tabulkách. Kombinuje flexibilní ukládání s rychlým, standardním vyhledáváním.
Mám normalizovat FHIR prostředky do relačních tabulek?
Obvykle ne pro primární úložiště. Normalizované tabulky jsou vhodné pro reporting; ponechte je jako projekce vytvořené z uložených prostředků, jak to dělá Anpheros pro svůj jednodušší REST API.
Jak HAPI FHIR ukládá prostředky?
JPA server HAPI FHIR také ukládá každou verzi prostředku jako serializovaný JSON a uchovává vyhledávací parametry v samostatných indexových tabulkách. Návrh Anpheros se řídí stejným principem.
Musím si sám vytvořit FHIR databázi?
Pouze pokud potřebujete plnou kontrolu nad profily a typy prostředků. Jinak vám spravovaná FHIR platforma poskytne úložiště, vyhledávání, historii, souhlas a audit bez nutnosti spouštět schéma.
Související
- FHIR vs. vlastní lékařská databáze
- Jak ukládat lékařské záznamy pomocí FHIR R4
- Bezplatná databáze a sandbox FHIR
- Jak si Anpheros stojí v porovnání s jinými FHIR servery
- Platforma FHIR
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card