HBYS ve CRM Entegrasyon Rehberi

Entegrasyonun hedefi veri taşımak değil, güvenilir işlem üretmektir

Bir sağlık kuruluşunda sesli yapay zekâ, HBYS ve CRM'i birbirine bağlamak ilk bakışta birkaç API çağrısı gibi görünebilir. Gerçekte proje; aynı kişiyi doğru eşleştirme, randevu durumunu tutarlı tutma, çalışanların yalnızca gerekli veriye erişmesini sağlama, başarısız işlemleri kaybetmeme ve her değişikliği denetlenebilir kılma problemidir. Arayan kişiye randevunuz oluşturuldu denirken HBYS'de kayıt yoksa entegrasyon teknik olarak çalışmış görünse bile iş sonucu başarısızdır. Aynı talep iki kez işlendiğinde veya yanlış hasta kaydı CRM'e taşındığında ise sorun yalnızca verimlilik değil, hasta güveni ve veri koruma riskidir.

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. Bu çerçeve, sesli AI projesinin mevcut HBYS sözleşmesi, Bakanlık standartları ve üreticinin desteklediği arayüzler üzerinden yürütülmesi gerektiğini gösterir. Veritabanına doğrudan yazmak veya ekran otomasyonunu kalıcı entegrasyon gibi kullanmak, desteklenebilirlik ve veri bütünlüğü açısından ayrıca risk değerlendirmesi gerektirir.

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

İlk toplantıda teknoloji değil iş sonucu tanımlayın. Örneğin mesai dışında randevu iptalini HBYS'ye işlemek, uygun randevu saatini okuyup talep oluşturmak, geri arama görevini CRM'e açmak veya çağrı nedenini yapılandırılmış kaydetmek ayrı hedeflerdir. Her hedef için başlangıç metriği, beklenen kullanıcı, işlem hacmi, izin verilen veri ve başarı koşulu yazılmalıdır. Tıbbi değerlendirme, tanı veya tedavi önerisi idari entegrasyon kapsamına dahil edilmemelidir.

Kapsam matrisinde akış adı, okuma ve yazma işlemleri, kaynak sistem, hedef sistem, veri sahibi, yetki seviyesi, hata halinde davranış ve iş sahibi bulunmalıdır. Randevu oluşturma ile yalnızca randevu talebi açma birbirinden ayrılmalıdır. HBYS üreticisi dış yazmaya izin vermiyorsa sesli AI doğrulanmamış bir tamamlanma mesajı vermemeli; CRM'de insan görevi açıp beklenen geri dönüş süresini söylemelidir.

Pilot için yüksek hacimli fakat düşük riskli iki veya üç akış seçin. Adres ve çalışma saati gibi statik bilgi, randevu iptali veya uygunluk sorgusu iyi aday olabilir. Karmaşık provizyon, klinik sonuç açıklama veya birden fazla kurumun eş zamanlı kararını gerektiren akışlar, temel mimari kanıtlanmadan eklenmemelidir.

Sistemler arası veri sahipliğini belirleyin

Her alanın tek bir ana kaynağı olmalıdır. Hasta demografisi, randevu durumu, hekim takvimi, kurum ve branş kodu çoğunlukla HBYS'nin yetkili olduğu alanlardır; aday talep, iletişim tercihi, geri dönüş görevi ve görüşme sonucu CRM'de yönetilebilir. Sesli AI kalıcı ana kayıt sistemi değil, bu sistemlerle kontrollü işlem yapan kanal olmalıdır. Aynı alan iki sistemde değiştirilebiliyorsa çatışma kuralı yazılı olmalıdır.

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ı gibi görünen basit bir alan bile HBYS ve CRM'de farklı kodlarla tutulabilir. Ekranda görünen metni anahtar olarak kullanmak yerine kararlı sistem kimlikleri ve yönetilen eşleme tabloları kullanılmalıdır. SKRS veya kurumun tabi olduğu başka referans kodlar varsa sürüm ve güncelleme süreci belirlenmelidir.

CRM'e yalnızca operasyon için gerekli alanları kopyalayın. Tam hasta dosyası, çağrı merkezi çalışanının işi için gerekli değilse aktarılmamalıdır. Sağlık verisi, ses kaydı ve döküm özel erişim politikalarına tabi olabilir. Veri minimizasyonu, entegrasyon performansını da iyileştirir; ancak temel gerekçe KVKK ilkeleri ve yetkisiz ifşa riskini azaltmaktır.

