Sağlık Kuruluşları İçin Yerel Yapay Zekâ Kurulumu

Sağlık kuruluşunda yerel yapay zekâ, dil modelinin (LLM) ve belge aramanın kurumunuzun kendi sunucusunda çalıştığı kurulumdur. Hasta dosyası, aranabilir kopyalar, sohbet geçmişi ve kayıtlar sizin belirlediğiniz ortamda kalır; hiçbiri üçüncü bir şirketin sunucusuna gitmez.

Gerekçe verinin niteliğinden gelir. KVKK md. 6/1, sağlığa ilişkin verileri özel nitelikli kişisel veri sayar. Epikriz, tetkik sonucu, reçete ya da hasta şikâyet yazısı bu kapsamdadır. Bu belgeleri bir yapay zekâ aracına verdiğinizde üç soruyu yanıtlayabilmeniz gerekir: veri hangi sunucuda işleniyor, kimler görüyor, kaydı tutuluyor mu? Özel hastane de olsanız küçük bir poliklinik de olsanız, genel amaçlı bir bulut sohbet aracına hasta belgesi yüklemeden önce bu üç soruya yazılı cevabınız olmalı.

Biz bu kurulumu “kapalı sistem” olarak tanımlıyoruz: model, arama dizini, kayıtlar ve yedekler kurumunuzun sınırları içinde çalışır, dışarı açılan her bağlantı tek tek sayılır ve gerekçelendirilir.

Hastane için yerel yapay zekâ kurulumundan bu sayfada anlaşılan, idari ve belge işleridir. Aynı çerçeve özel klinikler, poliklinikler, tıp merkezleri, ağız ve diş sağlığı merkezleri, laboratuvarlar ve küçük ile orta ölçekli özel hastaneler için geçerlidir. Teşhis, tedavi önerisi ve triyaj kapsamımızın dışındadır.

Hasta verisini yapay zekâ ile işlemek KVKK’nın özel nitelikli kişisel veri kurallarına tabidir: kanun sağlık verisinin işlenmesini kural olarak yasaklar ve sekiz şarttan birinin bulunmasına bağlar. Sağlık kuruluşunu en çok ilgilendiren hükümler şunlardır:

• Md. 6/3 (işleme şartları): Açık rıza bu şartlardan biridir. Sağlık kuruluşları için en sık gündeme gelen şart e bendidir. Bu bende göre sır saklama yükümlülüğü altındaki kişiler ya da yetkili kurum ve kuruluşlar, tıbbi teşhis, tedavi ve bakım hizmetlerinin yürütülmesi için veriyi gerektiği ölçüde işleyebilir. Sağlık hizmetlerinin planlanması, yönetimi ve finansmanı ile kamu sağlığının korunması ve koruyucu hekimlik de aynı bentte sayılır. Hangi şarta dayandığınıza siz ve hukuk danışmanınız karar verirsiniz.
• Md. 6/4 (ek önlemler): Özel nitelikli veride Kurul’un belirlediği yeterli önlemleri almanız da şarttır.
• Md. 4/2 (ölçülülük): Veri, işlendiği amaçla bağlantılı, sınırlı ve ölçülü olmalıdır. Yapay zekâya hasta dosyasının tamamını değil, işin gerektirdiği kısmını açarsınız.
• Md. 10 (aydınlatma): İşleme amacını ve verinin kimlere aktarılabileceğini ilgili kişiye bildirirsiniz.
• Md. 12 (güvenlik): Hukuka aykırı erişimi önleyecek teknik ve idari tedbirleri alırsınız. Verinizi sizin adınıza başka bir kişi işliyorsa, örneğin uzaktan destek veren bir sağlayıcı, tedbirlerden onunla müştereken sorumlu olursunuz. Verinin kanuni olmayan yollarla başkalarının eline geçmesi hâlinde ilgili kişiyi ve Kurulu en kısa sürede bilgilendirirsiniz.
• Md. 9 (yurt dışına aktarım): Aktarım için önce yeterlilik kararı aranır; yoksa uygun güvenceler gerekir; ikisi de yoksa yalnızca arızi istisnalar kalır. Bulut bir yapay zekâ servisi hasta belgesini yurt dışındaki sunucuda işliyorsa bu madde devreye girer.

