Problem
Muayenehaneler ve küçük ölçekli tıp merkezleri, büyük hastanelerin aksine her süreç için ayrı sistem işletecek ölçeğe sahip değil. Hasta kaydı bir yerde, tahsilat başka bir yerde, resmi bildirimler üçüncü bir kanalda tutulduğunda günlük işin önemli bir kısmı aynı bilgiyi tekrar girmeye gidiyor.
Ürün birden fazla ülkede kullanılacaksa buna iki şey daha ekleniyor: arayüzün yeni bir dile sonradan açılabilmesi ve her kurumun verisinin diğerlerinden ayrı durması. Bu ikisi sonradan eklenen özellikler değil, en baştan mimariyi belirleyen kısıtlar.
Yaklaşım
Sistemi tek bir platform olarak ele aldım: sağlık, mali ve idari süreçler ayrı ürünler değil, aynı kayıt üzerinden ilerleyen adımlar. Amaç ekran sayısını artırmak değil, aynı bilginin ikinci kez girilmesini gerektiren noktaları azaltmaktı — operasyonel iş yükü çoğunlukla orada birikiyor.
Modüller
Kurumların günlük işini karşılayan modüller şu başlıklarda toplandı:
- Hasta ve muayene süreçleri: Hasta kaydı ve muayenenin kendi akışı.
- Sağlık kayıtları: Muayene sonucunda oluşan klinik kayıtlar.
- Mali işlemler: Kurumun tahsilat ve finansal takibi.
- İdari işlemler: Kurum yönetimine ait tanım ve süreçler.
- Günlük operasyon: Kurumun gün içindeki işleyişini yöneten ekranlar.
Çok Dilli Yapı
Uygulama baştan çok dilli olacak şekilde tasarlandı. Çeviriler koda gömülü değil; dinamik bir çeviri altyapısı üzerinden yönetiliyor. Bunun pratik karşılığı, yeni bir dilin sisteme eklenmesinin geliştirme işi olmaktan çıkması.
Aynı yapı, platformun farklı ülkelerdeki sağlık kuruluşlarına uyarlanabilmesinin de temeli oldu.
Çoklu Veritabanı Mimarisi
Kurumlar ortak bir tabloda değil, kurum bazlı ayrı veritabanlarında tutuluyor. Bu tercihin üç gerekçesi vardı:
- Performans: Bir kurumun veri hacmi diğer kurumların sorgularını yavaşlatmıyor.
- Veri izolasyonu: Kurum verisi mantıksal bir filtreye değil, ayrı bir veritabanı sınırına dayanıyor.
- Güvenlik: Erişim yetkisi veritabanı düzeyinde de ayrılabiliyor.
Böylece aynı altyapı üzerinde birden fazla kuruma ve birden fazla ülkeye hizmet verebilen, yatay olarak büyütülebilir bir yapı oluştu.
Kamu Sağlık Sistemleri Entegrasyonları
Ulusal sağlık sistemleriyle entegrasyon kapsamında dört akış geliştirildi:
- E-İmza ile elektronik reçete bildirimi: Reçetenin elektronik imzayla resmi kanala bildirilmesi.
- Renkli Reçete: Kontrole tabi ilaç reçetelerinin ilgili sisteme bildirimi.
- Aşı Takip Sistemi (ATS): Aşı kayıtlarının takip sistemine aktarılması.
- E-Nabız: Sağlık kayıtlarının ulusal kişisel sağlık kaydı sistemine iletilmesi.
Bu akışlarda kurumun kendi kaydı ile dış sisteme gönderilen bildirim ayrı ayrı izleniyor; gönderilemeyen bir bildirim, kurum içindeki kaydı geçersiz kılmıyor.
Projedeki Rolüm
Yazılım mimarisi, çoklu dil ve çoklu veritabanı altyapısı, sağlık modülleri, kamu sağlık sistemleri entegrasyonları ve ölçeklenebilir web uygulamasının geliştirilmesi ile yönetilmesi süreçlerinde aktif olarak görev aldım.
Kullandığım Teknolojiler
Vue.js, Nuxt.js, Laravel, PHP, MySQL ve REST API. Arayüz ile sunucu tarafı REST API üzerinden konuşuyor; kurum bazlı veritabanı seçimi sunucu tarafında ele alınıyor.
Teknik Odak
- Sağlık, mali ve idari süreçlerin tek platformda birleştirilmesi.
- Çeviriyi veri olarak ele alan dinamik çok dilli yapı.
- Kurum bazlı çoklu veritabanı ve veri izolasyonu.
- Aynı altyapı üzerinde çok kurumlu, çok ülkeli çalışma.
- Kamu sağlık sistemleriyle bildirim entegrasyonları.
- Bildirim durumunun kurum kaydından ayrı izlenmesi.
Proje Bağlamı
İlk işyerimde üzerinde çalıştığım projelerden biri. Her kuruma ayrı veritabanı veren bir yapıda asıl mesele sorguların kendisi değil, şema değişikliğinin tüm kurumlara tutarlı biçimde uygulanabilmesi oluyor; tek bir kurumda kalan bir güncelleme, zamanla birbirinden ayrışan kopyalar üretiyor.
Aynı şey çeviri tarafında da geçerli: dil eklemeyi kolaylaştıran yapı, eksik çevirinin sessizce boş bir etiket olarak görünmesi riskini de beraberinde getiriyor. İzolasyon ve esneklik kazandıran her tercihin, tutarlılığı ayrıca gözetmeyi gerektiren bir bedeli oluyor.