Healthcare Interoperability 2026 yılında HL7 FHIR R5 ile sağlık IT’sinin standardı haline geldi. HIMSS 2025 Interoperability Survey, sağlık kurumlarının %78’inin FHIR R4 veya R5 üzerinden veri paylaşımı yaptığını gösteriyor. ONC Final Rule 2024 ABD’de USCDI v4 sertifikalı EHR’lerin FHIR R5 desteklemesini zorunlu kıldı.

HL7 FHIR R5: 2026 Standartlaşma ve Pazar Bağlamı

HL7 FHIR (Fast Healthcare Interoperability Resources), HL7 International tarafından geliştirilen RESTful healthcare interop standardı. FHIR R5 (Release 5), Mart 2023’te yayınlandı ve 2025-26’da production benimsemesi hızlandı. Önceki HL7 v2 (segment-based) ve HL7 v3 (XML-based) zorlu olduğu için sınırlı benimsendi; FHIR JSON-first RESTful API yaklaşımıyla geliştirici dostu. Konuyla ilişkili olarak Astro 5 2026: Server Islands ve Content Layer Production Implementation rehberimiz detaylı incelemeyi içerir.

HIMSS 2025: ABD’de sertifikalı EHR pazarının %94’ü Epic, Cerner (Oracle Health), Allscripts, MEDITECH FHIR R4 destekliyor; R5 adopsiyonu %38 ve hızla büyüyor. HL7 International 2025: 2.000+ FHIR Implementation Guide yayınlandı; US Core, International Patient Summary (IPS), Da Vinci PDex referans IG’ler. Statista 2025: küresel sağlık IT pazarı 392 milyar dolar.

FHIR R5 Resource Modeli

FHIR temel kavramı resource: standartlaştırılmış data structure (Patient, Observation, Condition, Encounter, MedicationRequest, …). R5’te 150+ resource türü; her biri RESTful endpoint olarak expose ediliyor. Reference field’lar ile resource’lar arası ilişki kuruluyor; Bundle resource ile ilişkili resource’lar tek transaction’da gönderilebiliyor.

Resource Açıklama R4 → R5 Değişim
Patient Hasta demografik bilgi Backward-compatible
Observation Lab, vital, soru cevabı triggeredBy yeni
Condition Tanı, sorun participant, severity yeniden
Encounter Klinik buluşma subjectStatus yeni
MedicationRequest İlaç reçetesi doNotPerform yeni
DocumentReference Klinik belge referansı practiceSetting kaldırıldı
ImagingStudy DICOM çalışmaları imageRegion yeni
InventoryItem Envanter (yeni R5) R5 yeni resource
Healthcare Interoperability 2026: HL7 FHIR R5 ile Kurumsal Implementation — Görsel 1
Healthcare Interoperability 2026: HL7 FHIR R5 ile Kurumsal Implementation — Görsel 1

SMART on FHIR: OAuth 2.0 + EHR Launch Context

SMART on FHIR (Substitutable Medical Apps, Reusable Technologies), FHIR üzerine third-party app’lerin EHR ile güvenli entegrasyonunu sağlayan standart. OAuth 2.0 ile authorization, launch context (patient, encounter) ile EHR-app arası state. SMART App Launch Framework 2.0 (2024) ile OAuth 2.1 desteği, asymmetric client authentication, PKCE zorunluluğu.

Argonaut Project 2024 itibarıyla 600+ SMART app sertifikalı; Epic App Orchard, Cerner Code Marketplace, Apple Health entegrasyonu SMART üzerinden. Standart scope’lar: patient/Observation.read, user/MedicationRequest.write, system/Patient.read.

Bulk Data Access: Population-Scale Export

FHIR Bulk Data Access (Flat FHIR, asynchronous $export operation) ile büyük hasta populasyonlarının NDJSON formatında export edilmesi sağlanır. CMS Patient Access ve Provider Directory Final Rule (2020) ABD’de payer’lar için zorunlu. Bulk Data 2.0 (2024) ile multi-tenant export, group-level filter, error recovery iyileştirildi.

  • $export operation: Asynchronous request → status polling → NDJSON download
  • Group-level export: Hasta grubu (örn: practice panel) filtering
  • Time-based filter: _since parameter incremental sync
  • Resource type filter: _type=Patient,Observation,Encounter
  • NDJSON format: Newline-delimited JSON, stream-friendly

İlgili konu: Sağlık IT entegrasyon rehberimizde Bulk Data ile data warehouse pipeline’larını detaylandırdık.

Terminology Binding: SNOMED CT, LOINC, ICD-10

FHIR resource’ları structure sağlar; klinik kavramlar terminoloji standartlarına bound edilir. SNOMED CT (clinical findings, procedures), LOINC (lab tests, observations), ICD-10/11 (diagnoses), RxNorm (medications), CPT (procedures). ValueSet ve CodeSystem resource’ları terminoloji binding yönetimini sağlar.

HL7 Terminology Service tarafından (terminology.hl7.org) hosted ValueSet’ler community standard. Implementation Guide’lar required vs preferred binding tanımlar; required’da non-standard kod gönderilemez. Türkiye’de SUT (Sağlık Uygulama Tebliği) kodlarının FHIR ValueSet’e mapping’i ulusal interop için kritik.

Healthcare Interoperability 2026: HL7 FHIR R5 ile Kurumsal Implementation — Görsel 2
Healthcare Interoperability 2026: HL7 FHIR R5 ile Kurumsal Implementation — Görsel 2

HAPI FHIR JPA Server: Açık Kaynak Reference

HAPI FHIR (Java), açık kaynak FHIR server reference implementation. JPA Server PostgreSQL veya MS SQL backend ile production deploy. 2025 verisi: 500+ kuruluşta production’da; SmileCDR ticari versiyonu enterprise destek sağlıyor. Microsoft FHIR Server (Azure), Google Cloud Healthcare API, AWS HealthLake managed FHIR seçenekler.