Sağlık verisine özgü ayrıca Kişisel Sağlık Verileri Hakkında Yönetmelik (2019) vardır. Hangi hükümlerinin kurumunuzu ilgilendirdiğini sağlık hukuku danışmanınızla birlikte okuyun; bu sayfa yönetmeliğin maddelerini yorumlamaz.

Yerel kurulum verinin nerede işlendiğine, erişim sınırına ve kayıtlara ilişkin teknik güvenceleri doğrudan karşılar; işleme dayanağı, aydınlatma ve sır saklama gibi sorumluluklar ise kurumunuzda kalır.

Kurulum “kapalı sistem” zeminini kurar; KVKK ve sır saklama yükümlülükleri kurumunuzda sürer.

Yerel yapay zekâ altı belge işinde yetkili personele taslak ve ön hazırlık çıkarır; son söz her zaman yetkili hekimde ya da personeldedir. Sistem hiçbir senaryoda tanı koymaz, tedavi önermez ve hastaya yanıt yazmaz.

Bu işlerin hazırlıksız bir modelde nasıl sonuç verdiğini kendimiz ölçtük. Hiçbir özelleştirme yapılmamış gemma4:26b, tek ekran kartlı bir bilgisayarda ve tamamen kurgusal belgelerle 22 maddelik bir epikriz taslağını eksiksiz çıkardı; dosyaya konmuş 7 tuzağın hiçbirine basmadı. 40 hasta mesajını doğru kategoriye ayırdı ve 6 acil mesajın 6’sını işaretledi. Protokol arşivindeki 14 sorunun hepsini doğru ele aldı, eski revizyondan cevap vermedi ve arşivde olmayan bilgiye “bulunamadı” dedi. Zorlandığı yerler de oldu: ilaç-doz kontrolünde 6 çelişkinin 6’sını buldu ama yanlış alarm da verdi; maskelemede 42 kişisel verinin 41’ini gizledi, cümle içine yazılmış bir doğum tarihi açıkta kaldı. Ölçüm yöntemi ve ayrıntılar Gemma 4 ile sağlık kuruluşu testi yazısında.

Hangi işin sizde nasıl çalışacağına siz karar verirsiniz. Biz, seçtiğiniz işleri kendi belgelerinizle pilotta sınarız.

Hayır: Metot’un kurduğu sistem tanı koymaz, tedavi önermez ve acil triyajı yapmaz; kapsamı idari işler ve belge işleridir. Tanı ve tedavi kararı hekime aittir, sistemin çıktısı ise onaylanacak bir taslaktır.

Klinik karar desteği, görüntü yorumlama ve hasta triyajı gibi alanlar ayrı bir klinik ve hukuki değerlendirme ister. Bu sayfadaki kurulum bu alanlara girmez. Pilotta modele kasıtlı olarak tanı ve tedavi soruları sorar, kapsam dışı olduğunu söyleyip söylemediğini kayda geçiririz.

Hekimlerinizin kendi başlarına genel amaçlı sohbet araçlarına hasta bilgisi girmesini önlemek de kurumunuzun yazılı politikasına kalır. Yerel sistem, idari ve belge işleri için kayıt altında, kurumun onayladığı bir alternatif sunar.

Kurulum HBYS’nizin yerine geçmez; yanına, kurumunuzun sunucusuna kurulur ve hastane bilgi yönetim sistemini değiştirmeden çalışır. Belgeleri ya da kayıtları HBYS’den nasıl alacağımız, HBYS tedarikçinizin sunduğu yönteme göre teknik keşifte belirlenir.

Üç yol vardır:

