Poliklinikler İçin Çok Bölümlü AI Santral
Çok branşlı poliklinikler için AI santral; doğru hizmet kataloğu, takvim entegrasyonu, insan devri ve ölçülebilir pilot kriterleriyle nasıl tasarlanır?

Çok bölümlü bir poliklinikte telefon trafiği dışarıdan küçük bir çağrı merkezine benzer, ama altında karmaşık bir kaynak planlama problemi yatar. Aynı kişi farklı günlerde farklı tesiste çalışan bir hekimi sorabilir; bir tetkik için hem cihaz hem teknisyen hem de oda uygunluğu gerekebilir; benzer isimli branşlar farklı randevu süreleri kullanabilir. Klasik santral bu karmaşıklığı tuşlama menülerine böler. AI santral ise konuşma dilindeki talebi hizmet, lokasyon, uzmanlık, zaman ve işlem türüne çevirmeyi hedefler. Satın alırken asıl soru şudur: sistem bu çeviriyi ne kadar güvenli, izlenebilir ve mevcut yazılımlara bağlanabilir biçimde yapıyor? Doğal konuşup konuşmadığı bu sorunun yanında geri planda kalır.
HL7 FHIR, Appointment kaynağını hasta, uygulayıcı, ilgili kişi veya cihaz gibi katılımcılar arasında planlanan bir sağlık etkinliği olarak tanımlar. Schedule ve Slot kaynakları ise rezervasyon yapılabilecek zaman aralıklarını, hizmet veya kaynak uygunluğundan ayrı ele alır. Bu ayrım poliklinik satın alması için değerlidir. AI santral takvimde boş görünen saati hemen hastaya vermesin; önce randevunun gerektirdiği hekim, oda, cihaz, süre, tesis ve hizmet kurallarının birlikte uygun olduğunu randevu sisteminden doğrulasın. Takvimin sahibi randevu sistemidir, konuşma modeli ona yalnız kontrollü biçimde erişir.
Çok bölümlü yapı neden farklıdır?#
Tek hekimli bir muayenehanede arayanın amacı ve doğru takvim çoğu zaman hızla belirlenebilir. Poliklinikte ise kardiyoloji muayenesi, kontrol randevusu, efor testi, çocuk kardiyolojisi ve rapor teslimi birbirinden ayrı işlerdir. Arayan bunların kurumsal adını bilmeyebilir. Üstelik tıbbi bir şikâyet anlatabilir; santral bu anlatıdan teşhis veya tedavi önerisi üretmemelidir.
Bu yüzden işe bir hizmet kataloğu kurarak başlayın. Her katalog kaydında şu alanlar bulunsun:
- Hastanın kullanabileceği adlar ve eş anlamlılar.
- Kurum içi hizmet kodu.
- İlgili branş ve alt hizmet.
- Sunulduğu tesis ve günler.
- Randevu süresi ve gerekli kaynaklar.
- Yeni hasta, kontrol veya işlem gibi randevu türü.
- Randevu öncesi yalnızca kurumca onaylanmış idari bilgilendirme.
- Otomasyonda tamamlanabilecek işlem ve insan onayı gereken adım.
- Kimlik doğrulama ve veri erişim seviyesi.
- Belirsizlik, güvenlik veya istisna halinde görüşmenin aktarılacağı ekip.
Kataloğu pazarlama sayfasından kopyalamayın. İşletme, hekim planlama, bilgi işlem ve kalite ekipleri onu birlikte sahiplensin. Bir hizmet geçici olarak durduğunda, hekim tesis değiştirdiğinde ya da süre kuralı güncellendiğinde değişiklik tek bir yerden yapılabilsin.
AI santral için altı katmanlı mimari#
Satın alma görüşmesinde çözümü altı katmana ayırın; parlak bir konuşma demosu ile gerçekten işletilebilecek bir sistem arasındaki fark ancak böyle görünür. Aşağıdaki katmanlar, çok bölümlü poliklinik için Çağrı AI Agent değerlendirmesinde de aynı sırayla sorulabilir.
1. Telefon ve hat katmanı#
SIP, ses oturumlarının kurulması, yönlendirilmesi ve sonlandırılması için yaygın bir protokol çerçevesidir. IETF RFC 3261 bu sinyalleşme modelini tanımlar. Kurum olarak şunları sorun: Mevcut operatör ve santral korunabiliyor mu? Numara taşıma zorunlu mu? Çağrı başarısız olduğunda yedek rota var mı? DTMF, arayan numara bilgisi, çağrı transferi ve geri arama hangi biçimde destekleniyor? Aynı anda karşılanabilecek çağrı sayısı nasıl fiyatlanıyor?
Telefon katmanı ile AI katmanını sözleşmede ayırırsanız tedarikçiden ayrılmak kolaylaşır. Tedarikçi değiştiğinde kurumsal numara, temel yönlendirme ve çağrı kayıt politikası eski firmada kalmasın.
2. Talep türü ve varlık çözümleme katmanı#
Sistem arayanın cümlesinden ne istediğini çıkarır: randevu alma, değiştirme, iptal, bilgi alma, insanla görüşme ya da geri arama. Branş, hekim, tesis, tarih ve dil gibi ayrıntıları da aynı cümleden ayıklar. Ancak modelin tahmin puanı bir iş kuralı yerine geçmez. Her talep türü için en düşük güven sınırını, kaç kez yeniden soru sorulacağını ve hangi durumda devredileceğini tanımlayın.
Örneğin arayan sadece dahiliyeye gelmek istiyorum diyorsa sistem muayene türünü açıklığa kavuşturabilir. Buna karşılık belirti anlatımından hangi branşın tıbben uygun olduğuna karar vermemelidir. Kurum tarafından önceden onaylanmış idari yönlendirme metinleri kullanılabilir; klinik değerlendirme gerektiren konu canlı sağlık profesyoneline veya kurumun belirlediği güvenli kanala aktarılmalıdır.
3. Politika ve güvenlik katmanı#
Bu katman AI'nın neleri yapabileceğini sınırlar. Çalışma saati ve adres gibi herkese açık bilgi kimlik doğrulama gerektirmez. Mevcut randevuyu okuma, değiştirme veya iptal etme ise kişiye bağlı işlem olduğundan doğrulama gerektirir. Sonuç, tanı, reçete veya kişisel sağlık kaydı gibi içerikler santralin genel bilgi akışından ayrılmalıdır.
İzin verilen veri alanları, hata durumu, insan devri, en fazla konuşma turu ve kayıt politikası her talep türü için ayrı ayrı uygulansın. WHO'nun sağlıkta AI için özerklik, güvenlik, şeffaflık ve hesap verebilirlik ilkeleri ile NIST AI RMF'in yönetişim ve ölçüm yaklaşımı bu katmanın değerlendirilmesine yardımcı olur.
4. Randevu ve kaynak orkestrasyonu#
HL7 FHIR Schedule kaynağı bir hizmet veya kaynak için uygun zaman pencerelerini, Slot kaynağı bu pencerelerdeki boş/dolu durumunu, Appointment ise planlanan etkinliği temsil eder. Poliklinik yazılımınız FHIR kullanmasa bile bu ayrımı API sözleşmesine taşımanız işinizi kolaylaştırır.
AI santral önce hizmet kodunu çözer, sonra ilgili tesis ve kaynak takvimlerini sorgular, uygun saatleri sunar ve seçimi randevu sistemine yazar. Birden fazla kaynak birlikte ayrılacaksa işlem bütün olarak ya tamamlansın ya da hiç yapılmasın. Ağ gecikmesi yüzünden aynı talebin iki kez gitmemesi için benzersiz işlem anahtarı kullanın. Sistem randevunun kesinleştiğini ancak başarılı yazma yanıtı geldikten sonra söylesin.
5. İnsan devri ve sıra yönetimi#
İnsan devri güvenli tasarımın bir parçasıdır, hata sayılmaz. Günümüzdeki görev yönlendirme sistemleri işi beceriye, sıraya, önceliğe ve personelin müsaitliğine göre dağıtır; bekleme uzayınca işi zamana bağlı olarak bir üst seviyeye taşır. Poliklinikte aktarımı, çağrıyı başka bir telefona bağlamakla bitirmeyin. Yetkili personele arayanın doğrulanmış kimlik seviyesi, seçilen tesis, anlaşılan talep, denenen işlemler ve devir nedeni aktarılabilir. Gereksiz sağlık ayrıntısını aktarmayın.
Sıra kuralları bölüm adının yanında beceriye de baksın: yabancı dil, anlaşmalı kurum, çocuk hasta işlemi, teknik randevu sorunu veya hasta iletişim şikâyeti. Bekleme uzadığında arayana geri arama seçeneği sunun. Verilen geri arama sözü de sahibi, hedef süresi ve kapanış kodu olan bir görev olarak izlensin.
6. Gözlemlenebilirlik ve yönetim#
Her konuşma için talep türü, güven puanı, kullanılan kural sürümü, sistem bağlantısının sonucu, aktarım, geri arama ve nihai sonuç gibi işletme verileri kaydedilebilsin. Ham ses veya tam metin dökümü olmadan da birçok kalite ölçüsü hesaplanabilir. Veri minimizasyonu gereği ayrıntılı içerik yalnız tanımlı amaç ve süreyle saklanmalıdır.
Yönetim ekranında modelin kaç konuşmayı tamamladığından çok nerede hata yaptığı görünsün. Yanlış branş, yanlış tesis, uygun olmayan saat, başarısız doğrulama, eksik devir özeti ve sistem kesintisi ayrı hata türleri olarak sayılsın.
Kimlik, mahremiyet ve yakın adına işlem#
Poliklinik çağrılarında kişi kendisi, çocuğu, ebeveyni veya başka bir yakını adına arayabilir. Arayan numarayı hasta kimliği kabul etmek güvenli değildir. Her işlem türü için hangi kimlik ve temsil bilgisinin gerektiği hukuk ve operasyon ekiplerince belirlenmelidir. Sistem yakın adına randevu talebini destekleyebilir, fakat temsil yetkisini varsayarak mevcut sağlık bilgisi açıklamamalıdır.
KVKK sağlık verilerini özel nitelikli kişisel veri olarak sınıflandırır. Bu nedenle hizmet seçimi için gerekli olmayan belirti ayrıntılarını kayda zorlamak, serbest metni sınırsız saklamak veya görüşmeleri varsayılan olarak model eğitimine aktarmak satın alma açısından kırmızı bayraktır. Teklifte veri işleme amacı, hukuki dayanak, saklama süresi, alt işleyenler, yurt dışı aktarım değerlendirmesi, rol bazlı erişim ve silme kanıtı açıkça yer almalıdır.
Hassas konuşmalarda kişinin arama ya da SMS gibi hangi yoldan ulaşılmak istediğini de kaydedin. Randevu onayı SMS ile gidecekse ekranda beliren mesaj gereksiz sağlık bilgisi göstermesin. Değişiklik bağlantısı kimlik doğrulaması istesin ve belli bir süre sonra geçersiz olsun.
Bağlantı şartnamesini sonuç odaklı yazın#
"HIS veya randevu sistemiyle entegre olabilir" cümlesi ölçülemez. Onun yerine her API işlemi için ayrı sözleşme yazın:
- Hizmet ve branş kataloğunu okuma.
- Hekim, tesis, oda ve cihaz uygunluğunu sorgulama.
- Randevu saatini geçici ayırma ve ayırma süresi.
- Randevu oluşturma, yeniden planlama ve iptal.
- İşlem kimliği ve tekrar güvenliği.
- Yetki kapsamı ve servis hesabı.
- Hata kodları, zaman aşımı ve tekrar deneme.
- Kesinti sırasında geri arama görevi oluşturma.
- Değişiklik günlüğü ve denetim izi.
Tedarikçiden, gerçek hasta verisi kullanmadan uydurma hekim, tesis ve takvimlerle senaryoları baştan sona deneyebileceğiniz bir test ortamı isteyin. Canlı ortam yetkilerini en az ayrıcalık ilkesiyle verin ve düzenli olarak gözden geçirin.
Deneme tasarımı: tek branş değil, kontrollü çeşitlilik#
Yalnız en kolay branşla yapılan deneme modelin konuşmasını gösterir, çok bölümlü işleyişi göstermez. Bunun yerine birbiriyle karışabilecek iki branş, iki tesis, farklı süre kullanan üç hizmet ve hem tek kaynaklı hem çok kaynaklı bir randevu türü seçin. Yüksek klinik risk taşıyan işleri ilk denemenin dışında bırakın.
Deneme senaryoları şu grupları kapsasın:
- Açık ve tek amaçlı talepler.
- Benzer branş veya hekim adı.
- Aynı hizmetin iki tesiste sunulması.
- Tercih edilen saatin dolu olması.
- Hekim uygun fakat oda veya cihazın dolu olması.
- Randevu sistemi zaman aşımı.
- Arayanın insan istemesi.
- Kimlik doğrulamanın başarısız olması.
- Çocuk veya yakın adına işlem.
- Belirti anlatımı ve güvenli klinik devir.
- Türkçe dışında desteklenen dil.
- Gürültü, kesilme ve tekrar arama.
Her senaryonun beklenen hizmet kodunu, izin verilen işlemi, yasak ifadeyi, devredileceği ekibi ve başarı kriterini önceden yazın. Model her güncellendiğinde bu seti regresyon testi olarak yeniden çalıştırın.
Ölçülecek iş sonuçları#
Cevaplama oranı resmin yalnız bir parçasını gösterir. Satın alma komitesi şu sonuçları izlesin: doğru ilk yönlendirme, otomasyonda tamamlanan idari işlem, insan devri sonrası çözüm, tekrar arama, yanlış randevu, mükerrer randevu, sistem bağlantısı hatası, geri arama hedefi, randevu değişiklik süresi ve mahremiyet olayı. Sonuçları branşa, tesise, talep türüne, dile ve saat dilimine göre ayrı ayrı görün.
AI'nın belirsiz durumları nasıl yönettiğini de ayrıca ölçün. Düşük güvenli taleplerin ne kadarı güvenli biçimde insana devredildi? Sistem bilmediği bilgiyi uydurdu mu? Politika dışı klinik soruda durdu mu? Personel kaç kez sınıflandırmayı düzeltti? Bu düzeltmeler kontrollü bir iyileştirme listesine giriyor mu?
Teklif karşılaştırma tablosu#
Tedarikçileri aynı başlıklarda puanlayın: telefon uyumluluğu, hizmet kataloğu yönetimi, Türkçe performans değerlendirme yöntemi, kural ve model ayrımı, FHIR veya mevcut API uyumu, çok kaynaklı takvim desteği, insan devri, rol bazlı erişim, veri saklama seçenekleri, denetim kaydı, kesinti planı, test ortamı, rapor dışa aktarımı ve çıkış desteği.
Fiyatı da aynı hacim senaryosunda karşılaştırın. Lisans, dakika, eş zamanlı oturum, konuşma çözümleme, sistem bağlantısı, mesajlaşma, saklama, destek ve değişiklik taleplerini tek toplam sahip olma maliyetinde birleştirin. Otomasyon oranı arttıkça lisansın hangi bileşeninin büyüdüğünü görün. Sözleşme bittiğinde kurumun hizmet kataloğu ve konuşma metinleri başka sisteme taşınabilecek biçimde teslim edilsin.
Uygulama yönetimi#
Canlıya geçtikten sonra sistemin bir ürün sahibi, klinik güvenlik sorumlusu, veri koruma sorumlusu, bağlantılardan sorumlu bir kişi ve bölüm temsilcileri olsun. Yeni talep türü ya da yanıt eklemek için bir onay adımı tanımlayın, kritik değişiklikleri de kayda geçirin. Aylık toplantıda hacim raporunun yanında hata örnekleri, insan devirleri, şikâyetler ve veri olayları da incelensin.
Çok bölümlü AI santralde amaç bütün telefonları bir konuşma modeline bağlayıp bırakmak olamaz. Asıl iş bir zincir kurmaktır: kurum dilini yapılandırılmış hizmet kataloğuna, bu kataloğu gerçek kaynak takvimlerine, belirsizliği güvenli insan devrine, bütün süreci de ölçülebilir bir yönetime bağlamak. Bu bağlar teklif ve kabul testinde görünmüyorsa doğal konuşma kalitesi tek başına satın alma gerekçesi oluşturmaz.
İlgili AgentFix rehberleri#
Kaynaklar
Bu yazıda yararlanılan kaynaklar:
- Appointment - FHIR v5.0.0 (yeni sekmede açılır)HL7 International
- Schedule - FHIR v5.0.0 (yeni sekmede açılır)HL7 International
- SIP: Session Initiation Protocol (RFC 3261) (yeni sekmede açılır)Internet Engineering Task Force
- Ethics and Governance of Artificial Intelligence for Health (yeni sekmede açılır)World Health Organization
- Artificial Intelligence Risk Management Framework (AI RMF 1.0) (yeni sekmede açılır)National Institute of Standards and Technology
- Özel Nitelikli Kişisel Veriler (yeni sekmede açılır)Kişisel Verileri Koruma Kurumu
Sık Sorulan Sorular
Bu yazıyla ilgili sık sorulan sorular ve kısa yanıtları.
01AI santral hastanın anlattığı belirtiye göre branş seçmeli mi?
Klinik değerlendirme gerektiren belirti anlatımından teşhis veya tedavi yönlendirmesi üretmemelidir. Kurumun onaylı güvenli metniyle canlı yetkiliye veya tanımlı kanala devretmelidir.
02FHIR kullanmayan randevu sistemiyle entegrasyon mümkün mü?
Evet. FHIR'in hizmet, takvim, slot ve randevu ayrımını kavramsal bir sözleşme olarak kullanabilirsiniz; mevcut sistemin API'leri bu nesnelere eşlenebilir.
03Çok kaynaklı randevu ne demektir?
Hekimle birlikte oda, cihaz veya başka personel gibi birden fazla kaynağın aynı zaman aralığında uygun ve birlikte ayrılmış olması gereken randevudur.
04Pilot tek branşla yapılmalı mı?
Yalnız en kolay branşla yapılan deneme yetmez. Kontrollü denemede birbiriyle karışabilecek iki branş, iki tesis ve kaynak kuralları farklı hizmetler bulunsun.
05İnsan devri başarısızlık sayılır mı?
Hayır. Belirsiz, hassas ya da kural dışı bir talebi gereken bilgilerle yetkili personele aktarmak güvenli sistemin işidir. Bunu ayrı bir kalite ölçüsü olarak izleyin.