Kimlik eşleştirmeyi ayrı bir ürün problemi gibi ele alın

Telefon numarası tek başına güvenilir hasta kimliği değildir; ortak aile numarası, değişen hat, kurum telefonu veya yanlış tuşlama 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.

Eşleştirme sonucunu kesin, olası ve bulunamadı gibi durumlara ayırın. Sistem yalnızca belirlenen güven eşiği ve doğrulama adımları tamamlandığında hassas bilgi okumalı veya kayıt değiştirmelidir. Birden fazla aday varsa sesli AI seçim yapmamalı; güvenli insan devri veya yeni talep akışı çalışmalıdır. Kimlik doğrulama başarısızlığının logunda girilen tam hassas değerler bulunmamalıdır.

Kişi birden çok kuruluş veya şubede kayıtlıysa tenant ve kurum sınırı zorunlu filtre olmalıdır. Aynı sayısal hasta kimliğinin farklı veritabanlarında başka kişileri temsil edebileceği unutulmamalıdır. Entegrasyon anahtarı, kaynak sistem ve kuruluş kimliğini birlikte taşımalıdır. Birleşen veya ayrılan hasta kayıtları için yeniden eşleme ve geçmiş işlem takibi planlanmalıdır.

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

Entegrasyon sözleşmesi yalnızca endpoint listesi değildir. İstek ve yanıt şemaları, zorunlu alanlar, kodlar, zaman dilimi, hata biçimi, sürüm, kimlik doğrulama, yetki kapsamı, oran sınırı, zaman aşımı, yeniden deneme ve idempotency davranışı belgelenmelidir. HBYS üreticisinin resmi ve desteklenen arayüzü esas alınmalı; değişiklik takvimi ve geriye uyumluluk beklentisi sözleşmeye bağlanmalıdır.

Her yazma isteğine benzersiz işlem anahtarı ekleyin. Sesli görüşmede bağlantı kesildiğinde veya ağ zaman aşımı oluştuğunda aynı istek yeniden gönderilebilir. HBYS aynı anahtarla gelen tekrar isteği yeni randevu oluşturmak yerine önceki sonucu döndürmelidir. Yerel API bunu desteklemiyorsa entegrasyon katmanı istek günlüğü ve tekilleştirme tablosuyla koruma sağlamalıdır. Anahtarın saklama süresi, işlemin makul tekrar penceresinden uzun olmalıdır.

Okuma sonrası yazma akışlarında yarış koşulunu düşünün. Sesli AI uygun görünen saati okurken başka kanal aynı saati alabilir. Nihai yazma işlemi kapasiteyi atomik doğrulamalı; başarısızlıkta alternatif sunmalı ve eski uygunluğu kesinmiş gibi açıklamamalıdır. Randevu güncelleme veya iptalde sürüm numarası ya da son değişiklik zamanı kullanmak, başka çalışanın yeni değişikliğini ezmeyi önler.

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

Arayanın yanıt beklediği uygunluk sorgusu gibi işlemler kısa süreli senkron olabilir. CRM'e görüşme özeti gönderme, analitik veya bildirim gibi işlemler kuyruk üzerinden asenkron yürütülebilir. Her işlem için maksimum bekleme süresi ve kullanıcıya verilecek mesaj belirlenmelidir. Uzun süren arka iş nedeniyle hattı açık tutmak hem deneyimi hem maliyeti bozar.

Kuyruk sistemi kullanıldığında teslim edildi ifadesi işlendi anlamına gelmez. Mesaj durumu alındı, işleniyor, başarılı, yeniden deneniyor, insan incelemesi ve kalıcı hata olarak izlenmelidir. Yeniden deneme sayısı ve aralığı sınırlı olmalı; geçici ağ hatasıyla doğrulama hatası aynı biçimde tekrar edilmemelidir. Sürekli başarısız mesajlar ölü mektup kuyruğuna alınmalı ve sorumlu ekip için görev oluşturmalıdır.

İşlem sırası önem taşıyorsa kişi veya randevu bazlı sıralama anahtarı kullanılabilir. İptal mesajından önce gecikmiş güncellemenin işlenmesi eski durumu geri getirmemelidir. Olaylarda sürüm ve gerçekleşme zamanı bulunmalı; tüketici eski olayı güvenle reddedebilmelidir.

Hata sözlüğü ve telafi akışı kurun

Teknik hatayı kullanıcı mesajından ayırın. HBYS-APPT-409 gibi iç kod, randevu kapasitesinin dolduğunu gösterebilir; arayana ise saat artık uygun değil, başka saatlere bakalım gibi sade bir mesaj verilir. Yetkilendirme hatası, veri doğrulama hatası, bulunamayan kayıt, çakışma, zaman aşımı, oran sınırı ve hizmet kesintisi ayrı kategoriler olmalıdır. Hassas sunucu ayrıntıları veya sorgular sesli yanıta ve istemci loguna taşınmamalıdır.

Her hata için otomatik yeniden deneme, alternatif akış, insan devri ve alarm kararı yazın. Başarılı olduğu doğrulanmayan işlem için tamamlandı denmemelidir. Arayan kişi hatta değilken sonuçlanan asenkron işlemde hangi kanaldan, hangi izinle ve ne kadar sürede bildirim yapılacağı belirlenmelidir. Telafi işlemleri de denetlenebilir olmalıdır; örneğin CRM görevi açıldıktan sonra HBYS işlemi başarısızsa görev yanlışlıkla kapatılmamalıdır.

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. Önce HBYS üreticisinin desteklediği sürümü, kaynakları, profilleri, arama parametrelerini ve uygulama rehberini sorun. FHIR adı tek başına semantik uyumluluk sağlamaz. Alan zorunlulukları, kod sistemleri ve kurum profilleri conformance testiyle doğrulanmalıdır.

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. Arka uç sesli AI entegrasyonunda insan oturumu yoksa backend service yaklaşımı değerlendirilebilir; yine de kuruluş politikası, hasta bağlamı ve en az ayrıcalık ayrıca uygulanmalıdır. Geniş joker kapsamlar yerine gerekli kaynak ve işlem düzeyi kapsam istenmelidir.

FHIR kullanılmayan yerel API'de de aynı ilkeler geçerlidir: güçlü istemci kimliği, kısa ömürlü kimlik bilgisi, TLS, dar yetki, nesne düzeyinde kontrol ve ayrıntılı denetim. 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. Yalnızca geçerli token sahibi olmak, her hasta veya randevuya erişim hakkı vermez.

Güvenlik mimarisini entegrasyonun içine yerleştirin

Sesli AI'yı doğrudan HBYS veritabanına bağlamak yerine kontrollü API ağ geçidi veya entegrasyon katmanı kullanın. Bu katman kimlik doğrulama, yetki, şema doğrulama, oran sınırlama, tekilleştirme, maskeleme ve denetim görevlerini merkezileştirebilir. Yine de tek hata noktası olmaması için yüksek erişilebilirlik ve kesinti modu tasarlanmalıdır.

Servis hesapları kişiye özel olmayan ancak sahipliği belirli hesaplardır. Her ortam ve entegrasyon için ayrı hesap kullanın; parolayı kaynak kodda tutmayın; sır kasası, anahtar döndürme ve iptal süreci uygulayın. Geliştirme ortamının üretim HBYS'sine erişimi olmamalıdır. Destek erişimi süreli, onaylı ve kayıtlı olmalıdır.

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 gerektiğinde ayrı korumalı kayıt kullanılabilir. Saatlerin senkron olması olay zincirini kurmak için kritiktir.

Test stratejisini katmanlara ayırın

Sözleşme testleri, HBYS ve CRM şemasındaki değişikliği canlıdan önce yakalar. Birim ve entegrasyon testleri dönüşüm, kod eşleme, kimlik doğrulama ve hata davranışını sınar. Uçtan uca test, telefon çağrısından HBYS kaydı ve CRM görevine kadar gerçek iş sonucunu doğrular. Performans testi yoğun saat hacmini; dayanıklılık testi zaman aşımı, kısmi kesinti ve yeniden denemeyi; güvenlik testi yetkisiz nesne erişimi ve veri sızıntısını kapsar.

Test verisi sentetik olmalıdır. Üretim kopyası zorunlu bir istisna olarak görülüyorsa minimizasyon, maskeleme, erişim ve silme için ayrıca onay gerekir. Randevu çakışması, aynı isteğin iki kez gelmesi, yanlış kurum kimliği, birleşmiş hasta kaydı, gün ışığından yararlanma veya saat dilimi, karakter kodlama ve çok uzun ad gibi uç durumlar eklenmelidir.