• Belge klasörü ya da dışa aktarım: HBYS’nin ürettiği PDF’leri, raporları ve dışa aktarımları sistem kurumun sunucusundan okur. Tedarikçiye en az bağımlı yol budur.
• HBYS’nin sunduğu bağlantı yöntemi: Tedarikçiniz bir bağlantı yöntemi sunuyorsa ve izin veriyorsa kullanırız. İzin ve lisans koşulları sizinle tedarikçiniz arasındadır.
• Elle yükleme: Pilotta, bağlantı kurulmadan önce seçilmiş belgelerle başlayabiliriz.

Varsayılan olarak sistem HBYS’ye kayıt yazmaz; yetkili personel taslağı onaylar ve kaydı kendisi yapar. Bu sayfadaki hiçbir madde MHRS, e-Nabız ya da Bakanlık sistemleriyle entegrasyon sunduğumuz anlamına gelmez; böyle bir gereksiniminiz varsa teknik keşifte değerlendiririz.

Erişim hekim, birim ve hasta dosyası bazında tanımlanır ve arama sırasında da uygulanır; dosya listesini gizlemek yetmez. Yetkisi olmayan biri soru sorduğunda başka bir hastanın belgesinden bilgi gelmemelidir.

Sağlık kuruluşunda bu ayrım dört yerde önem kazanır:

• Roller: Hekim, hemşire, sekreterya, laboratuvar personeli, kalite birimi ve dış danışman için yetkileri ayrı tanımlarsınız. Sekreterya mesaj sınıflandırmayı kullanırken epikriz taslaklarını görmeyebilir.
• Birim ayrımı: Bir birimin ya da hastanın dosyasına yetkisi olmayan hesap, belgeyi ne arama sonucunda ne de modele giden bağlamda görür.
• Ek koruma isteyen kayıtlar: Kurum çalışanlarının kendi hasta dosyaları gibi kayıtları ayrı alana alabilirsiniz.
• Görev değişikliği ve ayrılma: Bir personel birimden ayrıldığında ya da hasta dosyası arşive kalktığında erişim kapanmalı; arama dizini ve yedekler de buna uymalıdır.

Pilotta yetkisi olmayan bir hesapla başka birimlerin dosyalarına dair sorular sorarak bu ayrımı sınarız. Kimin neye erişeceğini siz belirlersiniz.

Model, arama dizini, sohbet geçmişi, kayıtlar ve yedekleri aynı sınırın içinde tutacak biçimde tasarlarız; hasta dosyasını da aranabilir kopyasını da aynı hassasiyette sayarız. Sınırı şu başlıklarda çizeriz:

• Dış bağlantılar: Hata bildirimi, kullanım verisi, belge okuma servisi, güncelleme ve uzaktan destek bağlantılarını tek tek sayarız. Gerekmeyenleri kapatır, gerekli olanın hangi veriyi taşıdığını size yazılı veririz.
• Şifreleme: Disk ve yedek şifrelemesi ile ağ içi bağlantı şifrelemesini kurumunuzun bilgi güvenliği politikasına göre yapılandırırız.
• Kayıt ve saklama: Sohbet geçmişi ile kullanım kayıtlarının ne kadar tutulacağına siz karar verirsiniz. Dosya silindiğinde ya da arşive alındığında arama dizinindeki ve yedeklerdeki karşılığı da aynı kurala bağlanmalıdır; bunu kurulumda birlikte tanımlarız.
• Model ve güncellemeler: Model dosyalarını ve güncellemeleri kontrollü biçimde alırız. Sürüm değişikliğinin erişimlere ve veri akışına etkisini önce test eder, geri dönüş yolunu hazır tutarız.
• İnternetsiz çalışma: Belge okuma, arama ve kullanıcı doğrulamanın da çevrimdışı çalışması gerekir. Bunu baştan varsaymayız; teknik keşifte değerlendiririz.

Hasta verisiyle model eğitmiyoruz; varsayılan yaklaşımımız kaynaklı aramadır (RAG): sistem soruya uygun belge bölümlerini bulur ve yanıt için modele bağlam olarak verir, modelin ağırlıkları değişmez. Belgeleriniz modele öğretilmez.

