HBYS ve CRM Entegrasyon Rehberi: Veri, Güvenlik ve Test

Entegrasyonun hedefi güvenilir işlem üretmektir#

Sesli yapay zekâyı, HBYS'yi ve CRM'i birbirine bağlamak ilk bakışta birkaç API çağrısı gibi görünür. İş bundan geniştir. Aynı kişiyi doğru kayıtla eşleştirmek, randevu durumunu sistemler arasında tutarlı tutmak, çalışanlara yalnız gereken veriyi göstermek, başarısız işlemleri kaybetmemek ve her değişikliği denetlenebilir kılmak gerekir.

Arayana "randevunuz oluşturuldu" denirken HBYS'de kayıt yoksa, bağlantı çalışıyor görünse bile iş başarısızdır. Aynı talep iki kez işlenirse ya da CRM'e yanlış hastanın kaydı taşınırsa zarar verimle kalmaz. Hastanın güveni ve verinin korunması da riske girer.

T.C. Sağlık Bakanlığı Sağlık Bilgi Sistemleri Genel Müdürlüğü, HBYS.API ve YBBYS.API dokümanlarını entegrasyonlarda veri kaybını önleme, entegrasyonu kolaylaştırma ve standardizasyon amacıyla yayımladığını belirtir. Bakanlığın dijital hastane kaynakları da HBYS'yi hastane süreçleriyle ve çok sayıda ulusal sistemle etkileşen yazılım grubu olarak tanımlar. Sesli AI projesini bu yüzden mevcut HBYS sözleşmesi, Bakanlık standartları ve üreticinin desteklediği arayüzler üzerinden yürütün. Veritabanına doğrudan yazmak ya da ekran otomasyonunu kalıcı bağlantı gibi kullanmak, üretici desteği ve veri bütünlüğü açısından ayrı risk değerlendirmesi ister.

Bu rehber HBYS ve CRM entegrasyonunu tek bir işlem zinciri olarak anlatır: ana kaynak, kimlik eşleştirme, sözleşme, hata adımları, güvenlik ve test. Her HBYS entegrasyonu üreticinin desteklediği arayüzden ve mevcut sözleşmeden başlar.

İş hedefini ve işlem kapsamını sınırlandırın#

İlk toplantıda teknolojiyi bırakın, iş sonucunu tanımlayın. Mesai dışında randevu iptalini HBYS'ye işlemek, boş saati okuyup talep açmak, CRM'e geri arama görevi açmak ve çağrı nedenini belli alanlara ayırmak ayrı hedeflerdir.

Her hedef için başlangıç ölçüsünü, kullanıcıyı, beklenen işlem sayısını, kullanılabilecek veriyi ve başarı koşulunu yazın. Tıbbi değerlendirme, tanı veya tedavi önerisi idari entegrasyon kapsamına dahil edilmemelidir.

Kapsam tablosunda her işin adı, okuma ve yazma işlemleri, kaynak ve hedef sistem, veri sahibi, yetki seviyesi, hata davranışı ve sorumlusu yer alsın. Randevu oluşturmakla randevu talebi açmayı ayırın.

Üretici dışarıdan yazmaya izin vermiyorsa sesli AI doğrulanmamış bir "tamamlandı" demesin. CRM'de çalışana görev açsın ve dönüş zamanını söylesin.

Deneme için sık yapılan, riski düşük iki ya da üç iş seçin. Adres ve çalışma saati, randevu iptali ya da boş saat sorgusu iyi adaydır. Karmaşık provizyonu, klinik sonuç açıklamayı ve birden fazla kurumun karar verdiği işleri temel yapı kanıtlanmadan eklemeyin.

Sistemler arası veri sahipliğini belirleyin#

Her alana tek bir ana kaynak atayın.

Demografik bilgi, randevu durumu, hekim takvimi, kurum ve branş kodu çoğunlukla HBYS'nin alanıdır. Aday talep, iletişim tercihi, geri dönüş görevi ve görüşme sonucu CRM'de yönetilebilir.

