Yabancı Hasta Formunda Ülke Kodu Neden Bozulur?

Yabancı Hasta Formunda Ülke Kodu, yalnızca form alanındaki bir yazım ayrıntısı değildir. 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 kanalın beklediği sözleşmeye uymayan bir değere dönüşebilir. Sorunun hangi aşamada oluştuğu ise ancak giriş, normalizasyon, saklama ve aktarım adımları ayrı ayrı izlendiğinde belirlenebilir.

Amaç hastanın yazdığı değeri tahminlerle değiştirmek değil; dönüşüm zincirini görünür hâle getirmek, kanonik değeri korumak ve manuel müdahalenin nedenini ölçmektir. 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?

Bir telefon numarasının tek bir değerden ibaret olduğu varsayılırsa, farklı sistemlerin yaptığı dönüşümler aynı alanda üst üste binebilir. Daha denetlenebilir bir veri modeli şu dört temsili 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: Entegrasyonlarda kullanılacak, kuruluş tarafından belirlenmiş 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ı belge, telefon URI’leri karşılaştırılırken tire, nokta ve parantez gibi tanımlı görsel ayraçların dikkate alınmamasını öngörür. Bu kural boşluğu bir URI görsel ayracı olarak tanımlamaz; dolayısıyla boşluk davranışı RFC’ye atfedilmemelidir. 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

E.164 sürümü de yapılandırma belgelerinde açıkça belirtilmelidir. 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

Bozulma incelemesi şu soruyla başlamalıdır: Ham giriş mi hatalıydı, yoksa doğru giriş daha sonraki bir dönüşümde mi değişti? Bu ayrım yapılmadan bütün kayıtları “geçersiz numara” etiketi altında toplamak, form sorunu ile entegrasyon sorununu birbirine karıştırır.

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

HTML’de input type="tel" kullanılması, tarayıcıya alanın telefon numarası için olduğunu bildirir; ancak belirli bir uluslararası biçimi kendiliğinden doğrulamaz. MDN’nin teknik referansında, telefon biçimlerinin dünya genelinde değişmesi nedeniyle bu alanın otomatik olarak tek bir formata göre doğrulanmadığı ve istemci tarafı kontrolünün sunucu tarafı doğrulamasının yerine geçmediği belirtilir. MDN burada normatif HTML standardı değil, uygulama davranışını açıklayan teknik referans olarak kullanılmalıdır. MDN

Form tasarımında bu nedenle ülke bağlamının nasıl elde edildiği açık olmalıdır. Ekip, tam uluslararası numarayı tek alanda isteyebilir veya ülke seçimini numara alanından ayırabilir. Her iki durumda da sunucu, forma gönderilen gerçek değeri ve seçilen ülke bağlamını birlikte değerlendirmelidir. Arayüzde görülen bayrak, yer tutucu metin veya varsayılan ülke; sunucuya iletilen değerin yerine geçmemelidir.

Önerilen iş akışı şöyledir:

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. Kanal bağlayıcısının ürettiği çıkışı maskeli biçimde denetle.

Form sonrası operasyonun diğer adımları, Randevu Formu Sonrası Geri Arama Hangi Adımda Aksar? yazısındaki süreç yaklaşımıyla birlikte ele alınabilir.

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

CRM şemasında yalnızca phone adlı tek bir alan kullanmak yerine alanların görevini belirlemek, dönüşümün izlenmesini kolaylaştırır. Örnek bir sözleşme phone_raw, phone_country_context, phone_canonical, phone_validation_status, phone_validation_reason ve phone_source alanlarından oluşabilir. Bunlar bir ürün zorunluluğu değil, denetlenebilirlik için önerilen iç veri sözleşmesidir.

CRM tarafında görünüşleri farklı iki değerin otomatik olarak aynı kabul edileceği varsayılmamalıdır. Microsoft Dynamics 365 Customer Insights’ın belgelenen telefon normalizasyonu, kendi eşleştirme sürecinde sembol ve boşlukları yok sayar; fakat ülke kodu bulunan bir numaranın ülke kodu bulunmayan numarayla eşleşmeyeceğini açıkça belirtir. Bu bulgu yalnızca 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 diğer kurumsal sistemlerin alan eşleştirmesi ayrıca belgelenmelidir. Hangi alanın ana kayıt olduğu, hangi sistemin değeri güncelleyebildiği ve başarısız dönüşümün nereye yazıldığı belirlenmelidir. Daha geniş entegrasyon mimarisi için HBYS ve CRM Entegrasyon Rehberi incelenebilir.

Normalizasyon kitaplığı kullanılıyorsa sürüm ve meta veri değişiklikleri de test kapsamına alınmalıdır. Google libphonenumber’ın 13 Ağustos 2026 tarihli v9.0.37 sürüm notları, ürünün Türkiye telefon meta verisinde ve +90 alternatif biçim verisinde güncelleme yaptığı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 kanal sözleşmesini ayırın

