HL7 v2, HL7 v3 ve FHIR: Hangisi Ne Zaman?

Üçü arasında seçim yapmanın kısa cevabı şu: hastane içinde cihaz, laboratuvar ve hasta hareketi trafiği HL7 v2.x ile akar; klinik dokümanın bütün olarak paylaşılması gerekiyorsa CDA kullanılır; yeni yazdığınız her uygulama, mobil istemci ve dışarıya açtığınız her API FHIR R4 ile konuşur. Bugün sıfırdan bir HL7 v3 mesajlaşma projesi başlatmak için geçerli bir teknik gerekçe yok. Buna karşılık v2'yi "eski" diye eleyip yerine FHIR koymayı planlıyorsanız, hastanedeki hiçbir cihazın sizinle konuşmayacağını baştan kabul etmeniz gerekir.

FHIR'ın kaynak modelini, REST arayüzünü ve temel kavramlarını FHIR Nedir? Sağlık Verisi Standardı Rehberi yazımızda ele almıştık. Bu yazı o bilgiyi tekrarlamıyor; hangi standardı hangi işte seçeceğinize odaklanıyor.

Üç Standart, Üç Farklı Problem

Bu üçünün "birbirinin yeni sürümü" olduğu yanılgısı, sağlık bilişimi projelerinde en pahalı kavram hatasıdır. Üçü farklı yıllarda, farklı problemler için, farklı tasarım felsefeleriyle yapıldı.

HL7 v2 Neden Hâlâ Ayakta

FHIR spesifikasyonunun kendi karşılaştırma sayfası, v2'yi HL7'nin "en yaygın benimsenen" standartlarından biri olarak tanımlıyor ve özellikle yatan hasta ortamlarındaki yaygınlığına dikkat çekiyor. Bunun sebebi nostalji değil: v2 olay tetiklemeli mesajlaşmada çok iyi ve yeniden kullanılabilir segmentler üzerinden sorgu dâhil pek çok iş akışını taşıyabiliyor.

HL7'nin kendi v2-to-FHIR uygulama kılavuzu (sürüm 1.0.0, deneme kullanımı statüsünde), sahada gerçekten karşılaşacağınız mesaj yapılarının listesini veriyor. Bir HBYS'ye bağlanacaksanız bu isimleri tanımanız gerekir:

Z-segmentleri bir genişletme mekanizması değil, bir borçtur

FHIR spesifikasyonu v2'nin en net zayıflığını şöyle koyuyor: Z-segmentleri genişletmeye izin verir ama opaktır; anlamları elle açıklanmak zorundadır ve iki farklı sistem aynı adı farklı anlamlarla kullandığında çakışma kaçınılmazdır. Segmentlerin bağımsız olarak ele alınamaması ve çoğu uygulamanın hiç kullanmadığı veri elemanlarının şemada yer alması da aynı sayfada sayılan sıkıntılar arasında.

Bunun sahadaki karşılığı şudur: bir hastanenin ZDS segmenti başka hastanede tamamen başka bir şey taşır. Üç hastaneye kurulan aynı yazılım, üç ayrı Z-segment haritası taşır. Entegrasyon maliyetinizin gizli çoğunluğu bu haritaların bakımıdır, mesaj ayrıştırıcısının kendisi değil.

HL7 v3 Pazarı Alamadı, CDA Aldı

HL7 v3, mesajlaşma standartlarının bir sonraki nesli olarak tasarlandı. Merkezinde Referans Bilgi Modeli (RIM), standart veri tipleri ve kontrollü terminoloji var. Kâğıt üzerinde tutarlı. Pratikte FHIR spesifikasyonunun kendi değerlendirmesi açık: v3, HL7 v2'nin ulaştığı pazar penetrasyonuna ulaşamadı, bazı büyük elektronik sağlık kaydı projelerinde benimsenmekle birlikte.

Sebeplerini de aynı sayfa sıralıyor ve bunlar mimari kararlar alırken hatırlanmaya değer:

