İçeriğe atla
Tüm yazılar

Çağrı Otomasyonu

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?

14 dakika
Poliklinikler İçin Çok Bölümlü AI Santral
Paylaş:

Çok bölümlü bir poliklinikte telefon trafiği, küçük bir çağrı merkezi görünümünün altında karmaşık bir kaynak planlama problemi taşır. 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 niyetine çevirmeyi hedefler. Satın alma kararı verirken asıl soru, sistemin doğal konuşup konuşmadığı değil, bu dönüşümü ne kadar güvenli, izlenebilir ve entegrasyona uygun yaptığıdı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 doğrudan satmamalı; randevunun gerektirdiği hekim, oda, cihaz, süre, tesis ve hizmet kurallarının birlikte uygun olduğunu randevu sisteminden doğrulamalıdır. Konuşma modeli takvimin sahibi değil, kontrollü bir istemcisidir.

Ç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 farklı iş akışlarıdır. 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 nedenle ilk iş bir hizmet kataloğu kurmaktır. Her katalog kaydı şu alanları taşımalıdır:

  • 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 devredilecek kuyruk.

Hizmet kataloğu pazarlama sayfasından kopyalanmamalıdır. Operasyon, hekim planlama, bilgi işlem ve kalite ekipleri tarafından ortak sahiplenilmelidir. Bir hizmet geçici olarak durduğunda, hekim tesis değiştirdiğinde veya süre kuralı güncellendiğinde tek bir kaynak üzerinden değiştirilebilmelidir.

AI santral için altı katmanlı mimari

Satın alma görüşmesinde çözümü altı katmana ayırmak, parlak bir konuşma demosu ile işletilebilir sistem arasındaki farkı görünür kılar.

1. Telefon ve kanal 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 açısından sorulması gerekenler şunlardır: 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? Eş zamanlı çağrı kapasitesi nasıl fiyatlanıyor?

Telefon katmanı ile AI katmanını sözleşmede ayırmak çıkış stratejisini kolaylaştırır. Tedarikçi değiştiğinde kurumsal numara, temel yönlendirme ve çağrı kayıt politikası kilitli kalmamalıdır.

2. Niyet ve varlık çözümleme katmanı

Sistem arayanın cümlesinden randevu alma, değiştirme, iptal, bilgi alma, insanla görüşme veya geri arama gibi niyeti; ayrıca branş, hekim, tesis, tarih ve dil gibi varlıkları çıkarır. Ancak bir tahmin skoru iş kuralı değildir. Her niyet için minimum güven eşiği, tekrar soru sayısı ve devretme koşulu tanımlanmalıdır.

Ö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.

Politika motoru; izin verilen veri alanlarını, hata durumunu, insan devrini, maksimum konuşma turunu ve kayıt politikasını niyet bazında uygulamalıdır. 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 kavramsal ayrımı API sözleşmesine taşımak yararlıdır.

AI santral önce hizmet kodunu çözer, sonra ilgili tesis ve kaynak takvimlerini sorgular, uygun slotları sunar ve seçimi randevu sistemine yazar. Birden fazla kaynağın birlikte ayrılması gerekiyorsa işlem atomik olmalıdır. Aynı talebin ağ gecikmesi nedeniyle iki kez gönderilmesini önlemek için benzersiz işlem anahtarı kullanılmalıdır. Sistem yalnızca başarılı yazma yanıtı aldıktan sonra randevuyu kesinleşmiş olarak söylemelidir.

5. İnsan devri ve kuyruk yönetimi

İnsan devri bir hata değil, güvenli tasarım unsurudur. Modern görev yönlendirme sistemleri beceri, kuyruk, öncelik, kapasite ve zaman tabanlı eskalasyon kullanır. Poliklinikte aktarım paketi yalnız telefon bağlantısından ibaret olmamalıdır. Yetkili personele arayanın doğrulanmış kimlik seviyesi, seçilen tesis, anlaşılan niyet, denenen işlemler ve devir nedeni aktarılabilir. Gereksiz sağlık ayrıntısı taşınmamalıdır.

Kuyruk kuralları departman adı kadar beceriyi de dikkate almalıdır: yabancı dil, anlaşmalı kurum, çocuk hasta işlemi, teknik randevu sorunu veya hasta iletişim şikâyeti. Bekleme uzadığında geri arama seçeneği sunulmalı; geri arama sözü sahipli bir görev, hedef süre ve kapanış koduyla izlenmelidir.

6. Gözlemlenebilirlik ve yönetim

Her konuşma için niyet, güven skoru, kullanılan politika sürümü, entegrasyon sonucu, aktarım, geri arama ve nihai sonuç gibi operasyon metadatası üretilebilmelidir. Ham ses veya tam metin dökümü olmadan da birçok kalite metriği hesaplanabilir. Veri minimizasyonu gereği ayrıntılı içerik yalnız tanımlı amaç ve süreyle saklanmalıdır.

Yönetim ekranı modelin kaç konuşmayı tamamladığını değil, nerede hata yaptığını göstermelidir. Yanlış branş, yanlış tesis, uygun olmayan slot, başarısız doğrulama, eksik devir özeti ve sistem kesintisi ayrı hata sınıfları olmalıdır.

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 tercih ettiği iletişim kanalı da kaydedilmelidir. Randevu onayı SMS ile gönderilecekse mesaj içeriği ekranda göründüğünde gereksiz sağlık bilgisi ifşa etmemelidir. Değişiklik bağlantısı kimlik doğrulamalı ve süreli olmalıdır.

