Sağlık yazılımı ne zaman tıbbi cihaz sayılır

Sağlık yazılımı geliştiren bir ekip için bu sorunun cevabı projenin süresini ve maliyetini değiştiriyor. Aynı kod, ürünün nasıl tanımlandığına göre çok farklı bir uyum yükü taşıyabiliyor.

İki uygulama düşünün. İkisi de kullanıcının girdiği belirtileri alıyor, bir algoritma çalıştırıyor ve bir liste döndürüyor. Kod neredeyse aynı. Biri tıbbi cihaz mevzuatına tabi, diğeri değil.

Farkı yaratan şey, uygulama mağazasındaki açıklama metni. Birincisi "belirtilerinize göre olası durumlar hakkında bilgi verir" diyor. İkincisi "belirtilerinizi değerlendirir ve olası tanıyı gösterir" diyor. İkinci cümle, ürünü tanı amacıyla sunulmuş hâle getiriyor ve bununla birlikte risk sınıflandırması, uygunluk değerlendirmesi, teknik dosya, klinik değerlendirme ve piyasaya arz sonrası izleme yükümlülükleri devreye giriyor.

Bu, sağlık teknolojisi projelerinde gördüğüm en pahalı ve en kolay önlenebilir hata. Ürün tanımını pazarlama ekibi yazıyor, kimse hukuki sonucunu düşünmüyor ve ürün, üstlenilmediği bir uyum rejiminin içine giriyor.

Kullanım amacı bir hukuki metin

Buradan çıkan pratik kural şu. Ürün tanımı, gizlilik politikası kadar dikkatle yazılmalı ve yayımlanmadan önce hukuki incelemeden geçmeli.

İnceleme yalnızca mağaza açıklamasıyla sınırlı kalmamalı. Web sitesindeki başlık, tanıtım videosundaki cümle, satış sunumundaki iddia ve destek dokümanındaki ifade de aynı sonucu doğurabilir. Bir yerde "tanı koyar" dediyseniz, başka yerde "bilgi amaçlıdır" yazmanız bu beyanı geri almaz.

Kararı baştan vermek gerekiyor. Ürün tıbbi cihaz olacaksa, o rejimin gerektirdiği süreç en baştan kurulur ve bu bir maliyet kalemi olarak plana girer. Olmayacaksa, her metinde bu sınırın korunması ürün geliştirme kuralı hâline getirilir.

Sağlık verisinde erişim mimarisi

6698 sayılı Kanun'un 6. maddesi sağlık verisini özel nitelikli kişisel veri olarak sayıyor ve işlenmesini daha dar şartlara bağlıyor. Bu nitelendirmenin teknik karşılığı çoğu projede eksik kalıyor.

Sık gördüğüm tablo şu. Uygulama çalışıyor, veriler tutuluyor, ama sistemde herkes her şeyi görebiliyor. Geliştirici üretim veritabanına bakabiliyor, destek ekibi hasta kaydını açabiliyor, yönetici raporlarda ham veri görebiliyor. Bu, erişimin sınırlandırılmadığı anlamına geliyor ve bir denetimde savunulması güç.

Doğru kurgu rol tabanlı erişimle başlıyor ama orada bitmiyor. Her erişimin kaydedilmesi, kaydın kim tarafından hangi amaçla yapıldığını göstermesi ve olağandışı erişimin fark edilebilmesi gerekiyor. Bir hasta kaydını gece yarısı açan bir kullanıcı varsa, bunun sistemde görünür olması lazım.

Test ortamı ayrı bir başlık. Gerçek hasta verisiyle test yapmak, sağlık teknolojisinde en yaygın ve en riskli alışkanlık. Maskelenmiş veya sentetik veriyle çalışmak bu riski büyük ölçüde ortadan kaldırıyor ve teknik olarak zor bir iş değil.

Klinik karar destek ve sorumluluk

Yapay zekâ destekli karar destek sistemleri, sorumluluğun kimde olduğu sorusunu doğuruyor. Uygulamada güvenli kurgu, sistemin öneri üretmesi ve nihai kararın yetkili sağlık profesyoneline bırakılması.

Bu kurgunun kâğıt üzerinde kalmaması için üç kaydın birlikte tutulması gerekiyor. Sistemin ürettiği öneri, önerinin dayandığı girdiler ve sağlık profesyonelinin verdiği son karar. Üçü ayrı ayrı tutulursa sonradan eşleştirilemez, hiç tutulmazsa sorumluluğun nerede olduğu gösterilemez.

Buna bir ölçüt eklemekte fayda var. Sağlık profesyonelinin sistemin önerisini reddetme oranı izlenmeli. Bu oran sıfıra yaklaşıyorsa, insan denetimi biçimsel hâle gelmiş demektir ve o noktada sistem fiilen kararı kendisi veriyor olur. Bu tespit, sorumluluk tartışmasında belirleyici olabilir.

Uzaktan sağlık hizmeti

Uzaktan sağlık hizmetleri Sağlık Bakanlığı düzenlemeleri çerçevesinde yürütülüyor. Hangi hizmetlerin uzaktan sunulabileceği, kayıt yükümlülükleri ve hizmetin sınırları ikincil mevzuatta belirleniyor. Bu düzenlemeler zaman içinde değişebildiği için, ürün tasarlanırken güncel metne bakılması gerekiyor.

Değişmeyen ilke şu. Yüz yüze muayene gerektiren durumlar uzaktan karşılanamaz. Bir uzaktan sağlık uygulaması, bu sınırı aşan bir talebi tanıyıp yönlendirebilmeli. Sistemin "bu durum için lütfen hekime başvurun" diyebilmesi, bir kullanılabilirlik özelliği değil hukuki bir gereklilik.

Projeye başlarken

Sağlık teknolojisi projelerinde ilk toplantıda cevaplanması gereken soru ürünün ne yapacağı değil, ne olduğunu beyan edeceği. Bu cevap verilmeden yazılan her satır kod, yanlış rejime göre yazılmış olabilir.

İkinci soru veri modeline ait. Hangi veri gerçekten gerekli, kim görebilecek, erişim nerede kaydedilecek ve amaç sona erdiğinde ne olacak. Bu dört sorunun cevabı tabloların tasarımını doğrudan belirliyor ve sonradan değiştirilmesi, geçmiş hasta verisini taşımayı gerektirdiği için hem teknik hem hukuki bir sorun doğuruyor.