TİTCK CDSS Klinik Validasyon Raporu Nasıl Hazırlanır?

CDSS klinik validasyon raporu, TİTCK dosyasında en çok geri dönen ve en çok hafife alınan belgedir. Çoğu ekip "modelimiz %94 doğru" cümlesini bir tablo ile destekleyip bunu validasyon sanır. Oysa kurum bağımsız, önceden planlanmış ve hedef popülasyonda ölçülmüş bir kanıt zinciri ister. Doğrulama "model iyi çalışıyor" değil, "model, iddia edilen kullanım amacında, iddia edilen popülasyonda, önceden tanımlanmış kabul kriterlerini karşıladı" iddiasının istatistiksel ispatıdır.

Bu yazıda raporun ne içermesi gerektiğini, hangi standartlara dayandığını, kimin neyi hazırladığını ve dosyanın en sık çöktüğü yerleri bir metodolog gözüyle açıklıyorum.

Klinik validasyon ile analitik/teknik validasyonu karıştırmayın

IMDRF'nin SaMD kanıt çerçevesi üç ayrı katman tanımlar ve TİTCK dosyası da bu mantıkla okunur:

• Valid clinical association: Modelin çıktısının hedeflediği klinik durumla gerçekten ilişkili olduğunun gösterilmesi (literatür + mantıksal gerekçe).
• Analytical/technical validation: Yazılımın girdiyi doğru işlediği, çıktıyı teknik olarak güvenilir ürettiği (verification). Bu mühendislik testidir, klinik validasyon değildir.
• Clinical validation: Çıktının hedef popülasyonda klinik olarak anlamlı ve doğru olduğunun, bağımsız bir veride ölçülmesi.

Sık görülen hata: ekip analitik validasyonu (kod test ediliyor, tekrarlanabilirlik sağlanıyor) yapıp bunu klinik validasyon diye sunar. TİTCK bu ikisini ayrı sorar. Klinik validasyon raporu üçüncü katmandır ve istatistik çekirdeği buradadır.

Raporun zorunlu çekirdeği: önceden tanımlanmış validasyon protokolü

Geçerli bir validasyon raporu, sonuçlardan önce yazılmış bir protokolün uygulanmasıdır. Sonuçları görüp metrik seçmek (HARKing) raporu çürütür. Protokol şunları sabitlemelidir:

• Kullanım amacı (intended use): Tam, tek cümlelik tanım. Klinik durum, hedef popülasyon, kullanıcı (hekim mi, hasta mı), cihazın karar sürecindeki rolü (bilgilendirici / tetikleyici / otonom). Performans hedefi bu cümleden türetilir.
• Birincil ve ikincil endpoint'ler: Sınıflandırma için duyarlılık/özgüllük ve AUC-ROC; segmentasyon için Dice/Hausdorff; risk skorları için kalibrasyon (calibration-in-the-large, slope, Brier skoru). Tek başına AUC yeterli değildir, kalibrasyon ve klinik fayda (decision curve analysis) eklenmelidir.
• Önceden hesaplanmış örneklem büyüklüğü: Beklenen performans, kabul edilebilir alt sınır ve güç (power) ile gerekçelendirilmiş n. "Elimizdeki veri kadar" cevabı kabul görmez.
• Kabul kriterleri: Çalışma başlamadan yazılmış eşikler (ör. duyarlılığın alt %95 güven sınırı belirlenen klinik eşiğin üzerinde).
• Ground-truth (referans standart) tanımı: Nasıl, kim tarafından, kaç okuyucuyla oluşturuldu; okuyucular arası uyum (ICC, kappa) ile nitelendirildi mi.

Standalone performans ve veri sızıntısı: dosyanın kırılma noktası

CDSS validasyonunun kalbi standalone (bağımsız) performanstır: modelin, klinik iş akışından izole, sabit bir test kümesinde ölçülmüş çıktısı. İki kural pazarlık konusu değildir:

• Veri sızıntısı (data leakage) yok: Train/validation/test ayrımı hasta bazında yapılmalı. Aynı hastanın farklı görüntüleri/kesitleri hem eğitimde hem testte olamaz; aksi halde performans tipik olarak gerçekçi olmayan biçimde şişer. Bu, TRIPOD-AI ve PROBAST-AI'nin doğrudan denetlediği bir bias kaynağıdır.
• Test kümesi tek kullanımlık: Final model üzerinde tek sefer çalıştırılır; test kümesine bakarak model seçilmez.

Standalone performans gerçek dünyada yeterli değilse, kullanıcıyla birlikte performans (örneğin radyolog + AI) için çok-okuyuculu çok-vakalı (MRMC) tasarım gerekir. Karar destek iddiası "hekim performansını artırır" ise, bunu standalone metrik değil MRMC kanıtlar.

CDSS validasyon protokolünüzdeki örneklem büyüklüğünün, endpoint'lerin ve veri sızıntısı kontrollerinin TİTCK denetimine dayanıp dayanmadığını bağımsız olarak değerlendirmek için 15 dakikalık ücretsiz scoping talep edin.

Training-data temsililiği ve alt grup performansı

Rapor, eğitim ve test verisinin hedef Türk klinik popülasyonunu temsil ettiğini göstermelidir. Bu hem TİTCK hem de yaklaşan düzenlemeler için merkezi bir konudur:

• Veri karakterizasyonu: Yaş, cinsiyet, hastalık şiddeti dağılımı; cihaz/üretici/protokol çeşitliliği (örneğin farklı BT/MR cihazları, farklı kesit kalınlıkları, farklı merkezler).
• Domain shift riski: Tek merkez, tek cihazla eğitilmiş model başka merkezde düşebilir. External validation (farklı merkez/cihaz/popülasyon) raporun gücünü belirler.
• Alt grup (fairness) analizi: Performansın cinsiyet, yaş ve klinik alt gruplarda ayrı ayrı raporlanması. AB Yapay Zeka Tüzüğü Madde 10 (yüksek riskli sistemler için veri yönetişimi ve temsililik yükümlülükleri, Ağustos 2026'da uygulanmaya başlıyor) bu beklentiyi sertleştiriyor; TİTCK dosyanız EU-MDR ile birlikte ilerliyorsa şimdiden bu yapıda kurmak mantıklıdır.

Risk yönetimi bağı: rapor cihaz dosyasından kopuk olamaz

Klinik validasyon raporu, ISO 14971 risk yönetimi dosyasına bağlanmalıdır. Tıbbi cihaz risk değerlendirmesinin kendisi bizim şeridimizde değildir, ancak validasyon istatistiği risklerle aşağıdaki noktalarda kesişir:

• Yanlış pozitif/yanlış negatif maliyeti: Klinik eşik, yalnızca Youden indeksi gibi istatistiksel optimumla değil, hatanın klinik sonucuyla seçilmelidir. Kaçırılan bir patolojinin maliyeti gereksiz bir ileri tetkikten yüksekse, çalışma duyarlılığı önceler.
• Artık risk (residual risk): Performans güven aralıklarının alt sınırı, kabul edilen artık risk seviyesini desteklemelidir.
• İzlenebilirlik: Validasyon sonuçları, risk dosyasındaki risk kontrol önlemlerinin etkinliğine kanıt olarak referanslanmalı; bu zincir CER ve teknik dosyada tutarlı olmalıdır.

Kim neyi hazırlar?

Rapor tek kişinin değil, tanımlı rollerin işidir:

• Üretici / kalite ekibi: Kullanım amacı tanımı, ISO 13485 kalite sistemi, ISO 14971 risk dosyası, ürün ruhsat evrakı. (Bunlar düzenleyici/QMS işidir, biyoistatistik şeridi değil.)
• Sorumlu/koordinatör araştırmacı (hekim): Prospektif veride etik kurul sorumluluğu, klinik yürütme ve hasta güvenliği. Klinik araştırmanın baş araştırmacısı bir hekimdir.
• Metodolog / biyoistatistikçi: Validasyon protokolünün tasarımı, örneklem büyüklüğü, endpoint ve kabul kriterleri, istatistiksel analiz planı, sonuç analizi ve raporun TRIPOD-AI/PROBAST-AI uyumlu istatistik bölümü. İsimli metodolog olarak imza burada atılır.

Serteser Danışmanlık üçüncü rolü üstlenir: dosyanın denetimde ilk bakılan ama gözden en çok kaçan istatistik çekirdeğini tasarlar ve imzalar. Hekim sorumlu araştırmacılık, çıkar çatışması doğuran (danışmanın kendi ürün geliştirdiği) terapötik alanlar ve QMS belgelendirmesi kapsam dışıdır.

Sık Yapılan Hatalar

• Analitik validasyonu klinik validasyon sanmak: Kod testi ve tekrarlanabilirlik klinik kanıt değildir; bağımsız veride performans gerekir.
• Protokolü sonradan yazmak: Sonuçlara bakıp metrik ve eşik seçmek (HARKing) raporu denetimde çökertir; protokol verilerden önce kilitlenmeli ve mümkünse önceden kaydedilmelidir.
• Veri sızıntısını gözden kaçırmak: Görüntü/kesit bazlı split ile hasta bazlı split karıştırılınca performans yanıltıcı biçimde şişer; PROBAST-AI bunu doğrudan yüksek bias olarak işaretler.
• Tek merkez verisini "yeterli" varsaymak: External validation ve alt grup temsililiği olmadan TİTCK ve EU-MDR/AI Act beklentileri karşılanmaz; "%94 doğruluk" cümlesi tek başına bir validasyon raporu değildir.

İlgili Yazılar

• SaMD Klinik Validasyon Çalışması Nasıl Tasarlanır?
• MRMC Çok-Okuyuculu Çalışma: Yapay Zeka Tanı Performansı
• Yapay Zeka Validasyonunda Veri Sızıntısı ve Train/Test Split

TİTCK CDSS validasyon raporunun başarısı regülasyon diline değil, arkasındaki istatistik çekirdeğinin denetime dayanıp dayanmadığına bağlıdır. Önceden kilitlenmiş bir protokol, gerekçeli örneklem büyüklüğü, sızıntısız standalone performans ve temsili veri, dosyanızı "geri dönen" değil "geçen" bir belge yapar. Kapsam, süre ve bütçe her dosyada farklıdır; bunları ücretsiz scoping görüşmesinde netleştiririz.

Ücretsiz Scoping Görüşmesi