Kanonik CRM değeri korunurken, her iletişim kanalına gönderilecek değer o kanalın belgelenen giriş sözleşmesine göre hazırlanmalıdır. Kanal için üretilen değer CRM’deki ana telefon alanının üzerine yazılmamalıdır.

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 veya parantez taşımamalıdır. Bu gereklilik Twilio’nun belgelenen ürün 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 önekleri konusunda ülkeye özgü istisnaların bulunabileceğ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

Her kanal için ayrı bir durum alanı tutulabilir: connector_input_created, request_sent, channel_rejected veya manual_review. Böylece “CRM’de kayıtlı”, “bağlayıcıya gönderildi” ve “kanal tarafından kabul edildi” olayları tek bir başarı etiketi altında birleştirilmez. Çok dilli iletişim akışının operasyonel kapsamı için Sağlık Turizminde Hasta İletişimi Rehberi kullanılabilir.

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

Ölçüm başlamadan önce “geçersiz” sözcüğü alt durumlara ayrılmalıdır. missing_country_context, parse_failed, channel_format_rejected ve manual_review_required gibi etiketler farklı sorunları temsil eder. Etiketlerin kesin anlamı veri sözlüğünde yazılmalı ve rapor boyunca değiştirilmemelidir.

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ışı tanımlanan kanal sözleşmesine uymayan kayıt sayısı / ilgili kanala hazırlanan toplam kayıt.
• Kanal biçim reddi oranı: Telefon biçimi nedeniyle reddedildiği ürün yanıt koduyla belirlenen istek sayısı / ilgili kanala 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.

Pay ve payda aynı dönem, kanal ve kayıt kapsamından seçilmelidir. Tekrarlanan denemelerin bir kayıt mı yoksa ayrı istekler mi sayılacağı önceden belirlenmelidir. Araştırma paketi bu oranlar için sektör kıyas değeri vermediğinden, kabul edilebilir eşik veya performans garantisi ileri sürülmemelidir. Ekip önce kendi başlangıç seviyesini ölçmeli; değişiklikleri aynı tanım ve veri kapsamıyla karşılaştırmalıdır.

Denetim kaydı oluştururken veri minimizasyonunu unutmayın

Dönüşümün izlenmesi, gerçek telefon numarasının ve bütün bağlayıcı yükünün sınırsız biçimde genel uygulama loglarına kopyalanmasını gerektirmez. 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. Tam değerin gerekli olmadığı loglarda maskeleme veya 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ı yüklerinde gereksiz alanların engellenmesi değerlendirilmelidir. Ham iş kaydı ile teknik teşhis logu birbirinden ayrılmalı, değişiklik geçmişine erişim sınırlandırılmalıdır. 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. Yalnızca telefon biçimini standartlaştırmak, tek başına KVKK uyumluluğu kanıtı değildir.

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 kanal çıkışı alanlarının üzerine birbirini 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.
• Log maskeleme, erişim, aktarım, saklama ve silme kurallarını devreye almadan ayrıntılı yük kaydı açmayın.
• Oranları ülke, form sürümü, CRM dönüşümü ve kanal aşamasında ayrı raporlayın.

Sık sorulan sorular

E.164 biçimi CRM’deki tek telefon alanı olmalı mı?

Kanonik uluslararası değerin ayrı tutulması yararlıdır; ancak ham girişin, ülke bağlamının ve doğrulama durumunun aynı alanın üzerine yazılması denetimi zorlaştırır. RFC 3966 küresel biçimin +, ülke kodu ve ulusal numarayı içerdiğini belirtir. RFC 3966

input type="tel" ülke kodunu otomatik doğrular mı?

Hayır. MDN teknik referansına göre bu alan dünya çapındaki telefon biçimlerini tek bir formata göre kendiliğinden doğrulamaz; istemci tarafı kontrolü sunucu doğrulamasının yerine geçmez. MDN

CRM’de ülke kodsuz ve ülke kodlu kayıtlar eşleşir mi?

Bu davranış ürüne göre doğrulanmalıdır. Microsoft Dynamics 365 Customer Insights’ın belgelenen normalizasyonunda ülke kodlu bir telefon, ülke kodu bulunmayan telefonla eşleşmez. Bu bilgi diğer CRM ürünlerine genellenemez. Microsoft Learn

WhatsApp için numaradan baştaki sıfır her zaman silinmeli mi?

WhatsApp Yardım Merkezi tam uluslararası biçimi isterken ülkeye özgü istisnaların bulunduğunu da belirtir. Bu nedenle önek dönüşümü WhatsApp’ın ilgili ülke talimatına göre yapılmalı, bütün ülkeler için tek bir silme kuralı uygulanmamalıdır. WhatsApp Yardım Merkezi

Manuel düzeltme oranı tek başına yeterli midir?

Hayır. Manuel düzeltmenin form ayrıştırması, CRM dönüşümü veya kanal reddi sonrasında yapılmış olması farklı sorunlara işaret eder. Oran, neden kodu ve aşama bilgisiyle birlikte raporlanmalı; payda aynı kapsam ve dönemden seçilmelidir.