FHIR Server Lisans Hosting Use Case
HAPI FHIR JPA Apache 2.0 Self-hosted Pilot, geliştirme
SmileCDR Ticari (HAPI tabanlı) Self-hosted / SaaS Enterprise
Microsoft FHIR Server Açık kaynak (depreca) Azure API for FHIR Azure ekosistem
Google Cloud Healthcare API SaaS GCP GCP ekosistem
AWS HealthLake SaaS AWS AWS ekosistem
Firely Server Ticari (.NET) Self-hosted .NET shop

USCDI v4 ve ONC Final Rule

USCDI (United States Core Data for Interoperability) ABD’de sertifikalı EHR’lerin desteklemesi gereken veri elemanları setini tanımlar. USCDI v4 (2025) 23 kategori, 90+ data element içeriyor; sosyal determinants of health (SDOH) eklenmiş. ONC Final Rule 2024 USCDI v4 + FHIR R5 zorunlu kıldı; uyumsuz EHR’ler sertifikasını kaybediyor.

Sektörel Use Case: EHR, Payer, Public Health

EHR (Epic, Cerner, Allscripts) tarafında FHIR app marketplace ve patient portal. Payer tarafında CMS Patient Access için Patient Access API ve Provider Directory API. Public health tarafında CDC eCR (electronic case reporting) ve immunization registry FHIR-based. Türkiye’de e-Nabız ve HSP (Sağlık-Net) FHIR R4 üzerinden interop yapıyor.

Healthcare Interoperability 2026: HL7 FHIR R5 ile Kurumsal Implementation — Görsel 3
Healthcare Interoperability 2026: HL7 FHIR R5 ile Kurumsal Implementation — Görsel 3

Kurumsal FHIR Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

  • Terminoloji haritalama ve subset tanımlamasının atlanması — SNOMED CT, LOINC, ICD mapping eksikliği
  • Profile uyumluluğunun (US Core, IPS) yapılmaması — generic FHIR ama use case spesifik değil
  • Consent management ve patient privacy preferences için Consent resource’unun ihmal edilmesi
  • Bulk Data Access ile data warehouse pipeline’ının kurulmaması — analytics zayıf
  • Versiyon yönetimi (FHIR R4 ve R5 hibrit) için strategy eksikliği
  • SMART on FHIR app güvenlik review’unun atlanması — third-party app risk

Sonuç

HL7 FHIR R5 2026’da sağlık IT’nin interop standardı. ABD ONC Final Rule zorunluluk; AB EHDS (European Health Data Space) 2025’te yürürlüğe girdi ve Avrupa’da FHIR’ı zorunlu kılıyor. Türkiye’de e-Nabız ve HSP FHIR’a geçti. Pilot için HAPI FHIR JPA server + US Core profile + SMART on FHIR auth 3 ayda kurulabilir; production-grade için managed çözüm (Azure API for FHIR, Google Healthcare API, AWS HealthLake) gerekli. Terminoloji binding ve consent management ihmal edilen ama kritik noktalar.

Sıkça Sorulan Sorular

FHIR R4 ve R5 arasındaki kritik fark nedir?

R5 backward-compatible değil; bazı resource’larda field değişimleri var. Major eklenenler: InventoryItem, ActorDefinition, Permission resource’ları; SDOH için new ValueSet’ler. Migration için Capabilities resource karşılaştırma + Implementation Guide review gerekiyor.

SMART on FHIR ile OAuth 2.0 farkı nedir?

SMART OAuth 2.0/2.1 üzerine launch context (patient, encounter) ve healthcare-spesifik scope’lar (patient/, user/, system/) ekleyen profile. EHR-app arası state passing ve launch flow standardize ediyor. Generic OAuth ile karşılaştırıldığında healthcare-aware.

HAPI FHIR production-ready mi?

Evet, 500+ kuruluşta production’da. Performance tuning (PostgreSQL config, search parameter indexing) gerekiyor; >1M resource scale için tuning şart. SmileCDR ticari versiyonu enterprise destek + advanced features sağlıyor.

Bulk Data Access ile real-time API farkı?

Bulk Data asynchronous, populasyon-scale (1M+ patient) export için; real-time API synchronous, hasta başına anlık. Analytics ve data warehouse için Bulk Data; clinical workflow için real-time API. İki yaklaşım birbirini tamamlar.

Türkiye’de e-Nabız FHIR uyumlu mu?

Evet, e-Nabız FHIR R4 desteği var ve SUT terminoloji mapping yapılıyor. Sağlık-Net (HSP) FHIR endpoint’leri SOAP+REST hibrit; private hospital’lar e-Nabız entegrasyonu için FHIR yaygın seçim. Sağlık Bakanlığı 2026 roadmap’inde FHIR R5 geçiş.

Ömer ÖNAL

Yazılım Mimarı | Yapay Zeka LLC. Ölçeklenebilir SaaS, .NET Core altyapıları ve Otonom AI süreçleri inşa ediyorum. Kod değil, sistem tasarlarım.

Yorum (1)

  1. Ömer ÖNAL
    Mayıs 23, 2026

    FHIR’i ‘sadece API expose ederiz’ diye yaklaşan sağlık IT projeleri 9-12 ay sonra terminoloji haritalama (SNOMED CT, LOINC, ICD-10), profile uyumluluğu (USCDI v4) ve consent yönetimi konularında saplanıyor. Doğru sıra: önce terminoloji subset ve profile catalog, sonra resource modeling ve validation, en son production endpoint. HAPI FHIR JPA server pilot için ideal. — Ömer Önal

Yorum Yap

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir