Yabancı Hasta Formunda Ülke Kodu Neden Bozulur?

Yabancı Hasta Formunda Ülke Kodu, form alanındaki küçük bir yazım ayrıntısından fazlasıdır. Numara web formundan CRM’e, CRM’den WhatsApp veya VOIP bağlayıcısına geçerken yeniden ayrıştırılabilir, farklı biçimde kaydedilebilir ya da hedef sistemin beklediği biçime uymayan bir değere dönüşebilir.

Sorunun hangi adımda çıktığını görmek için girişi, normalizasyonu, saklamayı ve aktarımı ayrı ayrı izleyin.

Hastanın yazdığı değeri tahminle değiştirmeyin. Amaç, numaranın geçtiği her dönüşümü görünür kılmak, kanonik değeri korumak ve elle yapılan düzeltmenin nedenini ölçmek. Bu yaklaşım yalnızca iletişim adresinin teknik yönetimini kapsar; otomasyon herhangi bir klinik değerlendirme veya tıbbi karar yerine geçmez.

Yabancı Hasta Formunda Ülke Kodu nerede bozulabilir?#

Telefon numarasını tek bir değer sayarsanız, farklı sistemlerin yaptığı dönüşümler aynı alanda üst üste binebilir. Denetlemesi daha kolay bir veri modeli şu dört biçimi birbirinden ayırır:

• Ham giriş: Kullanıcının forma yazdığı değer.
• Ülke bağlamı: Kullanıcının açıkça seçtiği ülke veya formun ayrıca topladığı çağrı kodu.
• Kanonik değer: Kuruluşun belirlediği, sistemler arası aktarımda kullanılan uluslararası gösterim.
• Görüntüleme değeri: Temsilcinin ekranda okuyacağı, gerekirse görsel ayraç içeren biçim.

RFC 3966’ya göre küresel telefon numarası + işaretiyle başlar, ülke kodunu ve ulusal numarayı içerir. Mümkün olduğunda küresel biçim yerel biçime tercih edilmelidir. Aynı belgeye göre telefon URI’leri karşılaştırılırken tire, nokta ve parantez gibi tanımlı görsel ayraçlar dikkate alınmaz. RFC boşluğu bu görsel ayraçlar arasında saymaz; boşlukla ilgili bir davranışı RFC’ye dayandırmayın. Buradan çıkarılabilecek güvenli tasarım sonucu, görüntü biçimi ile karşılaştırma veya aktarım için kullanılan değeri ayrı alanlarda yönetmektir. RFC 3966

Yapılandırma belgelerine E.164 sürümünü de açıkça yazın. 3 Eylül 2026 itibarıyla yürürlükte gösterilen ITU-T sürümü, 13 Şubat 2026’da onaylanan E.164 (02/26)’dır. Bu tarih bilgisi tek başına uygulamanın doğru çalıştığını kanıtlamaz; yalnızca ekiplerin hangi standart sürümünü referans aldığını kayda geçirmesine yardımcı olur. International Telecommunication Union

Bozulmayı incelerken ilk soru şu: Ham giriş mi hatalıydı, yoksa doğru giriş sonraki bir dönüşümde mi değişti? Ayrımı yapmadan bütün kayıtları “geçersiz numara” etiketiyle toplarsanız form sorunu ile aktarım sorunu birbirine karışır.

Form alanı neden tek başına doğrulama sağlamaz?#

HTML’de input type="tel", tarayıcıya alanın telefon numarası için olduğunu bildirir. Numaranın belirli bir uluslararası biçime uyup uymadığına ise bakmaz.

MDN’nin teknik referansına göre telefon biçimleri dünyada ülkeden ülkeye değiştiği için bu alan tek bir biçime göre otomatik doğrulanmaz ve istemci tarafı kontrolü sunucu tarafı doğrulamasının yerine geçmez. MDN burada normatif HTML standardı değil, uygulama davranışını açıklayan teknik referans olarak kullanılmalıdır. MDN

Formu tasarlarken ülke bilgisinin nereden geldiğini netleştirin. Tam uluslararası numarayı tek alanda isteyebilir ya da ülke seçimini numara alanından ayırabilirsiniz.

Her iki durumda da sunucu, gönderilen gerçek değeri ve seçilen ülkeyi birlikte değerlendirsin. Arayüzdeki bayrağa, yer tutucu metne ya da varsayılan ülkeye güvenmeyin; sunucu kendisine gelen değere baksın.

Önerilen adımlar şöyle:

1. Ham girdiyi değiştirmeden teslim al.
2. Ülke seçimi varsa ayrı bir alan olarak taşı.
3. Ayrıştırma sonucunu başarı, başarısızlık veya manuel inceleme durumlarından biriyle işaretle.
4. Kanonik değeri oluştur; ham değerin üzerine yazma.
5. CRM’e hem kanonik değeri hem de dönüşüm durumunu gönder.
6. Bağlayıcının ürettiği çıkışı maskeli biçimde denetle.

Formdan sonraki adımlar için Randevu Formu Sonrası Geri Arama Hangi Adımda Aksar? yazısına bakabilirsiniz.

CRM telefon numarası biçimi nasıl korunur?#

CRM şemasında tek bir phone alanı yerine her alanın görevini ayrı tanımlarsanız dönüşümü izlemek kolaylaşır. Örnek bir alan listesi phone_raw, phone_country_context, phone_canonical, phone_validation_status, phone_validation_reason ve phone_source alanlarından oluşabilir. Alan adları bir ürün zorunluluğu sayılmaz; kaydı denetleyebilmek için önerilen bir iç düzendir.

Görünüşü farklı iki değerin CRM’de eşleşip eşleşmediğini kendiniz sınayın. Microsoft Dynamics 365 Customer Insights’ın belgelenen telefon normalizasyonu, kendi eşleştirme sürecinde sembol ve boşlukları yok sayar. Ancak ülke kodu bulunan bir numaranın ülke kodu bulunmayan numarayla eşleşmeyeceğini de açıkça belirtir. Bulgu yalnız söz konusu Dynamics özelliğini açıklar. Başka CRM ürünlerinin aynı şekilde davrandığı sonucuna kaynak olmadan varılmamalıdır. Microsoft Learn

CRM ile öteki kurum sistemleri arasındaki alan eşleştirmesini de yazılı hâle getirin. Hangi alan ana kayıt, hangi sistem değeri güncelleyebiliyor, başarısız dönüşüm nereye yazılıyor; bunları önceden belirleyin.

Sistemlerin birbirine nasıl bağlanacağı için HBYS ve CRM Entegrasyon Rehberi yazısına bakın. Kayıtları klinikler için ücretsiz CRM gibi bir sistemde tutuyorsanız ülke kodu ve ulusal numara alanlarının nasıl saklandığını ayrıca kontrol edin.

Normalizasyon kitaplığı kullanıyorsanız sürüm ve meta veri değişikliklerini de teste katın. Google libphonenumber’ın 13 Ağustos 2026 tarihli v9.0.37 sürüm notları, Türkiye telefon meta verisinde ve +90 alternatif biçim verisinde güncelleme yapıldığını bildirir. Bu ürün belgesi, kullanılan libphonenumber sürümünün ve güncelleme sonrasındaki regresyon testlerinin kaydedilmesi gerektiğini gösterir; bütün doğrulama kütüphaneleri hakkında genel bir kanıt olarak kullanılmamalıdır. Google libphonenumber sürüm notları

WhatsApp ve VOIP aktarımında hedef sistemin sözleşmesini ayırın#

CRM’deki kanonik değer olduğu gibi kalsın.

WhatsApp’a ya da VOIP sistemine gidecek değeri, o sistemin belgelenen giriş kuralına göre ayrıca hazırlayın. Hazırlanan değeri CRM’deki ana telefon alanının üzerine yazmayın.

Twilio’nun Voice ve Messaging API hata belgesine göre To hedefi + işareti, ülke kodu ve abone numarasını içermeli; boşluk, tire ya da parantez taşımamalıdır. Kural, Twilio’nun kendi ürünü için belgelediği giriş biçimidir. Bir istek reddedildiğinde CRM kanonik değeri, bağlayıcının oluşturduğu çıktı ve Twilio yanıt kodu aynı işlem kimliği altında karşılaştırılabilir. Twilio

WhatsApp Yardım Merkezi ise uluslararası kişi numarasının +, ülke kodu ve tam numarayla girilmesini ister. Ulusal arama öneklerinde ülkeye özgü istisnalar olabileceğini de belirtir. Bu nedenle WhatsApp bağlayıcısında tek bir ülke için yazılmış önek silme kuralı bütün ülkelere uygulanmamalı, ürünün ülkeye özgü talimatları izlenmelidir. WhatsApp Yardım Merkezi

WhatsApp ve VOIP için ayrı birer durum alanı tutabilirsiniz: connector_input_created, request_sent, channel_rejected veya manual_review. Böylece “CRM’de kayıtlı”, “bağlayıcıya gönderildi” ve “hedef sistem kabul etti” olayları tek bir başarı etiketinde birleşmez. Çok dilli hasta iletişiminin günlük işleyişi için Sağlık Turizminde Hasta İletişimi Rehberi yazısına bakın.

Geçersiz numara ve manuel düzeltme oranı nasıl ölçülür?#

Ölçüme başlamadan önce “geçersiz” sözcüğünü alt durumlara ayırın. missing_country_context, parse_failed, channel_format_rejected ve manual_review_required gibi etiketler farklı sorunları gösterir. Her etiketin kesin anlamını veri sözlüğüne yazın ve rapor boyunca değiştirmeyin.

Aşağıdaki oranlar kuruluşun kendi olay kayıtlarından hesaplanabilir:

• Form ayrıştırma başarısızlık oranı: Ayrıştırılamayan gönderim sayısı / telefon alanı bulunan toplam form gönderimi.
• Aktarım biçimi hata oranı: Bağlayıcı çıkışı hedef sistemin tanımlı biçimine uymayan kayıt sayısı / o sisteme hazırlanan toplam kayıt.
• Biçim reddi oranı: Ürünün yanıt koduna göre telefon biçimi yüzünden reddedilen istek sayısı / o sisteme gönderilen toplam istek.
• Manuel düzeltme oranı: Telefon alanında insan müdahalesi gerektiren kayıt sayısı / telefon alanı bulunan toplam CRM kaydı.
• Aşama bazlı kayıp: Bir önceki aşamada bulunan ancak sonraki aşamaya geçemeyen kayıt sayısı / bir önceki aşamadaki toplam kayıt.

Oranın üstündeki ve altındaki sayıyı aynı dönemden, aynı hedef sistemden ve aynı kayıt kapsamından alın. Tekrarlanan denemelerin tek kayıt mı, ayrı istekler mi sayılacağına önceden karar verin.

Bu oranlar için elimizde bir sektör kıyas değeri yok. O yüzden burada kabul edilebilir bir sınır ya da performans garantisi önermiyoruz.

Önce kendi başlangıç değerinizi ölçün, sonraki değişiklikleri aynı tanım ve aynı veri kapsamıyla karşılaştırın.

Denetim kaydı oluştururken veri minimizasyonunu unutmayın#

Dönüşümü izlemek için gerçek telefon numarasını ve bağlayıcıya giden bütün veriyi genel uygulama kayıtlarına sınırsızca kopyalamanız gerekmez. KVKK’nin genel ilkeleri kişisel verilerin doğru ve gerektiğinde güncel tutulmasını; belirli, açık ve meşru amaçlarla, amaçla bağlantılı, sınırlı ve ölçülü işlenmesini öngörür. Verilerin gerekli süreyle sınırlı tutulması da değerlendirmeye alınmalıdır. Kişisel Verileri Koruma Kurumu

Bu ilkeleri operasyonel hâle getirmek için kuruluşun hukuk, güvenlik ve veri ekipleri birlikte karar vermelidir. Değerlendirilecek kontroller şunlar: tam değerin gerekmediği kayıtlarda maskeleme ya da tokenlaştırma, rol tabanlı erişim, korumalı aktarım, kayıt türüne göre saklama ve silme süresi, bağlayıcıya giden veride gereksiz alanların engellenmesi. Ham iş kaydını teknik hata kaydından ayırın ve değişiklik geçmişine erişimi sınırlayın. KVKK kaynağı bu teknik kontrollerin her birini tek tek reçete etmez; kontroller, amaçla sınırlılık ve ölçülülük ilkelerini uygulamak için kuruluş tarafından risk temelinde seçilmelidir. Telefon biçimini tek tipe getirmek, KVKK uyumunu tek başına kanıtlamaz.

Uygulama ve test kontrol listesi#

• Formun gönderdiği gerçek değer ile ekranda görülen değeri karşılaştırın.
• Ülke seçimini telefon numarasından ayrı izleyin.
• Ham, kanonik ve bağlayıcı çıkışı alanlarının birbirinin üzerine yazmasını engelleyin.
• Her dönüşüme kişisel veriyi içermeyen bir işlem kimliği verin.
• CRM alan eşleştirmelerini ve güncelleme yetkilerini belgeleyin.
• Kütüphane ve meta veri sürümünü test kaydına ekleyin.
• WhatsApp ve VOIP bağlayıcılarını kendi ürün sözleşmeleriyle ayrı ayrı sınayın.
• Manuel düzeltmede eski değere erişimi yetkilendirin; neden kodunu zorunlu tutun.
• Kayıtlarda maskeleme, erişim, aktarım, saklama ve silme kurallarını devreye almadan ayrıntılı istek kaydı açmayın.
• Oranları ülke, form sürümü, CRM dönüşümü ve gönderim aşamasında ayrı raporlayın.