Entegrasyon şartnamesini sonuç odaklı yazın

HIS veya randevu sistemiyle entegre olabilir ifadesi ölçülemez. Bunun yerine her API işlemi için sözleşme yazın:

  • Hizmet ve branş kataloğunu okuma.
  • Hekim, tesis, oda ve cihaz uygunluğunu sorgulama.
  • Slot 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çi test ortamı sağlamalı; gerçek hasta verisi olmadan sentetik hekim, tesis ve takvimlerle uçtan uca senaryo çalıştırılabilmelidir. Üretim yetkileri en az ayrıcalıkla verilmeli ve düzenli gözden geçirilmelidir.

Pilot tasarımı: tek branş değil, kontrollü çeşitlilik

Sadece en kolay branşla yapılan pilot konuşma motorunu gösterir, çok bölümlü işletimi 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 akışları ilk pilot dışında bırakın.

Pilot senaryoları şu grupları içermelidir:

  1. Açık ve tek niyetli talepler.
  2. Benzer branş veya hekim adı.
  3. Aynı hizmetin iki tesiste sunulması.
  4. Tercih edilen saatin dolu olması.
  5. Hekim uygun fakat oda veya cihazın dolu olması.
  6. Randevu sistemi zaman aşımı.
  7. Arayanın insan istemesi.
  8. Kimlik doğrulamanın başarısız olması.
  9. Çocuk veya yakın adına işlem.
  10. Belirti anlatımı ve güvenli klinik devir.
  11. Türkçe dışında desteklenen dil.
  12. Gürültü, kesilme ve tekrar arama.

Her senaryonun beklenen hizmet kodu, izin verilen işlem, yasak ifade, devir kuyruğu ve başarı kriteri önceden yazılmalıdır. Model güncellemesinden sonra bu set regresyon testi olarak yeniden çalıştırılmalıdır.

Ölçülecek iş sonuçları

Cevaplama oranı tek başına yeterli değildir. Satın alma komitesi şu sonuçları izlemelidir: doğru ilk yönlendirme, otomasyonda tamamlanan idari işlem, insan devri sonrası çözüm, tekrar arama, yanlış randevu, mükerrer randevu, entegrasyon hatası, geri arama hedefi, randevu değişiklik süresi ve mahremiyet olayı. Sonuçlar branş, tesis, niyet, dil ve saat diliminde ayrıştırılmalıdır.

AI performansı için ayrıca belirsizlik yönetimi ölçülmelidir. 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ü iyileştirme kuyruğuna 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, entegrasyon, 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. Kurumun hizmet kataloğu ve konuşma metinleri sözleşme sonunda taşınabilir biçimde teslim edilebilmelidir.

Uygulama yönetişimi

Canlıya geçişten sonra sistemin bir ürün sahibi, klinik güvenlik sorumlusu, veri koruma sorumlusu, entegrasyon sahibi ve departman temsilcileri olmalıdır. Yeni niyet veya yanıt eklemek için onay akışı tanımlanmalı; kritik değişiklikler kayıt altına alınmalıdır. Aylık kurul yalnız hacim raporunu değil, hata örneklerini, insan devirlerini, şikâyetleri ve veri olaylarını incelemelidir.

Çok bölümlü AI santral yatırımı, bütün telefonları tek bir konuşma modeline bağlamak değildir. Kurum dilini yapılandırılmış hizmet kataloğuna, bu kataloğu gerçek kaynak takvimlerine, belirsizliği güvenli insan devrine ve bütün süreci ölçülebilir yönetişime bağlamaktır. 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

  1. Appointment - FHIR v5.0.0HL7 International
  2. Schedule - FHIR v5.0.0HL7 International
  3. SIP: Session Initiation Protocol (RFC 3261)Internet Engineering Task Force
  4. Ethics and Governance of Artificial Intelligence for HealthWorld Health Organization
  5. Artificial Intelligence Risk Management Framework (AI RMF 1.0)National Institute of Standards and Technology
  6. Özel Nitelikli Kişisel VerilerKişisel Verileri Koruma Kurumu

Sık sorulan sorular

AI 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.

FHIR kullanmayan randevu sistemiyle entegrasyon mümkün mü?

Evet. FHIR'in hizmet, takvim, slot ve randevu ayrımı kavramsal bir sözleşme olarak kullanılabilir; mevcut sistemin API'leri bu nesnelere eşlenebilir.

Ç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.

Pilot tek branşla yapılmalı mı?

Yalnız en kolay branş yetersizdir. Kontrollü pilotta karışabilecek iki branş, iki tesis ve farklı kaynak kuralları olan hizmetler bulunmalıdır.

İnsan devri başarısızlık sayılır mı?

Hayır. Belirsiz, hassas veya politika dışı talebi doğru bağlamla yetkili personele devretmek güvenli sistem davranışıdır ve ayrı bir kalite metriği olarak ölçülmelidir.

poliklinik AI santralçok branşlı randevuFHIR entegrasyonuakıllı çağrı yönetimisağlık otomasyonu
Daha eski yazı bulunamadı
En yeni yazıdasınız

Kurumunuza uygun kapsamı belirleyin

Mevcut akışınızı, veri sınırlarını ve entegrasyon koşullarını birlikte değerlendirin.

Kapsam görüşmesi