Model seçimi için tıpta tek bir “en iyi” model yoktur; ölçüt sizin göreviniz ve belgelerinizdir. Çoğu kurulumda açık ağırlıklı bir modelle başlarız; lisans koşullarını ve ticari kullanım iznini sizinle birlikte kontrol ederiz. Türkçe tıbbi metinde, kısaltmalarda ve uzun yatış dosyalarında başarım modelden modele değişir. Bu yüzden modeli kendi belgelerinizle, beklediğiniz yanıt örnekleriyle sınayıp seçeriz. Uzun dosyalarda modelin bağlam penceresi de belirleyicidir.

Modelin ince ayarını ayrı bir çalışma olarak kapsamlandırırız. Hasta verisiyle yapılacaksa ayrıca hukuki değerlendirme gerekir; bu sayfadaki kurulumun parçası değildir.

Sağlayıcıya verinin nerede işlendiğini, kimlerin eriştiğini, neyin kayda geçtiğini ve sistemin klinik karara girip girmediğini sorun. Hangi firmayla çalışırsanız çalışın, görüşmenin gündemi şu on iki soru olmalı:

1. Verilerim hangi sunucuda ve hangi ülkede işleniyor, saklanıyor? Cevap kendi ortamınızsa dışarıdan erişim olup olmadığını da sorun.
2. Belgelerim, istemlerim ve çıktılarım model eğitiminde ya da ürün geliştirmede kullanılıyor mu? Cevabı yazılı isteyin.
3. Sistem dışarıya bağlanıyor mu? Hata bildirimi, kullanım verisi, belge okuma, ses çözümleme, güncelleme ve uzaktan destek bağlantılarının tek tek sayılmasını isteyin.
4. Alt işleyen ya da üçüncü taraf bir bileşen var mı? Varsa kim? Değişirse size haber verilecek mi?
5. HBYS’mizden veriyi nasıl alıyorsunuz? HBYS tedarikçimizin iznine ve lisans koşullarına ihtiyaç var mı?
6. Erişimi birim ve hasta bazında nasıl sınırlıyorsunuz? Yetkinin arama sırasında çalıştığını nasıl test ettiklerini sorun.
7. Hangi kayıtlar tutuluyor? Saklama süresini, silme imkânını ve kayıtlara kimin eriştiğini öğrenin.
8. Yanıtlar kaynak gösteriyor mu? Hekimin ya da personelin çıktıyı dosyayla karşılaştırabilmesi gerekir.
9. Uzaktan destek ve bakımda hasta verisine erişiyor musunuz? Erişimin nasıl yapıldığını ve kayıt altına alınıp alınmadığını sorun.
10. Tanı, tedavi önerisi ya da triyaj gibi klinik bir iş yapıyor musunuz? Yapıyorsa kapsamı ve sorumluluğu yazılı isteyin.
11. Veri ihlali olursa ne olacak? Bildirim ve sorumluluk düzeni yazılı olmalı.
12. Çıktının doğruluğu için ne taahhüt ediyorsunuz? Güvenilir bir sağlayıcı hata oranlarını ve sınırlarını açıkça söyler; “hatasız” ya da “tam uyumlu” diyen bir sağlayıcıya temkinli yaklaşın.

Bu liste hukuki bir kontrol listesi değil, teknik seçim için başlangıçtır. Sözleşme ve veri işleyen ilişkisi için hukuk danışmanınızla çalışmalısınız.

Yerel yapay zekâ hasta verisinin nerede işlendiğini kontrol etmenizi sağlar; yanlış çıktıyı, yetki hatasını, klinik kararı ya da hukuki yükümlülükleri kendiliğinden ortadan kaldırmaz.

Yerel çalışmanın kurumunuza uyup uymadığını varsayımlar değil, kendi belgelerinizle yapılan pilotun doğruluk, erişim ve performans sonuçları gösterir.

Donanım ve maliyeti kullanıcı sayınız, aynı anda kullanım yoğunluğu, belge ve tarama hacminiz, seçilen model boyutu ve beklediğiniz yanıt süresi belirler. Yeni donanım önermeden önce mevcut sunucunuza bakarız.

