Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

FHIR ve Özel Bir Tıbbi Veritabanı Karşılaştırması

Kendi tablolarınız veya HL7 FHIR R4 sağlık verileri için: her ikisi de aynı şekilde okunur, yan yana ödünleşimler, ne zaman hangisinin doğru olduğu ve veritabanınız ile FHIR kaydı arasındaki olağan ayrım.

Bir sağlık ürününe başlayan bir ekip genellikle erken aşamada aynı seçimle karşı karşıya kalır: hastalar, ölçümler ve teşhisler için PostgreSQL veya başka bir veritabanında kendi tablolarını tasarlamak veya tıbbi verileri başlangıçtan itibaren HL7 FHIR R4 kaynakları olarak saklamak. Özel bir şema ilk gün daha hızlıdır ve ürününüze tam olarak uyar. FHIR, başlangıçta daha fazla düşünme maliyeti getirir ve verilerin sisteminizden ayrılması, denetlenmesi, rıza ile paylaşılması veya sizden başka biri tarafından okunması gerektiğinde her seferinde geri ödeme yapar. Bu sayfa, aynı okumanın her iki şekilde de saklandığı takasları dürüstçe ortaya koyar ve her seçimin ne zaman doğru olduğunu belirtir.

Bu, hangi FHIR sunucusunun kullanılacağı sorusundan farklıdır. Bunun için Anpheros'un Diğer FHIR Sunucularıyla Nasıl Karşılaştırıldığı bölümüne bakın.

Aynı okuma, iki farklı yol

Özel bir şemada bir tansiyon okuması:

CREATE TABLE bp_readings (
  id          uuid PRIMARY KEY,
  user_id     uuid REFERENCES users(id),
  systolic    int,
  diastolic   int,
  measured_at timestamptz,
  created_at  timestamptz DEFAULT now()
);

Basit, sorgulaması hızlı, uygulamanın tam olarak ihtiyacı olan şey. Ardından tablonun yanıtlamadığı sorular geliyor:

• Değeri hangi cihaz veya kişi üretti? Hasta tarafından mı girildi, manşetle mi ölçüldü, yoksa bir hemşire tarafından mı kaydedildi?
• Birisi düzeltmeden önceki değer neydi ve kim düzeltti?
• Bir klinik sistemi, laboratuvar veya sigortacı bunu nasıl okur? Kendi sistemlerinde systolic ne anlama geliyor?
• Hasta bunu doktorunun uygulamasıyla nasıl paylaşır ve gelecek ay paylaşmayı nasıl durdurur?
• Kalp atış hızı, kilo, HbA1c ve diğer 200 ölçümü eklediğinizde, bu 200 tablo mu yoksa kendi tasarladığınız tek bir genel tablo mu?

FHIR R4 olarak aynı okuma:

{"resourceType": "Observation", "status": "final",
 "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs"}]}],
 "code": {"coding": [{"system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel"}]},
 "subject": {"reference": "Patient/d09e3942-…"}, "effectiveDateTime": "2026-10-10T08:30:00Z",
 "component": [
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}, "valueQuantity": {"value": 138, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}},
   {"code": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}, "valueQuantity": {"value": 88, "unit": "mmHg", "system": "http://unitsofmeasure.org", "code": "mm[Hg]"}}],
 "meta": {"versionId": "1"}}

Daha ayrıntılı, ancak her parçanın her FHIR sisteminin paylaştığı bir anlamı var: LOINC neyin ölçüldüğünü söyler, UCUM birimi söyler, meta.versionId bir geçmişi başlatır ve aynı Observation şekli diğer 200 ölçümü tutar. Anpheros ile Provenance kaynağı ayrıca kimin yazdığını da kaydeder. FHIR R4 kullanarak tıbbi kayıtların nasıl saklanacağı bölümü bunu ayrıntılı olarak anlatır.

Yan yana

Özel bir şema ne zaman doğru seçimdir

• Veriler aslında tıbbi değil veya tek bir kişiye ait değil. Eğitim planları, içerik, bir ürün kataloğu: kendi tablolarınızı kullanın.
• Kısa ömürlü bir prototip ürünün istenip istenmediğini test etmek için, sentetik verilerle ve geçiş planıyla.
• Veriler hiçbir standart modele iyi uymuyor, örneğin yeni bir araştırma ölçümü. FHIR yine de bunu taşıyabilir (Observation kendi kod sisteminizle veya Basic), ancak özel bir tablo daha net olabilir.
• Yoğun analizler. Kayıt sistemi olarak FHIR olsa bile, çoğu ekip raporlama için verileri kendi biçimlerinde bir veri ambarına kopyalar.

FHIR'ın Doğru Seçim Olduğu Durumlar

• Veriler bir kişinin sağlık kaydıdır: ölçümler, teşhisler, ilaçlar, alerjiler, laboratuvar sonuçları, belgeler.
• Sisteminizden ayrılacak: hastaya, bir doktora, bir kliniğe, bir laboratuvara, bir sigortacıya, bir yapay zeka modeline veya hasta taşındığında bir rakibe.
• Kimin ne yazdığını ve neyin değiştiğini göstermeniz gerekiyor: denetimler, klinik güvenlik, anlaşmazlıklar.
• Hastalar uygulama başına erişim izni verecek ve geri alacaktır.
• Avrupa Birliği'nde satış yapıyorsunuz ve Avrupa Sağlık Veri Alanı, kayıtların standart formatlarda değiştirilebilir olmasını bekliyor.

Olağan Orta Yol

Çoğu ürün, veri türüne göre bölünmüş her ikisine de sahip olur:

your database                         FHIR record (Anpheros)
─────────────                         ──────────────────────
users, sessions, settings             Patient
subscriptions, billing                Observation, Condition, MedicationStatement
product content, feature flags        AllergyIntolerance, Immunization, DocumentReference
user id → patient id (one column)     Provenance, Consent, history
caches and analytics copies  ◄─────── webhooks

Veritabanınız küçük ve ürün şekilli kalır. Tıbbi kayıt standart, sürümlenmiş ve paylaşılabilir durumdadır ve bunu oluşturmak zorunda kalmadınız. Tıbbi uygulama arka ucu ve veritabanı bu bölümü ayrıntılı olarak açıklar ve TypeScript ile sağlık API'si nasıl oluşturulur bunu oluşturur.

FHIR'ı Kendi Başınıza Oluşturmanın Gerektirdikleri

FHIR'ı seçmek, bir FHIR sunucusu yazmak anlamına gelmez. Seçenekleriniz arasında çalıştırdığınız açık kaynaklı bir sunucu, bir bulut sağlayıcısının FHIR deposu, açık kaynaklı bir sağlık platformu veya Anpheros gibi yönetilen bir sağlık veritabanı bulunur. Bu seçenekler, onay, denetim, köken, ikamet ve entegrasyonları kimin yönettiği konusunda farklılık gösterir; bu da Anpheros'un Diğer FHIR Sunucularıyla Karşılaştırması bölümünde açıklanmıştır.

Sıkça Sorulan Sorular

FHIR bir veritabanı mıdır?

Hayır. FHIR, sağlık verilerinin yapısı ve değişimi için bir standarttır: kaynaklar, kodlar ve bir REST API. Bir FHIR sunucusu veya yönetilen FHIR veritabanı, kaynakları depolar ve gerçek bir veritabanının üzerinde API'yi uygular.

FHIR kaynaklarını kendim PostgreSQL'de saklayabilir miyim?

Evet, JSON sütunları olarak kendi indekslerinizle saklayabilirsiniz ve bazı açık kaynak sunucular tam olarak bunu yapar. İş, depolama etrafındaki her şeydedir: arama parametreleri, sürümleme, referanslar, doğrulama, hasta başına erişim kontrolü ve köken bilgisi.

Özel bir şema ile başlayıp daha sonra FHIR'a geçebilir miyim?

Evet, yapabilirsiniz ve birçok ekip bunu yapar, ancak geçiş bir eşleme projesidir: her tablo, hiç kaydetmediği kodlar, birimler ve yazarlar gerektirir. Tıbbi verileri ilk özellikten itibaren FHIR olarak depolamak, daha sonra dönüştürmekten daha az maliyetlidir.

GDPR'a uymak için FHIR'a ihtiyacım var mı?

Hayır. GDPR belirli bir format gerektirmez. FHIR, çeşitli yükümlülüklerin karşılanmasını kolaylaştırır: taşınabilirlik (kayıt standart bir formatta dışa aktarılır), amaç başına erişim kontrolü ve kimin hangi veriyi işlediğini gösterme.

İlgili Konular

• FHIR veritabanı şeması: FHIR kaynaklarının nasıl saklandığı ve indekslendiği
• FHIR R4 kullanarak tıbbi kayıtların nasıl saklanacağı
• FHIR platformu
• Anpheros'un diğer FHIR sunucularıyla karşılaştırması
• Tıbbi uygulama arka ucu ve veritabanı
• Sağlık API'si

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card