• RIM tel formatına sızar. v3'te modeli anlamadan mesajı okuyamazsınız; FHIR ise RIM bilmeden uygulanabilir.
• classCode ve moodCode her yerdedir. v3 kontrollü kodlu nitelikleri yoğun kullanır; FHIR kodlu alanı yalnızca iş anlamı taşıyan yerlerde kullanır.
• Aynı kavramın çok sayıda modeli vardır. Spesifikasyon "Patient" kavramı için 10 farklı CMET bulunduğunu örnek veriyor; her birinin şeması ve eleman adları farklı olabiliyor. FHIR'da tek bir Patient kaynağı vardır.
• Kısıtlama ile tasarım. v3, sağlık verisinin tüm olasılıklarını RIM içinde temsil etmeye çalışır. FHIR ise "%80 kuralı" uygular: çoğu uygulamada bulunması beklenen alanları koyar, gerisini extension'a bırakır.

Buna karşılık CDA, spesifikasyonun ifadesiyle HL7'nin en yaygın benimsenen v3 standardıdır. Standart bir başlık ve bölümlere ayrılmış klinik içerik taşır; içerik kodlanmamış bir PDF'ten tam kodlanmış bir v3 örneğine kadar değişebilir. Yani "v3 öldü" demek yanlış olur: v3 mesajlaşma yaygınlaşmadı, v3 tabanlı doküman mimarisi yaygınlaştı.

CDA'yı bırakmanız gerekmiyor

FHIR, mevcut CDA yatırımını çöpe atmadan iki yol sunuyor: dokümanı FHIR yerlisi olarak yeniden kurmak istiyorsanız Composition, mevcut CDA R2 dokümanını ikili ek olarak referanslamak istiyorsanız DocumentReference. Kademeli geçiş planlarının çoğu ikinciyle başlar.

FHIR Sürüm Numaralarını Karıştırmayın

Bir ihale şartnamesinde ya da entegrasyon dokümanında "FHIR uyumlu" ifadesi tek başına hiçbir şey söylemez. Sürüm sorulmalıdır. Resmî sürüm geçmişi şöyle:

Uyumluluk kuralı da simetrik değil ve bu ayrımı bilmek pahalı sürprizleri önler. Spesifikasyon, normatif statüye ulaşmış içerik için ileri uyumluluğu garanti ediyor: eski bir sürüme uygun içerik gelecek sürümlerde de uygun kalacak. Geri uyumluluk ise garanti edilmiyor. Pratik önlem de aynı sayfada yazıyor: beklenmedik yeni elemanları ve tanımadığınız kodları, değiştirici olmayan alanlarda yok sayın.

Yeni bir proje için hangi sürüm? R4 seçin. Sebebi teknik üstünlük değil, ekosistem: kütüphanelerin, kamu profillerinin ve dönüşüm araçlarının çoğunluğu R4 hedefliyor. HL7'nin kendi v2-to-FHIR uygulama kılavuzu bile v2 mesajlarını FHIR Release 4.0 Bundle ve kaynaklarına eşliyor. R5'e geçiş, R4 ekosisteminiz oturduktan sonra planlanacak bir iştir.

Burası Kırılıyor: v2'den FHIR'a Eşleme Bir Dönüştürücü İşi Değil

"Bir v2-FHIR dönüştürücü koyarız, olur biter" cümlesi, bu alandaki en yaygın tahmin hatasıdır. FHIR spesifikasyonunun kendi ifadesi bu beklentiyi doğrudan reddediyor: HL7 v2 ile FHIR arasında uluslararası hatta bölgesel düzeyde tutarlı eşleme kuralları tanımlamak pek gerçekçi değildir. Eşleme, uygulamaya özgü olmak zorundadır.

Bunun üç somut sebebi var ve üçü de projenizde ayrı iş kalemi olarak görünür:

1. Kaynak kimliği. Mesajı kaynağa çevirirken, aynı nesnenin farklı mesajlarda aynı URI'ye işaret ettiğinden emin olmanız gerekir. v2 mesajları çoğu zaman bunu yapmaya yetecek tanımlayıcı kümesini taşımaz.
2. Tekilleştirme. Bir mesaj aynı nesneye farklı ayrıntı düzeyleriyle birden çok kez atıfta bulunabilir. Bunları birleştirecek mantığı siz yazarsınız.
3. Anlatı üretimi. Mesajdaki hangi bilginin FHIR kaynağının insan okunur bölümüne gireceği bir tasarım kararıdır. Otomatik değildir.