Sesli AI'ı kalıcı kayıt sistemi yapmayın; o yalnız bu sistemlerde kontrollü işlem yapan bir aracıdır. Aynı alan iki sistemde değişebiliyorsa hangisinin geçerli olduğunu yazılı kurala bağlayın.

Bir veri sözlüğü hazırlayın. Alan adı, iş anlamı, kaynak sistem, veri tipi, zorunluluk, izin verilen değer, kod sistemi, hassasiyet sınıfı, dönüşüm kuralı ve saklama süresi kaydedilsin. Branş adı bile HBYS ve CRM'de farklı kodlarla tutulabilir. Ekrandaki metni anahtar yapmayın; değişmeyen sistem kimliklerini ve bakımlı eşleme tablolarını kullanın. SKRS ya da başka referans kodlarda hangi sürümün kullanılacağını ve nasıl güncelleneceğini belirleyin.

CRM'e yalnız günlük iş için gereken alanları kopyalayın. Çağrı merkezinin işi için gerekmiyorsa tam hasta dosyasını aktarmayın. Sağlık verisi, ses kaydı ve döküm özel erişim politikalarına tabi olabilir. Veri minimizasyonu bağlantıyı da hızlandırır; asıl gerekçe yine de KVKK ilkeleri ve yetkisiz ifşa riskini azaltmaktır.

Kimlik eşleştirmeyi ayrı bir iş olarak ele alın#

Telefon numarası hastayı tanımaya yetmez. Numara ailenin ortak hattı, değişmiş bir hat ya da kurum telefonu olabilir. Ad ve doğum tarihi de çakışabilir. Eşleştirme stratejisi işlem riskine göre birden fazla doğrulayıcı kullanmalı, fakat gereksiz kişisel veri toplamamalıdır. T.C. kimlik numarası kullanılacaksa gereklilik, erişim, maskeleme ve hukuki çerçeve ayrıca değerlendirilmelidir.

Sonucu kesin, olası ve bulunamadı diye ayırın. Sistem hassas bilgiyi ancak güven sınırı aşıldığında ve doğrulama tamamlandığında okusun ya da değiştirsin.

Birden fazla aday kayıt çıkarsa sesli AI seçim yapmasın; görüşme bir çalışana geçsin ya da yeni talep açılsın. Başarısız doğrulamada girilen hassas değerler kayda tam hâliyle yazılmasın.

Kişi birden çok kuruluşta ya da şubede kayıtlıysa kurum ve kiracı (tenant) sınırı her sorguda zorunlu filtre olsun. Aynı hasta numarasının farklı veritabanlarında başka kişilere ait olabileceğini unutmayın. Anahtar, kaynak sistemi ve kuruluş kimliğini de taşısın. Birleşen ya da ayrılan hasta kayıtlarını yeniden eşlemeyi önceden planlayın.

Sözleşmeyi API'den önce tanımlayın#

Sözleşme bir uç nokta (endpoint) listesinden fazlasıdır. İstek ve yanıt şemalarını, zorunlu alanları, kodları, zaman dilimini, hata biçimini, sürümü, kimlik doğrulamayı, yetki kapsamını, istek sınırını, zaman aşımını, yeniden denemeyi ve tekrar gelen istekteki davranışı (idempotency) yazıya dökün.

Üreticinin resmî arayüzünü esas alın. Değişiklik takvimini ve eski sürümlerle uyumu sözleşmeye ekleyin.

Her yazma isteğine benzersiz işlem anahtarı ekleyin. Bağlantı kesilirse ya da zaman aşımı olursa aynı istek yeniden gelebilir. Aynı anahtarla gelen istekte HBYS yeni randevu açmasın, önceki sonucu döndürsün. Yerel API bunu desteklemiyorsa aradaki katman bir istek günlüğü ve tekrar ayıklama tablosuyla aynı korumayı sağlasın. Anahtarı, isteğin tekrar gelebileceği süreden uzun saklayın.

