Tek hekimden polikliniğe: hangi aşamada neye ihtiyaç var?

Klinik büyürken en çok konuşulan konu hasta sayısıdır, ama sistemi zorlayan asıl şey kişi sayısıdır. Tek kişi çalışırken kayıt düzeni gevşek olabilir; ikinci kişi geldiğinde aynı gevşeklik anında soruna dönüşür.

Sebep basit: tek kişilik klinikte bilginin bir kısmı hiç yazılmaz, kafada durur. İkinci kişi bu bilgiye ulaşamaz ve sormak zorunda kalır. Soru sayısı arttıkça asıl işe kalan zaman azalır.

Bu yüzden büyümenin ilk adımı personel almak değil, kaydı kişiden ayırmaktır. Yazılmamış bilgi yazıya döküldüğünde ikinci kişi gerçekten yardımcı olabilir; dökülmediğinde yalnız yeni bir soru kaynağı olur.

İkinci hekim geldiğinde iki yeni ihtiyaç doğar ve ikisi de tek hekimliyken hiç yoktur. Birincisi hekim bazlı ajanda: takvim artık kliniğin değil, her hekimin kendi sütunudur. Randevu verirken hangi hekimin uygun olduğu görünmezse banko çalışamaz.

İkincisi hak edişin ayrışmasıdır. Hangi işlemi hangi hekimin yaptığı ve buna bağlı prim ya da hak ediş hesabı, ay sonunda tartışma yaratan konuların başında gelir. Bu hesabın işlem kaydından otomatik çıkması gerekir; elle tutulan listeler bu ölçekte tutmaz.

Hekim bazlı ajandayı takvim yönetimi sayfasında, hak ediş tarafını hekim prim sayfasında anlattık.

Belirli bir ölçekten sonra klinikte olan biteni gözle takip etmek mümkün olmaz. Kaç randevu verildi, kaçı gerçekleşti, hangi hekimin doluluğu düşük, tahsilat oranı ne — bu soruların cevabı artık rapordan gelir.

Aynı ölçekte denetim izi de gereklilik hâline gelir. Kimin hangi kaydı ne zaman açtığı, sildiği ya da değiştirdiği tutulmuyorsa, bir sorun çıktığında geriye dönüp bakılacak hiçbir şey yoktur.

Üçüncü ihtiyaç ise ekip içi iletişimin kayda geçmesidir. Bilgi kişisel mesajlaşma uygulamalarında dolaştığı sürece ne aranabilir ne de korunabilir; hasta verisi söz konusu olduğunda bu ayrıca bir KVKK sorunudur.

Şube açıldığında ihtiyaç ikiye bölünür: her şubenin kendi randevusunu, hastasını ve tahsilatını kendi içinde yönetmesi gerekir; buna karşılık sahibin toplamı tek yerden görebilmesi gerekir.

Bu noktada kritik olan yetki tasarımıdır. Şube sorumlusu kendi şubesini yönetebilmeli ama diğer şubenin verisine erişememelidir. Aynı anda merkez, hepsini birleştiren raporu alabilmelidir.

Bu ölçekte tipik olarak API erişimi, IP kısıtlaması ve özel raporlar gibi başlıklar da gündeme gelir. Bunlar Enterprise paketinde ele alınıyor.