İhtiyaç kurumun ölçeğine göre belirgin biçimde değişir. Birkaç hekimin ve bir sekreterliğin kullandığı küçük bir klinikte tek sunucu ve küçük bir model yeterli olabilir. Birden çok birimi, yoğun evrak akışı ve taranmış arşivi olan orta ölçekli bir hastane, belge okuma ve arama için ayrıca kaynak ister. Birden fazla şubede erişim ayrımı, yedekleme ve bakım yükü de büyür.

Belirleyici teknik etkenler:

• Model boyutu ve ekran kartı belleği: Büyük model daha fazla bellek ister. Ekran kartının (GPU) belleği (VRAM) ve kullanılan sıkıştırma yöntemi bu hesabı etkiler.
• Dosya uzunluğu: Yüzlerce sayfalık yatış dosyalarında modelin bağlam penceresi ve belgenin nasıl bölündüğü önem kazanır.
• Eş zamanlı kullanıcı: Aynı anda soru soran kişi sayısı yanıt süresini değiştirir.
• Belge hazırlama: Taranmış belgeyi okumak ve arama dizinini kurmak işlemci, bellek ve depolama harcar.

Toplam maliyete kurulumun yanında enerji, lisans koşulları, yedekleme ve bakım da girer. Fiyatı varsayımla vermiyoruz; teklifi pilotta gördüğümüz iş yüküne ve birlikte belirlediğimiz kabul ölçütlerine göre hazırlarız.

Kurulum, kurumunuzun belge ve veri sınırlarını belirlemekle başlar, kendi belgelerinizle yapılan bir pilotla sınanır ve yazılı devirle biter.

Belge ve veri envanteri

Hangi belgelerin sisteme gireceğini, kimlerin erişeceğini ve hangi kayıtların dışarıda kalacağını sizinle birlikte netleştiririz. Özel nitelikli verinin işlendiği yerleri ve dış bağlantıları bu aşamada çıkarırız.

Mimari, model ve donanım seçimi

Modeli, belge arama bileşenlerini ve donanımı kurumunuzun iş yüküne göre seçeriz. HBYS’den belge alma yöntemini, lisansları ve güncelleme yöntemini de bu aşamada planlarız.

Başarı ölçütü ve ilk pilot

Pilota başlamadan başarı ölçütünü yazarız: bugünkü süre ve hata durumu, kabul edilecek doğruluk, kaçırılan ve yanlış işaretlenen kayıt sayısı, her çıktının kaynağa bağlanması. Pilotta bir çıktı başarısız olursa nedenini veri, kapsam ya da çözüm olarak ayırırız.

İlk pilot için hasta verisi içermeyen bir iş öneririz; örneğin protokol ve SOP arşivinde kaynaklı arama. Hasta verili işlere, veri sınırı ve yetkiler netleştikten sonra geçeriz. Gerçek hasta verisini pilota almak için gereken hukuki dayanak ve bilgilendirme kararı size aittir; gerekirse kurgusal ya da maskelenmiş örneklerle başlarız. Süreyi keşifte netleştiririz.

Kurulum ve erişim yetkileri

Ortamı kurar, kullanıcı rollerini ve birim ile hasta bazlı izinleri yapılandırırız. Dış bağlantıları, kayıtları ve yedeklemeyi kontrol ederiz.

Eğitim ve destek

Kullanım sınırlarını, çıktı denetimi adımını ve kayıt düzenini size aktarırız. Bakımı kimin yapacağı, güncelleme yöntemi ve destek kapsamı yazılı olarak belirlenir. Kurumunuzun yazılı yapay zekâ kullanım politikasını ve aydınlatma metnini hazırlamak sizin ve hukuk danışmanınızın işidir; sistemi bu politikaya göre yapılandırırız.

1. [1]6698 sayılı Kişisel Verilerin Korunması Kanunu (md. 3, 4, 6, 9, 10 ve 12; 7499 sayılı Kanunla değişik hâli), mevzuat.gov.trmevzuat.gov.tr↗
2. [2]Kişisel Verileri Koruma Kurumu: Yurt dışına aktarımkvkk.gov.tr↗