Önce okuyup sonra yazan işlemlerde yarış durumunu hesaba katın. Sesli AI boş saati okurken aynı saat web sitesinden ya da resepsiyondan alınabilir. Yazma adımı saatin hâlâ boş olduğunu kontrol edip tek seferde ayırsın. Olmazsa başka seçenek sunulsun; eski bilgi kesinmiş gibi söylenmesin. Güncelleme ve iptalde sürüm numarası ya da son değişiklik zamanı, başka bir çalışanın değişikliğinin üzerine yazmayı önler.

Senkron ve asenkron işlemleri doğru ayırın#

Arayanın hatta beklediği işler, örneğin boş saat sorgusu, kısa ve anında (senkron) yapılabilir. CRM'e görüşme özeti, raporlama ve bildirim sıraya alınıp sonra (asenkron) yapılabilir. Her işlem için en uzun bekleme süresini ve arayana ne söyleneceğini belirleyin. Arka iş için hattı açık tutmak hem deneyimi hem maliyeti bozar.

"Teslim edildi" durumu işin yapıldığını göstermez.

Her mesajın durumunu ayrı izleyin: alındı, işleniyor, başarılı, yeniden deneniyor, insan incelemesinde, kalıcı hata. Yeniden deneme sayısını ve aralığını sınırlayın.

Geçici ağ hatasını ve doğrulama hatasını aynı biçimde denemeyin. Sürekli başarısız olan mesajlar ayrı bir hata sırasına (dead letter queue) düşsün ve sorumlu ekibe görev açsın.

Sıra önemliyse kişiye ya da randevuya göre sıralama anahtarı kullanılabilir. İptalden sonra işlenen gecikmiş bir güncelleme randevuyu geri getirmesin. Her olay sürüm numarasını ve zamanını taşısın ki eski olay güvenle reddedilebilsin.

Hata sözlüğü ve telafi adımları kurun#

Teknik hatayı kullanıcı mesajından ayırın.

HBYS-APPT-409 gibi bir iç kod saatlerin dolduğunu gösterebilir. Arayana ise "Bu saat artık dolu, başka saatlere bakalım" denir. Yetki, veri doğrulama, bulunamayan kayıt, çakışma, zaman aşımı, istek sınırı ve hizmet kesintisi ayrı türler olsun. Sunucunun hassas ayrıntıları ve sorgular sesli yanıta ya da istemci kayıtlarına girmesin.

Her hata için yeniden denenip denenmeyeceğini, hangi yola geçileceğini, ne zaman çalışana devredileceğini ve alarm verilip verilmeyeceğini yazın. Başarısı doğrulanmayan işleme "tamamlandı" demeyin.

Arayan kapattıktan sonra sonuçlanan işlerde kişiye hangi yoldan, hangi izinle ve ne kadar sürede haber verileceğini belirleyin. CRM görevi açıldıktan sonra HBYS işlemi başarısız olursa görev yanlışlıkla kapanmasın.

FHIR ve yerel standartları doğru konumlandırın#

HL7 FHIR, sağlık verisi değişimi için kaynak modelleri ve REST etkileşimleri sunar; ancak her HBYS'nin FHIR desteklediği varsayılmamalıdır. Üreticiye desteklenen sürümü, kaynakları, profilleri, arama parametrelerini ve uygulama rehberini sorun. FHIR adını taşımak, sistemlerin veriyi aynı anlamda okuduğunu göstermez. Zorunlu alanları, kod sistemlerini ve kurum profillerini uygunluk testiyle (conformance) doğrulayın.

HL7'nin güvenlik dokümanı FHIR'ın kendisinin bir güvenlik protokolü olmadığını; TLS, kimlik doğrulama, yetkilendirme, erişim kontrolü ve denetim kaydı gibi kontrollerin ayrıca uygulanması gerektiğini açıklar. SMART App Launch, OAuth tabanlı yetkilendirme ve sınırlı erişim kapsamları için kalıplar sağlar. Oturum açmış bir insan yoksa backend service yaklaşımı düşünülebilir; kuruluş kurallarını, hasta bağlamını ve en az yetki ilkesini yine ayrıca uygulayın. Joker kapsam yerine yalnız gereken kaynak ve işlem için yetki isteyin.