Kullanıcı kabul testinde yalnızca mutlu yol denenmemelidir. HBYS'nin cevap vermediği, CRM'in görevi reddettiği, telefon bağlantısının yazma sırasında koptuğu ve insan operatörün kaydı güncellediği senaryolar çalıştırılmalıdır. Kabul kriteri, arayana verilen mesajla arka sistemdeki sonucun uyumudur.

Gözlemlenebilirlik ve mutabakat tasarlayın

Tek bir genel sistem çalışıyor göstergesi yetersizdir. Her akış için başarı, iş kuralı reddi, teknik hata, zaman aşımı, yeniden deneme, kuyruk yaşı, insan devri ve gecikme yüzdelikleri izlenmelidir. İş metriği olarak oluşturulan, iptal edilen veya değiştirilen randevu ile açılan ve kapanan CRM görevi sayısı görünmelidir. Hassas veri göstermeyen dağıtık işlem kimliği, çağrının sistemler arasındaki yolunu takip etmeyi sağlar.

Günlük mutabakat işi, sesli AI'ın başarılı dediği işlemleri HBYS ve CRM kayıtlarıyla karşılaştırmalıdır. Eksik, çift veya farklı durumdaki kayıtlar istisna kuyruğuna düşmelidir. Mutabakat yalnızca toplam sayı karşılaştırması değil, işlem anahtarı düzeyinde olmalıdır. Düzeltmenin otomatik mi insan onaylı mı yapılacağı risk bazında belirlenmelidir.

Alarm eşiği iş etkisine bağlanmalıdır. Beş dakikalık analitik gecikmesi düşük öncelikli olabilir; randevu yazma hatalarının artması veya yetkilendirme reddinin aniden yükselmesi acil müdahale gerektirebilir. Nöbet planında uygulama, HBYS üreticisi, ağ, güvenlik ve operasyon sahiplerinin iletişim sırası bulunmalıdır.

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

İlk aşamada yalnızca okuma ve CRM'e görev açma kullanılabilir. İkinci aşamada düşük riskli randevu iptali sınırlı şube ve saatlerde yazmaya açılır. Üçüncü aşamada doğrulanmış performans ve güvenlik sonuçlarına göre yeni akış eklenir. Her aşamada özellik bayrağı, hacim limiti ve hızlı geri alma yolu bulunmalıdır. Geri alma, veritabanını eski sürüme zorla döndürmek değil, yeni yazmaları durdurup güvenli manuel akışa geçmek anlamına gelir.

Canlıya geçiş kapısında HBYS ve CRM sahiplerinin şema onayı, veri koruma değerlendirmesi, güvenlik testi, yedek ve kurtarma, destek planı, mutabakat, kullanıcı eğitimi ve tedarikçi iletişimi tamamlanmış olmalıdır. İlk günlerde her işlem türü daha yüksek örneklemle kalite kontrolünden geçirilir. İyi sonuç yalnızca düşük hata değil, hatanın hızlı görünmesi ve güvenli telafi edilmesidir.

Tedarikçi seçiminde istenecek kanıtlar

Tedarikçiden 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ı açıkça sorun. Kimlik eşleştirme, tekilleştirme, zaman aşımı, veri sahipliği, rol bazlı yetki, log maskeleme, silme ve çıkış senaryosunu kendi örneklerinizle gösterin. Alt işleyen ve veri konumu KVKK değerlendirmesine dahil edilmelidir.

Sözleşmede API sürüm değişikliklerinin bildirim süresi, kritik hata müdahalesi, üretici koordinasyonu, bakım penceresi, veri dışa aktarma, log erişimi, güvenlik olayı ve fesih sonrası silme tanımlanmalıdır. Kaynak sistem değiştiğinde entegrasyon maliyetinin kimde olduğu net olmalıdır. Başarı primi veya SLA varsa başarı tanımı arka sistemde doğrulanmış iş sonucu üzerinden yapılmalıdır.

HBYS ve CRM entegrasyonunda kalıcı değer, en çok endpoint bağlayan çözümden değil; doğru kaydı doğru sistemde tutan, yetkiyi sınırlayan, tekrar işlemi önleyen, hatayı kaybetmeyen ve sonucu her gün mutabık kılan mimariden gelir. Bu temeller kurulmadan sesli AI'ın çağrı kalitesi ne kadar iyi olursa olsun sağlık operasyonu güvenilir biçimde ölçeklenemez.

İlgili AgentFix rehberleri

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