Kısa cevap: sağlık verileri dört katman standart üzerinden hareket eder. Değişim standartları veriyi sistemler arasında taşır: HL7 v2 mesajları, CDA belgeleri, FHIR kaynakları ve görüntüler için DICOM. Modelleme ve depolama standartları, bir kaydın sistem içinde nasıl yapılandırıldığını belirtir: klinik kayıtlar için openEHR, araştırma veritabanları için OMOP. Terminolojiler, her kavrama her iki tarafın da anladığı bir kod verir: SNOMED CT, LOINC, ICD, ATC, UCUM, RxNorm. Kimlik ve güvenlik standartları kimin neyi okuyabileceğine karar verir: OAuth 2.0 ve SMART on FHIR, ayrıca tüm bunları test edilmiş tariflerde birleştiren IHE profilleri. Kimse tek birini kullanmaz; bir hastane tipik olarak dört katmanı aynı anda çalıştırır.
Harita
Sağlık hizmetlerinde birlikte çalışabilirlik standartları dört katmandan oluşur. Değişim standartları (HL7 v2, CDA, FHIR, DICOM ve DICOMweb) sistemler arasında veri taşır ve IHE profilleri bunları test edilmiş tariflerde birleştirir. openEHR depolanan kaydı yapılandırırken, OMOP araştırma veritabanlarını yapılandırır. SNOMED CT ve LOINC gibi terminolojiler ve SMART on FHIR gibi kimlik standartları, bunların hepsinin içinde kullanılır.
| Katman | Standart | Nedir | 2026'da nerede karşınıza çıkar |
|---|---|---|---|
| Değişim | HL7 v2 | MLLP üzerinden boru hattı ayrılmış mesajlar (ADT, ORU, ORM, SIU) | Hastaneler içinde: kabul, laboratuvar sonuçları, siparişler, planlama. Hala en yaygın arayüz |
| Değişim | CDA / C-CDA | İnsan tarafından okunabilir bir bölümü ve kodlanmış girişleri olan XML klinik belgeleri | Taburcu özetleri, sevk mektupları, ABD C-CDA, MyHealth@EU'daki sınır ötesi özetler |
| Değişim | FHIR (R4, R4B, R5) | REST ve JSON üzerinden web kaynakları (Patient, Observation, Condition…) | Hasta uygulamaları, ulusal API'ler, EHR API'leri, US Core, IPS, EHDS değişim formatı |
| Değişim | DICOM ve DICOMweb | Gömülü meta verilere sahip görüntü nesneleri; DICOMweb onun REST yüzüdür | Her tarayıcı, PACS ve radyoloji görüntüleyici; web görüntüleyiciler DICOMweb kullanır |
| Tarifler | IHE profilleri | Tek bir kullanım durumu için yukarıdakilerin test edilmiş kombinasyonları (XDS, PIX/PDQ, XCA, SWF) | Hastaneler ve bölgeler arasında belge paylaşımı, hasta kimliği, radyoloji iş akışı |
| Depolama | openEHR | Kaydın kendisi için arketip tabanlı klinik veri modeli | Avrupa, İskandinavya, Brezilya'nın bazı bölgelerindeki hastane ve ulusal EHR platformları |
| Araştırma | OMOP CDM | Gözlemsel araştırmalar için ortak bir ilişkisel model | Araştırma ağları, gerçek dünya kanıtları, EHDS ikincil kullanım |
| Terminoloji | SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM | Bulgular, testler, teşhisler, ilaçlar, birimler için kodlar | Yukarıdaki standartların her birinin içinde |
| Kimlik | OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA | Kullanıcının kim olduğu ve uygulamanın neye erişebileceği | Her hasta odaklı uygulama ve her EHR uygulama platformu |
Katmanlar Nasıl Bir Araya Gelir
Sağlık hizmetlerinde birlikte çalışabilirlik standartlarının katmanları, aynı iş akışında bir işi yaparak bir araya gelir: bir HL7 v2 mesajı laboratuvar isteğini taşır, LOINC ve UCUM sonucu kodlar, bir openEHR platformu bunu depolar, bir FHIR API SMART on FHIR oturum açtıktan sonra bir hasta uygulamasına sunar ve bir CDA belgesi bunu başka bir hastaneyle paylaşır.
Bir kan testi, bir öğleden sonra tüm dört katmanı gösterir. Sipariş, HL7 v2 ORM mesajı (değişim) olarak servisten ayrılır. Analizör sonucu, test LOINC ile ve birim UCUM ile kodlanmış olarak HL7 v2 ORU olarak geri gelir (terminoloji). Hastane bunu kendi veritabanında, belki bir openEHR platformunda (depolama) saklar. Hastanın uygulaması, hastanın SMART on FHIR (kimlik) ile giriş yaptıktan sonra, bunu bir Observation olarak bir FHIR API'si aracılığıyla okur. Hastane tam raporu başka bir hastaneyle paylaşırsa, bunu bir IHE XDS kaydı aracılığıyla CDA belgesi olarak yapabilir. Sonuç daha sonra bir araştırma kohortuna katılırsa, OMOP'a dönüştürülür.
Standartlar rakip değildir. Her biri farklı bir iş için inşa edildi ve birini diğeriyle değiştirmek genellikle zaten çalışan bir şeyi yeniden inşa etmek anlamına gelir.
Hangisine İhtiyacınız Var?
Hangi sağlık hizmetlerinde birlikte çalışabilirlik standardına ihtiyacınız olduğu işe bağlıdır: hasta veya klinisyen uygulamaları için SMART on FHIR ile FHIR R4, mevcut hastane sistemlerine bağlanmak için HL7 v2, görüntüler için DICOM ve DICOMweb, tüm belgeler için CDA veya FHIR belgeleri, uzun süreli kayıt depolama için openEHR, araştırma için OMOP ve iki sistemin aynı şekilde davranması gerektiğinde IHE profilleri.
- Hastalar veya klinisyenler için bir uygulama geliştiriyorsunuz: FHIR R4, pazarınızın profilleriyle (uygulama kılavuzları), oturum açma için SMART on FHIR.
- Bir hastanenin mevcut sistemlerine bağlanıyorsunuz: önce HL7 v2'yi bekleyin; satıcı sunduğunda FHIR. HL7 v2 mesajları açıklandı bölümüne bakın.
- Görüntülerle uğraşıyorsunuz: depolama ve aktarım için DICOM, tarayıcıdaki her şey için DICOMweb, yalnızca meta veriler için FHIR ImagingStudy. DICOMweb açıklandı ve ImagingStudy vs DICOMweb bölümlerine bakın.
- Tüm belgeleri (özetler, mektuplar) değiştiriyorsunuz: zorunlu olduğu yerlerde CDA, seçebileceğiniz yerlerde FHIR belgeleri (tip
documentolan bir Bundle). CDA ve C-CDA açıklandı bölümüne bakın. - Bir kaydın onlarca yıl boyunca nasıl saklanacağını tasarlıyorsunuz: openEHR, değişim katmanı olarak FHIR ile. openEHR vs FHIR bölümüne bakın.
- Birçok kayıt üzerinde araştırma yürütüyorsunuz: OMOP, kaynak olarak FHIR ile. Sağlık verilerinin ikincil kullanımı bölümüne bakın.
- İki sistemin aynı şekilde davranmasını istiyorsunuz: kullanım durumunuz için IHE profilini seçin ve ona göre test yapın.
Anpheros Nerede Yer Alıyor
Anpheros Platformu, standart haritasının değişim katmanında, OAuth 2.0 erişimi ve değişiklik bildirimleri için webhook'ları olan bir FHIR R4 sunucusu olarak yer alır, HL7 v2 ORU, CSV veya JSON'dan bir bağlayıcı aracılığıyla laboratuvar sonuçlarını alır. DICOM görüntülerini depolamaz ve bir CDS Hooks hizmeti sunmaz; bunlar hastane sistemlerinde kalır.
Anpheros Platform, hasta merkezli bir kaydın ihtiyaç duyduğu kaynaklara (Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenance ve diğerleri), erişim için OAuth 2.0'a ve değişiklik bildirimleri için webhook'lara sahip bir FHIR R4 sunucusudur. Laboratuvar sonuçları, HL7 v2 ORU, CSV veya JSON'dan laboratuvar bağlayıcısı aracılığıyla gelir. DICOM görüntülerini saklamaz ve bir CDS Hooks hizmeti sunmaz; bunlar hastanenin sistemlerinde kalır ve kayıt onlara işaret eder.
Okuma Sırası
Sağlık hizmetlerinde birlikte çalışabilirlik standartları için iyi bir okuma sırası, FHIR'ın ne olduğu ve HL7 v2'den nasıl farklılaştığı ile başlar, ardından FHIR Observation kaynağı, ardından içinde kullanılan LOINC ve SNOMED CT terminolojileri, ardından görüntüler için DICOMweb, belgeler için CDA ve son olarak kayıtların nasıl saklandığı konusunda FHIR ile karşılaştırılan openEHR ile devam eder.
Alana yeniyseniz: FHIR Nedir → HL7 vs FHIR → FHIR Observation → LOINC ve SNOMED CT → DICOMweb → CDA → openEHR vs FHIR.
İlgili Sayfalar
- HL7 vs FHIR
- HL7 v2 mesajları açıklandı
- CDA ve C-CDA açıklandı
- DICOMweb açıklandı
- openEHR vs FHIR
- FHIR uygulama kılavuzları
- FHIR R4 vs R5
- LOINC kodu nedir?
- SNOMED CT nedir?
- Geliştiriciler için DICOM vs FHIR
- FHIR profilleri ve uzantıları açıklandı
- FHIR terminoloji sunucuları açıklandı
- Sağlık verileri düzenleme haritası
- Avrupa ve ABD'deki ulusal elektronik sağlık kayıtları
- Hastane sistemi entegrasyonu açıklandı
- Tıbbi verilerde yapay zeka
- Sağlık verilerinin ikincil kullanımı
- Sağlık uygulamalarında güvenlik ve kimlik
Kaynaklar
- HL7 International: standartlar
- HL7 FHIR R4 spesifikasyonu
- DICOM standardı, güncel sürüm
- IHE teknik çerçeveleri
- openEHR spesifikasyonları
- OHDSI OMOP Ortak Veri Modeli
- SMART Uygulama Başlatma
Sık sorulan sorular
FHIR diğer tüm standartların yerini mi alıyor?
Hayır. FHIR özel API'lerin ve yavaş yavaş bazı CDA belge değişimlerinin yerini alıyor. HL7 v2 hastaneler içinde iş gücü olmaya devam ediyor, DICOM görüntüler için tek standart olmaya devam ediyor ve openEHR ile OMOP, FHIR'ın cevaplamak için tasarlanmadığı soruları (depolama, araştırma) yanıtlıyor.
Bir standart ile bir IHE profili arasındaki fark nedir?
FHIR veya DICOM gibi bir standart, yapı taşlarını tanımlar. Bir IHE profili belirli blokları seçer, seçeneklerini sabitler ve sistemlerin tek bir görev için bunları tam olarak nasıl kullanması gerektiğini söyler, böylece IHE testlerini geçen iki satıcı bir proje olmadan birlikte çalışabilir.
Ulusal sağlık sistemleri hangi standardı kullanıyor?
Avrupa sistemlerinin çoğu CDA belgeleri ve HL7 v2 ile başladı ve FHIR API'leri ekliyor; EHDS değişim formatı FHIR ve IPS üzerine kuruludur. ABD, hasta erişimi için FHIR US Core ve belge değişimi için C-CDA'yı zorunlu kılıyor.
SNOMED CT ve LOINC nereye uyuyor?
Bunlar değişim standartları değildir; hepsi içinde kullanılan kelime dağarcıklarıdır. Bir LOINC kodu, bir HL7 v2 OBX segmentindeki, bir CDA girişindeki ve bir FHIR Observation'daki testi aynı şekilde tanımlar.
Sandbox'ta ücretsiz deneyin
İlk FHIR çağrınız 5 dakikada. Hasta izniyle yerleşik HL7 FHIR R4 API: sandbox'ta deneyin, ardından kendi uygulamanızı veya klinik sisteminizi bağlayın.
Ücretsiz · 30 sentetik hasta · kart gerekmez
Anpheros, hasta kontrolünde olan ve herhangi bir klinik ile paylaşılabilecek, AB merkezli bir HL7 FHIR R4 platformu üzerinde tıbbi kayıtlar oluşturur. Bu rehberler, sağlığınızı anlamanıza ve düzenlemenize yardımcı olur; doktorunuzun yerini tutmaz.
Anpheros Hakkında →