FHIR kullanılmayan yerel API'de de güçlü istemci kimliği, kısa ömürlü kimlik bilgisi, TLS, dar yetki, nesne düzeyinde kontrol ve ayrıntılı denetim gerekir. OWASP API Security Top 10, nesne ve işlev düzeyi yetkilendirme ile hassas iş akışlarına sınırsız erişimin temel riskler olduğunu vurgular. Geçerli bir token, her hasta ya da randevuya erişim hakkı vermez.

Güvenlik mimarisini entegrasyonun içine yerleştirin#

Sesli AI'yı HBYS veritabanına doğrudan bağlamayın; kontrollü bir API ağ geçidi ya da ara katman kullanın. Kimlik doğrulama, yetki, şema doğrulama, istek sınırı, tekrar ayıklama, maskeleme ve denetim orada toplanır. Katman tek hata noktası olmasın; yedekli çalışmasını ve kesinti planını hazırlayın.

Servis hesaplarının sahibi belli olsun. Her ortam ve her bağlantı için ayrı hesap açın. Parolayı kodda tutmayın, sır kasası kullanın, anahtarları düzenli değiştirin. Geliştirme ortamı canlı HBYS'ye erişemesin. Destek erişimi süreli, onaylı ve kayıtlı olsun.

Loglarda çağrı kimliği, işlem anahtarı, sistem, endpoint, durum kodu, gecikme ve hata sınıfı bulunabilir; tam sağlık verisi, token, parola veya gereksiz kimlik bilgisi bulunmamalıdır. Yetkili inceleme için ayrı korumalı kayıt kullanılabilir. Sunucu saatleri birbirini tutmazsa olayların sırası kurulamaz.

Test stratejisini katmanlara ayırın#

Sözleşme testleri şema değişikliğini canlıdan önce yakalar. Birim ve bağlantı testleri dönüşümü, kod eşlemeyi, kimlik doğrulamayı ve hata davranışını sınar. Uçtan uca test, telefon çağrısından HBYS kaydına ve CRM görevine kadar gerçek sonucu doğrular. Performans testi yoğun saati, dayanıklılık testi zaman aşımını ve kısmi kesintiyi, güvenlik testi yetkisiz nesne erişimini ve veri sızıntısını kapsar.

Testte gerçek kişiye ait olmayan kayıtlar kullanın. Canlı verinin kopyası zorunlu bir istisna sayılıyorsa veriyi azaltma, maskeleme, erişim ve silme için ayrıca onay alın. Çakışan randevu, aynı isteğin iki kez gelmesi, yanlış kurum kimliği, birleşmiş hasta kaydı, saat dilimi, karakter kodlama ve çok uzun ad gibi uç durumları da ekleyin.

Kabul testinde yalnız sorunsuz senaryoyu denemeyin. HBYS'nin cevap vermediği, CRM'in görevi reddettiği, telefonun yazma sırasında koptuğu ve bir çalışanın kaydı aynı anda güncellediği durumları da çalıştırın. Arayana söylenen sonuçla arka sistemdeki sonuç tutuyorsa test geçer.

İzleme ve mutabakat tasarlayın#

Tek bir "sistem çalışıyor" ışığı yetmez.

Her iş için başarıyı, iş kuralı reddini, teknik hatayı, zaman aşımını, yeniden denemeyi, sırada bekleme süresini, insana devri ve gecikme yüzdeliklerini izleyin. Oluşturulan, iptal edilen ve değişen randevu sayısı ile açılan ve kapanan CRM görevleri de görünsün. Hassas veri taşımayan, sistemler boyunca aynı kalan bir işlem kimliği çağrının yolunu takip etmeyi sağlar.

