Randevu Formu Sonrası Geri Arama Hangi Adımda Aksar?

Randevu Formu Sonrası Geri Arama sürecinde yalnızca “form geldi” ve “randevu oluştu” sayılarına bakmak, aksamanın yerini göstermez. Talep web sitesinde sorunsuz alınmış olabilir. Ama CRM görevi geç açılabilir, görevi kimse üstlenmeyebilir, arama listeye düşmeyebilir, hasta arandığı hâlde anlamlı temas kurulamayabilir ya da randevu geldiği formla eşleşmeyebilir.

Bu yüzden formdan aramaya geçen süreyi tek bir sayaçla izlemeyin; her adımı ayrı bir olay olarak kaydedin. Amaç yalnız ekibi hızlandırmak olmasın. Teknik gecikme, ekipte geçen bekleme, görüşmenin sonucu ve randevu kaydı birbirinden ayrı görünsün.

Randevu Formu Sonrası Geri Arama neden tek metrikle ölçülmemeli?#

Sonunda kaç randevu oluştuğu, sürecin nerede durduğunu söylemez. Büyük bir akademik sağlık sisteminde 103.737 uzmanlık randevusu planlama girişimi incelendi. Bunların %34,8’i kayıtlı ve tamamlanmış bir randevuyla sonuçlandı; %38,9’unda ise randevu tarihi bulunmadı. Hastaların yaklaşık %6’sına randevu vermek için ulaşılamadı, %12’si planlamayı reddetti. Bazı randevular da ilk sevk kaydına bağlanmadan açıldı. Çalışma uzmanlık sevklerinin planlanmasını inceledi; reklam formu ya da sağlık turizmi talebi kapsamında yoktu. Bu yüzden oranlar kliniğin geri arama hedefi olamaz. Bulguların bu makale açısından değeri, “ulaşılamadı”, “istemedi” ve “kayıt ilişkilendirilemedi” sonuçlarının aynı hata altında toplanmaması gerektiğini göstermesidir. Araştırmayı inceleyin.

“Formdan randevuya dönüşüm düştü” demek, kimin ne yapacağını söylemez. Düşüşün nedeni formun CRM’e ulaşmaması da olabilir, uygun randevu bulunamaması da. İlk durumda bağlantıdan sorumlu bilgi teknolojileri ekibi, ikinci durumda boş saatleri ve randevuları yöneten ekip devreye girsin.

Talep zincirindeki olayları ayrı kaydedin#

Her talepte aynı olay sözlüğünü, yani aynı olay adlarını kullanın; farklı sistemlerin kayıtlarını karşılaştırmak kolaylaşır. En az şu olayları kaydedin:

OpenTelemetry’de span, tek bir işlemi ya da iş birimini temsil eder. Başlangıç ve bitiş zamanının yanında olay, öznitelik, bağlantı ve durum bilgisi de taşıyabilir. Form kabulü, CRM görevi ve aramanın sıraya alınması gibi adımları ayrı işlem birimleri olarak kaydetmek bu veri modeline uyar. Bu, OpenTelemetry kullanan her kliniğin otomatik olarak doğru randevu analitiğine sahip olduğu anlamına gelmez; olay sözlüğü ve iş kuralları ayrıca tanımlanmalıdır. OpenTelemetry trace modeline bakın.

Form, CRM, arama sistemi ve randevu yazılımındaki kayıtları aynı talebe bağlamak için korelasyon kimliği, yani bütün sistemlerde aynı kalan bir talep numarası kullanılabilir. W3C Trace Context, farklı yazılım bileşenlerinden geçen işlemlerin ortak bir trace kimliğiyle nasıl bağlanacağını tanımlar. Standart ayrıca traceparent ve tracestate alanlarında kişiyi tanımlayan veya hassas bilgi bulunmamasını öngörür. Bu nedenle hasta adı, telefon numarası, tanı veya tedavi talebi korelasyon kimliğine yazılmamalıdır. W3C standardını inceleyin.

Dört ayrı süre ölçüsü oluşturun#

Toplam süreyi parçalara ayırınca darboğazın kimde olduğu görünür:

1. CRM görev oluşturma süresi: crm_görevi_oluşturuldu − form_alındı
2. Görev sahiplenme süresi: görev_sahiplenildi − crm_görevi_oluşturuldu
3. İlk geri arama süresi: ilk_arama_başladı − form_alındı
4. Temastan randevuya geçen süre: randevu_booked − anlamlı_temas_kuruldu

İlk ölçü sistemler arası aktarımdaki gecikmeyi, ikincisi görevlerin sırada ne kadar beklediğini, üçüncüsü hastanın toplam bekleyişini, dördüncüsü de görüşmeden sonraki planlama adımlarını gösterir. Her sürede ortalamanın yanına medyanı ve yüksek gecikme dilimini de koyun. Az sayıdaki uzun bekleme böylece gözden kaçmaz.

Süreleri ölçmeden önce sistem saatlerini kontrol edin. NIST’in bilgisayar güvenliği günlüklerinin yönetimine dair genel rehberi, cihazların saatleri birbirini tutmadığında günlüklerin olay sırasını yanlış gösterebileceğini belirtir. Bu teknik uyarı sağlık turizmi performansına özgü değildir; ancak form, CRM ve telefon sistemleri eşzamanlı değilse hesaplanan sürelerin hatalı, hatta negatif çıkabileceğini açıklar. NIST rehberini inceleyin.

Görev oluştu, fakat gerçekten işlendi mi?#

“CRM görevi oluşturuldu” kaydı, ekibin görevi kabul ettiğini ya da bitirdiğini kanıtlamaz. HL7 FHIR görev durumları requested, received, accepted, rejected, ready, in-progress, on-hold, failed ve completed gibi aşamaları birbirinden ayırır. Bu kodlar her CRM’in zorunlu özelliği değildir; görev yaşam döngüsünü tasarlarken kullanılabilecek standart bir referans sözlüğüdür. FHIR görev durumlarına bakın.

Klinik kendi sistemindeki durumları en azından “oluşturuldu”, “sahiplenildi”, “işleniyor”, “beklemede”, “başarısız” ve “tamamlandı” biçiminde eşleyebilir. Böylece otomatik geri arama hataları, personelin iş listesindeki beklemeden ayrılır. Teknik hata kodu da mümkünse hatanın hangi aşamada çıktığını göstersin. CRM yazma hatası, arama sırasına aktarma hatası ve arama başlatma hatası ayrı başlıklarda dursun.

Verinin sistemler arasında nasıl taşındığını ayrıca gözden geçirmek isteyen ekipler, bağlantının sınırlarını HBYS ve CRM Entegrasyon Rehberi ile değerlendirebilir. Talep, durum ve geri arama sonucu tek kayıtta izlenecekse hasta takip sistemi bu alanları ayrı ayrı tutsun.

“Randevu açıldı” ile booked randevuyu ayırın#

Randevu yazılımında kayıt olması, randevunun kesinleştiğini göstermeyebilir. HL7 FHIR randevu durumları proposed, pending, booked, cancelled, waitlist ve entered-in-error gibi farklı durumlar tanımlar. “Randevu booked oranı” hesaplanırken yalnız kesinleşmiş kayıtları sayın; önerilen, bekleyen, bekleme listesindeki ve hatalı kayıtları ayrı tutun. Buradaki FHIR sözlüğü de kliniklerin kullandığı her yazılımın yetenek iddiası değil, durum eşlemesi için referanstır. FHIR randevu durumlarını inceleyin.

İzlenecek temel geçiş oranları şunlar:

• Form → CRM görevi
• CRM görevi → sahiplenilen görev
• Sahiplenilen görev → ilk arama
• İlk arama → anlamlı temas
• Anlamlı temas → booked randevu
• Form → booked randevu

Her oranın neye bölündüğünü açıkça yazın. Booked randevu sayısını bütün formlara bölerseniz genel dönüşümü görürsünüz. Yalnızca anlamlı temas kurulan taleplere bölerseniz temastan sonraki planlamanın sonucunu görürsünüz. İki oran farklı sorulara cevap verir.

Çağrı sonucunu ve dil grubunu birlikte inceleyin#

“Arandı” demek yetmez. İlk aramanın sonucu yanıt yok, yanlış numara, iletişim kuruldu, daha sonra aranmak istiyor, hizmeti istemiyor, uygun saat yok ya da booked gibi ayrı başlıklara bağlanabilir. “Anlamlı temas” tanımı da ekipten ekibe değişmesin. Şöyle bir tanım işe yarar: karşılıklı konuşuldu ve sonraki adım kaydedildi. Yalnızca çalan telefon bu tanıma girmez.

Çok dilli hasta geri arama işinde dili ayrı bir rapor başlığı yapın. Elektronik sağlık kaydı (EHR) üzerinden gönderilen otomatik erken randevu tekliflerini inceleyen bir çalışmada 60.660 teklifin %11’i kabul edildi, %8,9’u tamamlanmış ziyarete dönüştü. Çince konuşanlarda ve diğer dil gruplarında kabul olasılığı İngilizce konuşanlardan düşüktü. Araştırma otomatik telefon geri aramasını ya da Türkiye’deki sağlık turizmini incelemedi. Bu yüzden oranlar hedef olarak taşınamaz; yalnızca otomatik randevu akışlarının dil segmentinde ayrı ölçülmesi gerektiğine kanıt sağlar. Çalışmanın kapsamını inceleyin.

Raporlarda ülke ve dilin yanında vardiya, saat dilimi, reklam kaynağı, hizmet türü ve uygun saat bulunup bulunmadığına göre de filtre kullanılabilir. Aramaları karşılama oranına hedef koyacak aracı kuruluşlar Sağlık Turizmi Aracı Kuruluş Çağrı Merkezi SLA Rehberi yazısındaki çerçeveye bakabilir. Mesai dışında biriken talepler için Hafta Sonu Sağlık Turizmi Leadleri Nasıl Sıralanır? yazısı yol gösterir.

KVKK açısından ölçüm veri setini sınırlayın#

Randevu olaylarını sıradan iletişim verisi saymayın. KVKK’nın özel nitelikli kişisel veriler rehberi, kişinin randevu aldığı hastane, klinik veya birimin bazı durumlarda sağlık durumuna ilişkin çıkarım sağlayabileceğini; psikiyatri polikliniği randevusunu buna örnek olarak verir. Dolayısıyla hizmet türü, klinik adı ve formdaki serbest metin alanları ölçüm tasarımında ayrıca değerlendirilmelidir. KVKK rehberini inceleyin.

Takip ekranında kimlik bilgisini doğrudan göstermeyin. Rastgele talep kimliği, olay zamanı, başvuru yolu, dil, görev durumu, çağrı sonucu ve randevu durumu gibi ölçüm için gereken alanlarla çalışmak daha kontrollü bir yapı kurar. Erişim yetkileri ile saklama yaklaşımı kurumun veri işleme süreçlerine göre belirlenmelidir. Bu makale KVKK uyumluluğu garantisi veya hukuki danışmanlık sunmaz.

Uygulanabilir kontrol listesi#

• Her olayın sahibini ve kesin tanımını yazın.
• Tekrarlanan formları ayrı işaretleyin; sessizce silmeyin.
• Sistem saatlerini ve zaman dilimlerini doğrulayın.
• Ortak korelasyon kimliğinde kişisel veya hassas veri tutmayın.
• Teknik hatayı, yanıtsız aramayı, hastanın tercihini ve boş saat bulunmamasını ayrı kaydedin.
• Görev oluşturma ile görev sahiplenmeyi aynı kabul etmeyin.
• Yalnızca kesinleşmiş randevuları booked olarak sayın.
• Sonuçları dile, başvuru yoluna, vardiyaya ve hizmet türüne göre ayrı ayrı raporlayın.
• Her ölçüde neyin neye bölündüğünü ve hangi kayıtların dışarıda kaldığını yazın.

Bu ölçüm düzeni klinik karar vermez ve sağlık profesyonelinin değerlendirmesinin yerini alamaz. Talebin formdan kesinleşmiş randevuya giderken hangi teknik adımda ya da hangi ekip adımında durduğunu gösterir.