Buna bir de v2'nin güncelleme semantiği ekleniyor: v2 hem anlık görüntü hem de eylem kodu (action code) yaklaşımını destekler, FHIR ise ağırlıklı olarak anlık görüntü üzerinden çalışır. "Bu OBX satırı bir ekleme mi, güncelleme mi, silme mi" sorusunun cevabı mesajdan her zaman net çıkmaz ve bu belirsizlik doğrudan sizin dönüşüm katmanınıza miras kalır.

Ara katman şart, ama ikisini birbirine konuşturmayın

Doğru mimari, v2 mesajlarını alıp kendi kanonik veri modelinize yazan, FHIR arayüzünü ise bu kanonik modelden üreten bir ara katmandır. v2 ayrıştırıcısının çıktısını doğrudan FHIR serileştiricisine bağlamak kısa vadede hızlıdır, uzun vadede her iki tarafın değişimini aynı anda kırar. Bu tür ara katman tasarımını API geliştirme hizmetlerimiz kapsamında ele alıyoruz.

Türkiye Bağlamı: Yasal Gönderim Bu Üçünün Hiçbirinden Geçmiyor

Bu, Türkiye'de çalışan ekiplerin en sık kaçırdığı nokta. Sağlık Bakanlığı'na yapılan yasal veri gönderimi ne HL7 v2, ne CDA, ne de FHIR üzerinden yürür. SYS web servisinin sözleşmesi tek bir operasyon tanımlar, SYSSendMessage, ve bu operasyon string alıp string döner. Gönderdiğiniz paketin yapısı Bakanlığın kendi XML şemalarıyla tanımlanır.

Endpoint : https://sys.sagliknet.saglik.gov.tr/SYS/SYSWS.svc
Operation: SYSSendMessage   // string in, string out
// Paket şeması WSDL'de değil, ayrı kılavuzlarda tanımlıdır.

Yani FHIR desteği vermek, yasal veri gönderim yükümlülüğünüzü karşılamaz. Bu ikisi ayrı kanallardır ve ayrı ayrı bütçelenir.

Standartların Türkiye'de nerede zorunlu olduğuna gelince: Kayıt Tescil Sistemi kılavuzu, yazılım tipine göre farklı uygunluk testleri tanımlıyor. Laboratuvar Bilgi Yönetim Sistemi (LBYS) için testler arasında "LOINC Standardına Göre Veri Gönderim Durumu" yer alıyor. HBYS tarafında ise "ICD-O Standardına Göre Veri Gönderim Durumu", "MKYS'ye Entegrasyon Durumu" ve "MHRS Entegrasyon Durumu" sayılıyor. PACS için ise teletıp ve teleradyoloji sistemine entegrasyon durumu kontrol ediliyor.

Buradan çıkan kural şu: Türkiye'de tescil testleri terminoloji standartlarına (LOINC, ICD-O) ve ulusal sistemlere entegrasyona bakıyor; mesajlaşma standardı seçimi ise kurum içi bir mimari karardır. Şartnamede "HL7 uyumlu olacaktır" ifadesini gördüğünüzde, bunun tescil şartı değil kurumun kendi iç entegrasyon beklentisi olduğunu bilerek okuyun. Tescil sürecinin ayrıntıları için HBYS ve SBYS tescili yazımıza, gönderim hattının süre ve maliyet tarafı için e-Nabız entegrasyonu maliyet analizimize bakabilirsiniz.

FHIR'ın İki Tasarım Kararı, Entegrasyon Maliyetinizi Doğrudan Etkiliyor

FHIR spesifikasyonu kendi karşılaştırma sayfalarında iki tercihi öne çıkarıyor. İkisi de soyut görünür, ikisinin de faturası somuttur.

Bağlam örtük değil, açık taşınır

v3'te bağlam model üzerinden yürütülür ve çıkarım yapılabilir: bir öğenin hangi hastaya, hangi başvuruya ait olduğu, bulunduğu yerden anlaşılır. FHIR bunu tersine çevirir; her kaynak gerekli referansları kendi içinde taşır ve spesifikasyonun ifadesiyle her kaynak örneği kendi kendine yeter.

