Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
FHIR adatbázis séma
Hogyan tároljunk FHIR erőforrásokat: normalizált táblák kontra JSON keresési indexekkel kontra graf, a PostgreSQL séma, amin az Anpheros fut (erőforrások, történet, típusú indexek, projekciók) és a fontos szabályok.
Egy FHIR adatbázis HL7 FHIR erőforrásokat tárol, hogy azok a FHIR API-n keresztül olvashatók, kereshetők és verziózhatók legyenek; a leggyakoribb séma minden erőforrást JSON formátumban tart, és külön index táblákat tölt fel a keresési paraméterekhez, ahelyett, hogy minden elemet normalizált relációs táblákba szórna szét. Ez az oldal a három szokásos tervet, az Anpheros által PostgreSQL-ben használt sémát, és azt magyarázza el, mikor ne építsen sajátot.
Három módja a FHIR tárolására
| 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.
A FHIR erőforrások mélyek, opcionálisak és bővíthetők: egyetlen megfigyelés (Observation) is több tucat elemet, választási típusokat (value[x]), ismétlődő kódolásokat és kiterjesztéseket tartalmaz. Ennek relációs oszlopokba normalizálása azt jelenti, hogy minden alkalommal migrálásra van szükség, amikor egy profil mezőt ad hozzá. Az erőforrás JSON formátumban tartása bármi érvényes dolgot változatlanul tárol; az index táblák kereshetővé teszik.
Az Anpheros sé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
| Tábla | Egy sor per | Kulcs oszlopok |
|---|---|---|
fhir_resources |
egy erőforrás aktuális verziója | resource_type, id, patient_id, version, json (a teljes erőforrás), last_updated, deleted, valamint a származási oszlopok |
fhir_history |
minden valaha írt verzió | resource_type, id, version, json, last_updated |
idx_token |
kódolt vagy azonosító keresési érték | system, code — code, category, identifier, status esetén |
idx_string |
szöveges keresési érték | normalizált szöveg — nevek és szabad szöveg esetén |
idx_date |
dátum keresési érték | a tartomány kezdete és vége — date, onset-date, birthdate esetén |
idx_reference |
referencia keresési érték | cél típus és azonosító — patient, subject, encounter esetén |
idx_quantity |
mennyiség keresési érték | érték, rendszer, egység — value-quantity esetén |
proj_observations, proj_conditions, proj_medications |
erőforrás, lapított | az oszlopok, amelyekre az egyszerű REST API szűr |
Minden írásnál a platform érvényesíti az erőforrást, megírja az új verziót a fhir_resources és fhir_history táblákba, kicseréli az index sorait és kivetítéseit, és rögzíti a Provenance-t. Egy keresés, mint például a Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01, illesztésekké válik a idx_reference, idx_token és idx_date táblákon; az eredmény visszaadja a tárolt JSON-t, ahogy írva volt.
Fontos tervezési szabályok
- Csak a deklarált keresési paramétereket indexelje, és az ismeretleneket
400hibával utasítsa el ahelyett, hogy csendben figyelmen kívül hagyná őket. - Soha ne frissítsen helyben előzmények nélkül: a javításoknak meg kell őrizniük a korábban ismert információkat.
- Puha törlés: a törölt erőforrás eltűnik az olvasásokból és keresésekből, de verziói megmaradnak audit céljából.
- Beteg-kompartment oszlop: minden erőforrásra
patient_idtárolása olcsóvá teszi a$everything, a hozzájárulási szűrőket és a betegspecifikus izolációt. - Validálás tárolás előtt: az érvénytelen JSON a tárolóban minden későbbi olvasót tönkretesz.
Gyakran ismételt kérdések
Mi a legjobb adatbázis a FHIR számára?
A legtöbb éles FHIR szerver relációs adatbázist használ, például PostgreSQL-t, ahol az erőforrásokat JSON (JSONB) formátumban tárolják, és a keresési paramétereket külön táblákban indexelik. Ez egyesíti a rugalmas tárolást a gyors, szabványos kereséssel.
Normalizáljam a FHIR erőforrásokat relációs táblákba?
Általában nem az elsődleges tárolóhoz. A normalizált táblák alkalmasak jelentéskészítésre; ezeket a tárolt erőforrásokból felépített projekciókként érdemes kezelni, ahogyan az Anpheros is teszi az egyszerűbb REST API-ja esetében.
Hogyan tárolja az erőforrásokat a HAPI FHIR?
A HAPI FHIR JPA szervere is minden erőforrás verziót szerializált JSON-ként tárol, és a keresési paramétereket külön index táblákban tartja. Az Anpheros kialakítása ugyanezt az elvet követi.
Kell-e saját FHIR adatbázist építenem?
Csak akkor, ha teljes körű vezérlésre van szüksége a profilok és erőforrás-típusok felett. Ellenkező esetben egy felügyelt FHIR platform biztosítja a tárolást, keresést, előzményeket, hozzájárulást és auditálást a séma futtatása nélkül.
Kapcsolódó
- FHIR vs. egyedi orvosi adatbázis
- Orvosi rekordok tárolása FHIR R4 használatával
- Ingyenes FHIR adatbázis és sandbox
- Az Anpheros összehasonlítása más FHIR szerverekkel
- FHIR platform
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card