Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
FHIR Veritabanı Şeması
FHIR kaynakları nasıl saklanır: normalleştirilmiş tablolar, arama indeksli JSON veya grafik, Anpheros'un çalıştırdığı PostgreSQL şeması (kaynaklar, geçmiş, tipli indeksler, projeksiyonlar) ve önemli kurallar.
Bir FHIR veritabanı, HL7 FHIR kaynaklarını FHIR API aracılığıyla okunabilir, aranabilir ve sürümlenebilir hale getirmek için depolar; en yaygın şema, her kaynağı JSON olarak tutar ve arama parametreleri için ayrı indeks tablolarını doldurur, her öğeyi normalleştirilmiş ilişkisel tablolara yaymak yerine. Bu sayfa, üç yaygın tasarımı, Anpheros'un PostgreSQL'de çalıştırdığı şemayı ve kendi şemanızı ne zaman oluşturmamanız gerektiğini açıklar.
FHIR'i Saklamanın Üç Yolu
| 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 kaynakları derin, isteğe bağlı ve genişletilebilir yapıdadır: tek başına bir Observation'ın onlarca öğesi, seçim türleri (value[x]), tekrarlanan kodlamalar ve uzantıları vardır. Bunu ilişkisel sütunlara normalleştirmek, bir profil alan eklediğinde bir geçiş anlamına gelir. Kaynağı JSON olarak saklamak, geçerli olan her şeyi değişmeden depolar; dizin tabloları aranabilir olmasını sağlar.
Anpheros şeması
- 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
| Tablo | Bir satır başına | Anahtar sütunlar |
|---|---|---|
fhir_resources |
bir kaynağın mevcut sürümü | resource_type, id, patient_id, version, json (tam kaynak), last_updated, deleted ve köken sütunları |
fhir_history |
yazılmış her sürüm | resource_type, id, version, json, last_updated |
idx_token |
kodlanmış veya tanımlayıcı arama değeri | sistem, kod — code, category, identifier, status için |
idx_string |
metin arama değeri | normalleştirilmiş metin — adlar ve serbest metin için |
idx_date |
tarih arama değeri | aralığın başlangıcı ve sonu — date, onset-date, birthdate için |
idx_reference |
referans arama değeri | hedef türü ve kimliği — patient, subject, encounter için |
idx_quantity |
miktar arama değeri | değer, sistem, birim — value-quantity için |
proj_observations, proj_conditions, proj_medications |
kaynak, düzleştirilmiş | basit REST API'nin filtrelediği sütunlar |
Her yazma işleminde platform, kaynağı doğrular, yeni sürümü fhir_resources ve fhir_history'ya yazar, dizin satırlarını ve projeksiyonlarını değiştirir ve Kökeni kaydeder. Observation?patient=…&code=http://loinc.org|4548-4&date=ge2026-01-01 gibi bir arama, idx_reference, idx_token ve idx_date üzerinde birleştirmeler haline gelir; sonuç, yazıldığı gibi saklanan JSON'u döndürür.
Önemli Tasarım Kuralları
- Yalnızca beyan edilmiş arama parametrelerini indeksleyin ve bilinmeyenleri sessizce yok saymak yerine
400ile reddedin. - Geçmiş olmadan asla yerinde güncelleme yapmayın: düzeltmeler, önceden bilinenleri korumalıdır.
- Yumuşak silme: silinen bir kaynak okumalardan ve aramalardan kaybolur ancak sürümleri denetim için kalır.
- Hasta bölmesi sütunu: her kaynağa
patient_iddepolamak,$everything, onay filtreleri ve hasta başına izolasyonu ucuz hale getirir. - Depolamadan önce doğrulayın: depodaki geçersiz JSON daha sonra her okuyucuyu bozar.
Sıkça Sorulan Sorular
FHIR için en iyi veritabanı hangisidir?
Çoğu üretim ortamındaki FHIR sunucusu, kaynakların JSON (JSONB) olarak saklandığı ve arama parametrelerinin ayrı tablolarda indekslendiği PostgreSQL gibi ilişkisel bir veritabanı kullanır. Bu, esnek depolamayı hızlı, standart arama ile birleştirir.
FHIR kaynaklarını ilişkisel tablolara normalleştirmeli miyim?
Genellikle birincil depolama için hayır. Normalleştirilmiş tablolar raporlama için uygundur; bunları, Anpheros'un daha basit REST API'si için yaptığı gibi, saklanan kaynaklardan oluşturulan projeksiyonlar olarak saklayın.
HAPI FHIR kaynakları nasıl saklar?
HAPI FHIR'ın JPA sunucusu da her kaynak sürümünü serileştirilmiş JSON olarak saklar ve arama parametrelerini ayrı indeks tablolarında tutar. Anpheros tasarımı aynı prensibi takip eder.
Kendi FHIR veritabanımı oluşturmam gerekiyor mu?
Yalnızca profiller ve kaynak türleri üzerinde tam kontrol istiyorsanız. Aksi takdirde yönetilen bir FHIR platformu, şemayı çalıştırmadan depolama, arama, geçmiş, izin ve denetim sağlar.
İlgili Kaynaklar
- FHIR ve özel bir tıbbi veritabanı karşılaştırması
- Tıbbi kayıtların FHIR R4 kullanılarak nasıl saklanacağı
- Ücretsiz FHIR veritabanı ve sandbox
- Anpheros'un diğer FHIR sunucularıyla karşılaştırması
- FHIR platformu
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card