Her gün sesli AI'ın başarılı dediği işlemleri HBYS ve CRM kayıtlarıyla karşılaştırın. Eksik, çift ya da durumu farklı kayıtlar istisna listesine düşsün.

Toplam sayılarla yetinmeyin; her işlem anahtarını tek tek eşleştirin. Düzeltmenin otomatik mi, çalışan onayıyla mı yapılacağına riske göre karar verin.

Alarm sınırını işe etkisine göre koyun. Raporlamadaki beş dakikalık gecikme bekleyebilir. Randevu yazma hataları ya da yetki retleri aniden artıyorsa hemen müdahale gerekebilir. Nöbet planında uygulama, HBYS üreticisi, ağ, güvenlik ve iş sorumlularına hangi sırayla ulaşılacağı yazsın.

Aşamalı canlı geçiş planı#

İlk aşamada yalnızca okuma ve CRM'e görev açma kullanılabilir. İkinci aşamada riski düşük randevu iptalini sınırlı şube ve saatlerde yazmaya açın. Üçüncü aşamada performans ve güvenlik sonuçları doğrulandıkça yeni işler ekleyin. Her aşamada özellik bayrağı, işlem sayısı sınırı ve hızlı geri alma yolu olsun.

Geri almak, yeni yazmaları durdurup güvenli biçimde elle çalışmaya geçmektir. Veritabanını zorla eski sürüme döndürmek geri alma sayılmaz. Aşamalı geçişi entegrasyonlu AI Agent kurulumunun adımları ile aynı takvimde planlayabilirsiniz.

Canlıdan önce HBYS ve CRM sahiplerinin şema onayı, veri koruma değerlendirmesi, güvenlik testi, yedek ve kurtarma, destek planı, kayıt karşılaştırması, kullanıcı eğitimi ve tedarikçi iletişimi tamam olsun. İlk günlerde her işlem türünden daha çok örnek seçip kalite kontrolü yapın. Yalnız hata sayısını ölçmeyin; hatanın ne kadar hızlı göründüğü ve ne kadar güvenle düzeltildiği de ölçüye girsin.

Tedarikçi seçiminde istenecek kanıtlar#

Desteklenen HBYS üreticileri listesi yerine sizin sürümünüzle çalışan referans mimari ve test planı isteyin. Resmi API mi, FHIR mı, dosya aktarımı mı, arayüz otomasyonu mu kullanıldığını sorun. Kimlik eşleştirme, tekrar ayıklama, zaman aşımı, veri sahipliği, rol bazlı yetki, kayıtlarda maskeleme, silme ve çıkış senaryoları sizin örneklerinizle gösterilsin. Alt işleyenler ve verinin yurt dışına aktarılıp aktarılmadığı KVKK değerlendirmesine dahil edilmelidir.

Sözleşmeye API sürüm değişikliğinin ne kadar önce bildirileceğini, kritik hataya müdahale süresini, üretici koordinasyonunu, bakım saatlerini, veri dışa aktarmayı, kayıt erişimini, güvenlik olayını ve fesih sonrası silmeyi yazın. Kaynak sistem değişirse yeniden bağlantı maliyetini kimin üstleneceği belli olsun. Başarı primi ya da SLA varsa başarıyı arka sistemde doğrulanmış iş sonucuna göre tanımlayın.

HBYS ve CRM entegrasyonunda kalıcı değeri uç nokta bağlamak üretmez. Değer doğru kaydı doğru sistemde tutan, yetkiyi sınırlayan, tekrar işlemi önleyen, hatayı kaybetmeyen ve sonucu her gün karşılaştıran yapıdan gelir. Bu temeller yoksa görüşme ne kadar iyi olursa olsun kurumun günlük işi güvenle büyütülemez.

İlgili AgentFix rehberleri#

• Sağlıkta dijital dönüşüm yol haritası
• KVKK uyumlu sesli AI kontrol listesi

Bu konunun kurulum karşılığı hastane ve kliniklere özel yazılım geliştirme sayfasında anlatılıyor.