Bunun pratik sonucu, veri katmanınızda görünür. FHIR tarafına yazarken her Observation için subject ve encounter referanslarını doldurabilmeniz gerekir. Kaynak sisteminizde bu ilişki "aynı mesajda geldiler" varsayımıyla örtük tutuluyorsa, dönüşüm katmanında bunu açığa çıkaracak bir eşleştirme mantığı yazmak zorunda kalırsınız. Bu, tahminlerde en sık unutulan kalemdir.

%80 kuralı, extension'ı istisna değil rutin yapar

FHIR yalnızca uygulamaların çoğunda bulunması beklenen alanları kaynağa koyar; gerisi extension ile taşınır. Extension'ların v2'nin Z-segmentlerinden farkı, keşfedilebilir bir URI ile tanımlanmalarıdır. Yani anlamı belgelenmiş ve adreslenebilirdir, çakışma riski yoktur.

Ama bir yanılgıya düşmeyin: extension kullanmak "standart dışına çıkmak" değildir, FHIR'ın normal çalışma biçimidir. Türkiye'ye özgü alanların (kurum kodu, SKRS karşılıkları, SGK ile ilgili nitelikler) bir kısmı ancak extension ile taşınabilir. Projenin başında "extension kullanmayacağız, saf FHIR olacak" diye karar veren ekipler, altıncı haftada bu kararı bozar. Baştan bir extension isim alanı ve yönetişim kuralı tanımlayın.

Şartnameye Yazacağınız Beş Soru

Bir sağlık entegrasyonu ihalesinde ya da tedarikçi görüşmesinde, standart tartışmasını beş somut soruya indirebilirsiniz. Cevaplar yazılı alınmalıdır.

1. Hangi sürüm? "FHIR uyumlu" yetmez. R4 (4.0.1) mı, STU3 (3.0.2) mü, R5 (5.0.0) mi? v2 tarafında hangi sürüm profilleniyor?
2. Hangi kaynaklar ve hangi mesaj yapıları? Patient, Encounter, Observation listesi ya da ADT_A01, ORU_R01 listesi. İsim isim.
3. Z-segment haritası var mı? Varsa dokümanı talep edin. Yoksa, tersine mühendislik eforunu tahmine ekleyin.
4. Extension isim alanı ne? Yerel alanlar hangi URI altında tanımlanıyor, kim yönetiyor?
5. Test ortamı ve örnek mesaj kümesi sağlanacak mı? Gerçek örnek mesaj olmadan yazılan ayrıştırıcı, üretimde ilk hafta kırılır.

Beşinci madde küçük görünür. Değildir. Sahada en sık yaşanan gecikme, karşı tarafın örnek mesaj üretmesinin haftalar sürmesidir.

Karar Tablosu

Sırada Ne Var

Karar vermeden önce yapılacak tek bir envanter çalışması var ve bir günlük iştir: entegre olacağınız her sistem için üç soruyu yazılı cevaplayın. Hangi protokolü bugün konuşuyor? Karşı taraf yeni bir arayüz açmaya istekli mi, yoksa mevcut arayüzü mü kullanacaksınız? Değişiklik talebiniz için kimin bütçesi var?

Üçüncü sorunun cevabı çoğu zaman standart seçimini belirler. Teknik olarak en iyi seçim, karşı tarafın uygulamayacağı seçimdir. Sağlık projelerindeki yaklaşımımızı sağlık ve medikal yazılım sayfasında, kendi kapsamınız için bir efor bandını proje fiyat hesaplama aracıyla görebilirsiniz.

Bu yazıdaki karşılaştırmalar ve sürüm bilgileri 25 Eylül 2026 tarihinde HL7 International'ın resmî spesifikasyon sayfalarından doğrulanmıştır: hl7.org/fhir/R4/comparison.html, comparison-v2.html, comparison-v3.html, comparison-cda.html, versions.html, ayrıca R4 (4.0.1), R4B (4.3.0) ve R5 (5.0.0) yayın sayfaları ile build.fhir.org/ig/HL7/v2-to-fhir/ adresindeki HL7 v2-to-FHIR uygulama kılavuzu. Türkiye'ye ilişkin ayrıntılar SYS servis sözleşmesinden ve Sağlık Bakanlığı Kayıt Tescil Sistemi kılavuzundan alınmıştır. Standart sürümleri ve kılavuzlar güncellenir; mimari kararı vermeden önce ilgili sayfayı teyit edin.