HBYS Entegrasyonu: API mi, Doğrudan Veritabanı mı?

Bir hastane bilgi sistemine dışarıdan bağlanmanın iki yolu vardır: sistemin size veri göndermesi (push) ya da sizin sistemin veritabanından veri okumanız (pull). Hangisinin doğru olduğu, kurumun büyüklüğünden çok altyapısının nerede durduğuna bağlıdır.

Push — kurum API ile gönderir

HBYS randevu oluşturduğunda ilgili bilgiyi bir HTTP isteğiyle dış servise yollar. Dış servis veriyi kendi tarafında saklar.

POST /api/v1/appointments
{
  "frid": 1,
  "appointment_id": "RND-2026-8841",
  "date": "2026-08-14",
  "time_start": "10:30",
  "patient": { "name": "Ayşe Yılmaz", "phone": "05321234567" },
  "doctor":  { "name": "Mehmet Demir", "title": "Uzm. Dr." }
}

Avantajları

• Veritabanı dışarı açılmaz. Güvenlik açısından en önemli fark budur. Bir MySQL portunu internete açmak, kurumun saldırı yüzeyini kalıcı olarak genişletir.
• Şema bağımlılığı yoktur. HBYS'nizde bir kolon adı değiştiğinde dış servis kırılmaz; arada net bir sözleşme vardır.
• Yerel kurulumlarda çalışır. Sunucusu kurum içinde duran, dışarıdan erişilemeyen sistemler için tek uygulanabilir yoldur.
• Ağ gecikmesi kullanıcıya yansımaz. Sayfa açılırken uzak bir veritabanına bağlanmak gerekmez.

Dezavantajları

• HBYS tarafında geliştirme gerekir. Randevu oluşturma, güncelleme ve iptal akışlarına birer çağrı eklenmelidir.
• Senkronizasyon riski vardır. Randevu HBYS'de ertelenir ama çağrı atılmazsa, hasta eski saati görür. Bu, bu yaklaşımın en gerçek riskidir.
• Veri iki yerde durur; silme talepleri iki yerde işlenmelidir.

Senkronizasyon riskini azaltmak

Çağrıyı randevu kaydının yapıldığı tek bir noktaya bağlayın — birden çok ekrandan randevu güncelleniyorsa hepsine ayrı ayrı değil, ortak bir katmana. Ayrıca çağrı başarısız olursa kuyruğa alıp tekrar deneyin; anlık bir ağ hatası yüzünden hastanın yanlış saat görmesi kabul edilebilir değildir.

Pull — dış servis veritabanından okur

Dış servise salt okunur bir veritabanı kullanıcısı verilir; servis randevuyu her gösterimde canlı okur.

Avantajları

• HBYS tarafında geliştirme gerekmez. Kapalı kaynak ya da desteği biten sistemlerde çoğu zaman tek seçenektir.
• Senkronizasyon sorunu yoktur. Randevu ertelenirse ekran zaten güncel veriyi gösterir; randevu silinirse sayfa kendiliğinden kapanır.
• Veri tek yerde durur; silme talebi tek noktada işlenir.

Dezavantajları

• Veritabanı erişilebilir olmalıdır. Kurum içinde duran bir sunucu için bu, VPN ya da port açma anlamına gelir.
• Şemaya bağımlılık vardır. HBYS güncellemesinde kolon adı değişirse entegrasyon kırılır.
• Erişilemezlik doğrudan hastaya yansır. Veritabanı yanıt vermezse hasta randevusunu göremez.

Pull yapıyorsanız uyulması gerekenler

• Kullanıcıya yalnızca SELECT yetkisi verin ve yalnızca gereken tablolarda. Dış servisin randevu silebilmesi için hiçbir neden yoktur.
• Kaynak IP kısıtlaması koyun.
• Bağlantıya kısa bir zaman aşımı tanımlayın (3–5 saniye). Erişilemeyen bir veritabanı, hasta sayfasını dakikalarca kilitlememelidir.
• Bağlantı hatasında hastaya anlamlı bir mesaj gösterin: "sistemimize şu anda ulaşılamıyor, kısa süre sonra deneyin" — teknik hata metni değil.

latin1 veritabanları ve Türkçe karakterler

Pull yaklaşımında Türkiye'ye özgü bir tuzak vardır. 2010 öncesinde kurulmuş birçok HBYS veritabanı latin1 karakter kümesiyle oluşturulmuştur. Bu veritabanlarından utf8mb4 bağlantısıyla okuma yaptığınızda Türkçe karakterler şu hâle gelir:

Sebep şudur: veriler aslında Windows-1254 (Türkçe) kodlamasıyla yazılmış ama tablo latin1 (ISO-8859-1) olarak işaretlenmiştir. MySQL çeviriyi latin1 varsayarak yapar ve altı harf yanlış eşleşir.

Çözüm veritabanını dönüştürmek değildir — bu, çalışan bir HBYS'yi riske atar. Okuma anında düzeltmek yeterlidir:

function turkceDuzelt(string $deger): string
{
    return str_replace(
        ['Ð', 'Þ', 'Ý', 'ð', 'ý', 'þ'],
        ['Ğ', 'Ş', 'İ', 'ğ', 'ı', 'ş'],
        $deger
    );
}

Bu düzeltmeyi yalnızca karakter kümesi latin1 olan kurumlarda uygulayın; utf8mb4 veritabanında çalıştırırsanız doğru harfleri bozarsınız. Kurum kaydında karakter kümesini bir alan olarak tutmak, bu kararı her seferinde tahmin etmekten kurtarır.

Yazma yönü daha risklidir ve ters dönüşüm gerektirir. Salt okunur bir entegrasyon bu sorunu bütünüyle ortadan kaldırır — pull yaklaşımını yalnızca okumayla sınırlamak için bir sebep daha.

Karar tablosu

Son satır, çok kurumlu bir servis işletiyorsanız kaçınılmaz olandır. İki yolu da desteklemenin maliyeti, okuma katmanını tek bir arayüzün arkasına almak ve kaynağı kurum ayarında tutmaktır. Görünüm katmanı verinin nereden geldiğini bilmez; bu ayrım korunduğu sürece iki kod yolunun bakımı zorlaşmaz.

İkisinde de değişmeyen kural

Entegrasyon hangi yönde olursa olsun, randevu üzerindeki tek yetkili kurumun kendi sistemidir. Dış servis randevuyu silmemeli, ertelememeli, durumunu değiştirmemelidir. Hastanın iptal isteği bir talep olarak iletilmeli, işlem kurum tarafında yapılmalıdır.

Bu kısıt bir eksiklik değil, kasıtlı bir tasarım tercihidir: yanlışlıkla ya da kötü niyetle yapılan iptalleri engeller ve kliniğin randevu takvimi üzerindeki denetimini bozmaz.