Hasta Takip Programı Nedir? Klinikler İçin Seçim Rehberi

Bir hasta takip programı seçerken ilk soru, ekibin randevuları nerede göreceği değildir. Asıl soru, kuruluşun hangi hasta kayıtlarını tutacağı, bu kayıtları kimlerin kullanacağı ve mevcut çalışma biçiminin yeni sisteme nasıl taşınacağıdır. Muayenehane, poliklinik ve özel diş kliniği aynı ekranları kullanıyor gibi görünse de kayıt ihtiyaçları ve tabi oldukları düzenlemeler aynı değildir. Bu rehber, ürün vaatlerinden önce kuruluş türünü ve iş akışını esas alan bir seçim çerçevesi sunar.

Hasta takip programı nedir?#

Hasta takip programı, kliniğin hasta ile ilgili idari ve klinik işlerini düzenlemek için değerlendirdiği yazılımdır. Muayenehane yazılımı, klinik yönetim yazılımı ya da hasta takip sistemi diye de anılır. Kâğıt dosya, ajanda ve ayrı tahsilat defteri yerine hastanın randevusunu, başvurularını, işlemlerini ve ödemesini aynı kayıt altında toplamayı amaçlar. Bu ifade yine de tek bir ürün sınıfını veya sabit bir özellik paketini tanımlamaz. Bir ürün yalnızca takvim ve iletişim bilgilerini yönetirken başka bir ürün klinik kayıt süreçlerini de kapsayabilir. Satın alma görüşmesinde bu farkı ürün adıyla değil, ekranda gösterilen işlevler ve yazılı kapsam üzerinden anlamak gerekir.

Özellikle randevu talebi ile kesinleşmiş randevuyu ayırın. HL7’nin FHIR Appointment açıklaması, uygun görünen bir zaman aralığının kesin rezervasyon anlamına gelmeyebileceğini ve rezervasyonu işleyen sistemin ek kurallar uygulayabileceğini belirtir. Bu, değerlendirme sırasında sorulacak yararlı bir soruya dönüşür: Hastaya hangi aşamada kesin randevu bilgisi iletiliyor? Standarttaki açıklama, aday yazılımın FHIR desteklediğini veya belirli bir rezervasyon yöntemi kullandığını kanıtlamaz.

Bir başka ayrım da iletişim talebi ile hasta dosyası arasındadır. Telefon ya da mesajla gelen ilk başvuru, klinik personelinin incelemesini bekleyen bir talep olabilir. Hasta dosyasındaki tıbbi bilgi ise farklı erişim ve doğruluk ihtiyaçları doğurur. Bu nedenle görüşmede ‘hasta kaydı açılıyor’ yanıtıyla yetinmeyin; hangi bilginin kim tarafından, hangi aşamada dosyaya işlendiğini örnek bir akış üzerinde gösterilmesini isteyin.

Temel modüller: randevu, hasta kartı, anamnez, onam, ödeme ve e-Nabız#

Ürünler aynı adları kullanmasa da değerlendirmede sık karşılaşılan işlevler şunlardır: hekim ve oda bazında randevu takvimi; kimlik, iletişim ve geçmiş başvuruları içeren hasta kartı; branşa özgü anamnez ve muayene notu; işlem bazında onam kaydı; ön ödeme, taksit ve bakiye takibi; Bakanlık sistemlerine veri gönderimi ve gelmeyen hasta oranı, hekim doluluğu gibi yönetim raporları. Yalnız randevu takvimi sunan ürünler genellikle "randevu programı" olarak satılır; hasta takip programı ifadesi bu takvime klinik ve idari kayıtları ekler. Her modülün aşağıdaki sorularla ayrıca sınanması gerekir.

Randevu ve hasta kartı: Takvimdeki bir değişikliğin hasta kaydında nasıl göründüğünü; aynı hastaya ait mükerrer kayıtların nasıl fark edildiğini ve yanlış kişiye işlenmiş bilginin nasıl düzeltildiğini sorun. Bunlar her programda bulunduğu varsayılacak özellikler değil, canlı gösterimde sınanacak seçim sorularıdır. Randevu talebi alındıktan sonraki ekip işini ayrıca düşünmek için randevu formu sonrası geri arama yazısı da bir süreç karşılaştırması sunar.

Anamnez ve onam: Anamnez alanları için klinik ekibin hangi bilgileri, hangi dilde ve hangi aşamada istediğini belirleyin. Anamnez formu ve dijital ön kayıt konusunu ayrıca incelemek, formun doldurulması ile bilginin klinik kayda alınmasını birbirinden ayırmaya yardımcı olabilir. Onam ekranını değerlendirirken yalnızca ‘imza var mı?’ diye sormayın. Sağlık Bakanlığının Hasta Hakları Yönetmeliği, belirttiği durumlarda rıza formunun hastaya sözlü açıklanması, imzalanması ve bir nüshasının hasta dosyasına konulmasına ilişkin hükümler içerir. Bir yazılım ekranı, bu sürecin kendisi yerine geçmez. Taslak hazırlama ihtiyacı için onam formu oluşturucu incelenebilir; oluşturulan metnin ilgili müdahale ve kuruluşun uygulaması için uygunluğu ayrıca değerlendirilmelidir.

Ödeme: Teklifte ödeme takibi ifadesi geçiyorsa hangi tutarın, işlemin ve düzeltmenin hangi kayıtta göründüğünü sorun. Ödeme ekranı ile klinik kayıt ekranının aynı üründe bulunması, aralarında ihtiyaç duyduğunuz bağlantının kurulduğu anlamına gelmez. İade veya kayıt düzeltmesi gibi örnekleri satıcıya kendi çalışma akışınız üzerinden gösterin.

e-Nabız ve veri gönderimi: Bakanlığın e-Nabız yardım sayfası, sistemde görülen teşhis, tahlil, görüntüleme ve ilaç bilgilerinin sağlık kuruluşlarının elektronik ortamda gönderdiği bilgilerle oluştuğunu açıklar. Sağlık Bakanlığının ayakta teşhis ve tedavi yönetmeliği de kapsamındaki kuruluşların kaydettiği kişisel sağlık verilerinin Bakanlığın belirlediği usul ve esaslara göre merkezi sağlık veri sistemine aktarılmasını düzenler. Bu hükümler, incelediğiniz herhangi bir ürünün kendiliğinden e-Nabız bağlantısı sunduğunu göstermez. Satıcıdan kuruluş türünüze uygun gönderim kapsamını, bağlantının kimin sorumluluğunda olduğunu ve hatalı gönderimin nasıl ele alındığını yazılı açıklamasını isteyin.

Muayenehane, poliklinik ve diş kliniği ihtiyaçları#

Önce ruhsatınızdaki kuruluş türünü belirleyin. Sağlık Bakanlığının ayakta teşhis ve tedavi yönetmeliği tıp merkezi, poliklinik, fizik tedavi ve rehabilitasyon müessesesi ile muayenehaneyi kapsar. Yönetmeliğin hasta kayıtlarına ilişkin maddesi, bu kapsamdaki kuruluşlarda elektronik kaydı ve kayıt ile arşivleme için Bakanlığın kayıt tescil sisteminde kayıtlı yazılım kullanımını düzenler; muayenehane için muayene bilgi yönetim sistemini ayrıca belirtir. Dolayısıyla muayenehane yöneticisi satıcıya genel bir ‘klinik programı’ sorusu yerine, kendi kuruluş türü için sunduğu yazılımın kapsamını ve kayıt durumunu sormalıdır.

Poliklinik değerlendirmesinde ortak takvim kadar görev paylaşımını da gösterim senaryosuna alın: Başvuru kim tarafından görülür, randevu değişikliğini kim onaylar, klinik kayda kim erişir? Bunlar polikliniklerin tamamında aynı şekilde yürütüldüğü ileri sürülen kurallar değil, yerel iş akışını yazılım üzerinde sınama sorularıdır. Sağlık Bakanlığının yönetmeliğindeki elektronik kayıt ve merkezi sisteme aktarım hükümlerini de kuruluşunuzun statüsü bakımından ayrıca değerlendirin.

Özel ağız ve diş sağlığı kuruluşları için Sağlık Bakanlığının ayrı yönetmeliğine bakılmalıdır. Bu düzenleme elektronik hasta kaydı ve Bakanlığın kayıt tescil sisteminde kayıtlı sağlık bilgi yönetim sistemi kullanımını ele alır. Teşhis ve tedavi bilgilerinin; varsa röntgen ile genel anestezi veya sedasyon altındaki işlemlerin diş numaralarıyla birlikte ayrıntılı kaydına ilişkin hükümler de içerir. Müdahaleler için ilgili mevzuata uygun rıza formunu ayrıca düzenler. Bu nedenle diş kliniği gösteriminde genel bir hasta kartı yerine, kuruluşun gerçekten kullandığı diş bazlı kayıt ve onam akışını görmek daha anlamlıdır. Diş kuruluşuna ilişkin hükmü muayenehane veya polikliniğe otomatik olarak uygulamayın.

Mevzuat ayrımının yanında iş akışı da ihtiyacı değiştirir. Aşağıdaki tablo bir seçim önerisidir; kuruluş türüne göre gösterimde öncelik verilecek konuları ve sık gözden kaçan noktaları özetler:

Hasta takip programı seçim kriterleri: kontrol listesi#

Aday ürünleri aynı kısa iş akışıyla sınayın. Örnek hasta bilgilerini gerçek hasta verisi kullanmadan hazırlayın; satıcıdan her adımı göstermesini ve gösteremediği noktayı teklif kapsamından ayrı işaretlemesini isteyin.

• Kuruluş türü ve kayıt durumu: Yazılımın hangi kuruluş türüne sunulduğunu, ilgili kayıt tescil bilgisinin nasıl doğrulanacağını ve sözleşmede hangi ürünün adının geçtiğini sorun. Bakanlığın KTS kayıt aşamaları sayfasında tedarikçilere yönelik aşamalar ve SBYS yazılım listesine ilişkin belge yer alır; bu sayfa tek başına belirli bir teklifin uygunluğunu onaylamaz. Muayenehane yazılımları için Kayıt ve Tescil Birimi ayrıca aktif ve pasif liste yayımlar: MBYS sayfasına göre aktif listede sağlık bilişim standartlarına ve Bakanlığın veri gönderim servislerine uyan, veri gönderimlerinde başarılı ve istenen belgeleri teslim etmiş üreticiler yer alır; bu şartlardan birini sağlamayanlar pasif listededir. Aday ürünün üreticisini aktif MBYS listesinde aramak birkaç dakika sürer.
• Randevu sınırı: Talebin alınması, personelin onayı, değişiklik ve iptal durumlarını ayrı ayrı deneyin. Hastaya gönderilecek bilginin kesinleşmiş randevuyu mu, yalnızca alınmış talebi mi anlattığını kontrol edin. Görünür boşluğun kesin rezervasyon anlamına gelmeyebileceği, HL7 Appointment açıklamasındaki sınırlardan biridir.
• Kayıt ve erişim: Mükerrer hasta, yanlış kayıt düzeltmesi, personel erişimi ve kullanıcı ayrılması örneklerini çalıştırın. Sağlık verileri özel nitelikli kişisel veridir; Kişisel Verileri Koruma Kurumu bu verilerin işlenmesini Kanun’daki şartlar ve yeterli önlemler çerçevesinde ele alır. Ekrandaki bir izin kutusunu tek başına hukuki dayanak veya veri güvenliği kanıtı saymayın. Kişisel Sağlık Verileri Hakkında Yönetmelik, sağlık personelinin kişinin sağlık verisine verilecek hizmetin gereğiyle sınırlı olarak erişebileceğini düzenler; bu nedenle sekreter, hekim ve muhasebe için rol bazlı yetkinin nasıl kurulduğunu gösterimde isteyin. Aynı yönetmelik banko, gişe ve masa gibi bölümlerde başkalarının kişisel veriyi görmesini veya duymasını önleyecek fiziki, teknik ve idari tedbirleri de ister; ekranda açık kalan hasta kartı bu açıdan ayrıca değerlendirilmelidir.
• Güvenlik soruları: Satış sunumundaki genel ifadelerle yetinmeyin. KVKK Kurulunun 2018/10 sayılı kararı, özel nitelikli veriler için kriptografik anahtarların güvenli ve farklı ortamlarda tutulmasını, veriler üzerindeki tüm hareketlerin işlem kayıtlarının güvenli biçimde loglanmasını ve uzaktan erişimde en az iki kademeli kimlik doğrulamayı sayar. Bu başlıkları teklif aşamasında yazılı olarak sorun.
• Yedek ve kesinti: Yedeğin nasıl alındığını, geri yüklemenin nasıl denendiğini ve sistem kullanılamadığında ekibin hangi kayıtla çalışacağını yazılı isteyin. Sağlık Bakanlığının ayakta teşhis ve tedavi yönetmeliği, kapsamındaki kuruluşlarda elektronik hasta verilerinin güvenli yedekleme sistemiyle düzenli yedeklenmesini düzenler; burada önerilen deneme soruları ise seçim kontrol listesidir.
• Veri taşıma: Hasta kartları, randevular ve varsa eklerin hangi biçimde dışa aktarılacağını; yeni sisteme geçişte dönüşümün kimin işi olduğunu sorun. ABD Sağlık Bilgi Teknolojileri Ofisinin EHR rehberi, sistem değiştirmede veri taşınabilirliği, aktarım ve dönüştürmeyi değerlendirmeyi önerir. Bu bir Türkiye mevzuatı hükmü değildir.
• Sözleşme ve destek: Kurulum, eğitim, destek, veri çıkarma ve sözleşme sonunda erişim koşullarını ayrı satırlarda karşılaştırın. Gösterimde çalışan işlevle teklif edilen işlevin aynı olduğunu yazılı olarak netleştirin.

Ücretsiz hasta takip programlarının sınırları#

‘Ücretsiz’ etiketi, ürünün kuruluşunuz için uygun veya uygunsuz olduğunu tek başına söylemez. Karşılaştırmayı peşin yazılım bedeline sıkıştırmak yerine şu soruları sorun: Kuruluş türünüze uygun kayıt tescil durumu nedir? Verinizi hangi biçimde dışarı alabilirsiniz? Kurulum ve eğitim kapsamda mıdır? Destek nasıl sağlanır? ABD Sağlık Bilgi Teknolojileri Ofisinin kamu EHR rehberi, fiyat karşılaştırmasında yazılımla birlikte uygulama, eğitim ve destek kalemlerini ayrı değerlendirmeyi önerir; bu, Türkiye için bir fiyat verisi veya ücretsiz ürünler hakkında genel bir hüküm değildir.

İki teklifi aynı satırlara yazın: yazılım kullanımı, kurulum, eğitim, destek ve ileride veri taşıma koşulları. Bir kalem için fiyat verilmemişse onu sıfır kabul etmek yerine ‘teyit edilecek’ olarak bırakın. Ücretsiz sürüm ile ücretli sürüm arasındaki farkı da ürün adı üzerinden değil, ihtiyaç duyduğunuz iş akışının gösterimi üzerinden belirleyin. Özellikle klinik kayıtla yalnızca randevu tutmayı birbirine karıştırmayın. İletişim kayıtlarını ve randevu taleplerini izlemek için sunulan ücretsiz hasta takip programı seçeneklerinde de klinik kayıt kapsamı ayrıca sorulmalıdır.

Ücretsiz seçeneklerde üç soru daha öne çıkar. Birincisi verinin nerede durduğudur: genel amaçlı takvim ve form araçları sağlık verisi için tasarlanmamış olabilir. İkincisi Bakanlık bildirimidir: veri gönderimi olmayan bir araç, ikinci bir sisteme çift giriş gerektirebilir. Üçüncüsü ücretsizliğin karşılığıdır: kullanıcı sınırı, dışa aktarma kısıtı veya sonradan ücretli pakete geçiş gibi koşullar sözleşmede yazılı olmalıdır. Hastanın kliniği bir platform üzerinden bulduğu ücretsiz randevu hizmetlerinde ise platformun hangi veriyi hangi amaçla işlediğini ve kliniğin veri sorumlusu olarak hangi yükümlülükleri sürdürdüğünü ayrıca kontrol edin.

Eski sistemden yeni programa geçiş#

Seçim kadar geçiş de plan ister. Kâğıt dosyadan, tablodan ya da başka bir yazılımdan taşınırken aşağıdaki sıra bir operasyonel öneri olarak kullanılabilir:

1. Envanter çıkarın: Hasta kimlik ve iletişim bilgisi, geçmiş randevular, açık tedavi planları, kalan bakiyeler ve taranmış belgeleri ayrı ayrı listeleyin.
2. Temizlik yapın: Mükerrer kayıtları ve eksik iletişim bilgilerini taşımadan önce ayıklayın.
3. Deneme aktarımı isteyin: Tedarikçiden küçük bir örnek grupla aktarım yapmasını ve alan eşleşmesini birlikte kontrol etmeyi isteyin.
4. Paralel dönem belirleyin: Kısa bir süre iki sistemi birlikte kullanın; yeni randevuları yalnız yeni sisteme girin.
5. Rol bazında eğitin: Görevli, hekim ve muhasebe aynı ekranları kullanmaz; eğitimi de buna göre planlayın.
6. Eski verinin saklanmasını yazın: Eski sistemdeki kayıtların hangi ortamda, ne kadar süre ve kimin erişimiyle tutulacağını belirleyin.

İletişim alanlarının doğruluğunu ayrı bir kontrol adımı olarak ele alın. Telefon numarası yanlış taşınan bir hasta, hatırlatma ve teyit mesajlarını alamaz. Taşıma sırasında mevcut sistemle bağlantı gerekiyorsa veri alanlarını ve sorumlulukları kuruma özel kurulum ve entegrasyon kapsamı içinde yazılı hale getirin.

Hasta iletişimi katmanı: program ile asistan birlikte nasıl çalışır?#

Klinik kayıt tutma kapsamı doğrulanmış ürünlerde hasta takip programı, bu rehberde klinik kaydın değerlendirildiği ana sistem olarak ele alınır; iletişim katmanı ise gelen talebin karşılanması ve ekibe iletilmesi için ayrıca tasarlanabilir. AgentFix bu rehberde hasta takip programı olarak değil, değerlendirilebilecek ayrı bir iletişim katmanı olarak ele alınır. Belirli bir klinik yazılıma bağlantı, çift yönlü veri aktarımı veya randevunun otomatik kesinleştirilmesi varsayılmamalıdır. Bağlantı düşünülüyorsa kapsamı, veri alanlarını ve sorumlulukları yazılı teklif üzerinde karşılaştırın; AgentFix'i bir [klinik otomasyon platformu](/) olarak değerlendirirken de aynı yazılı kapsam esas alınmalıdır. Sistemler arasında hangi bilginin aktarılacağını düşünürken HBYS ve CRM entegrasyonu yazısındaki süreç ayrımını da göz önünde bulundurun.

Acil devir için operasyonel tasarım önerisi: Kliniğin hekimlerince onaylanan acil ifade listesine uyan bir mesaj geldiğinde kişiyi hemen ve koşulsuz yerel acil yardım kanalına yönlendirecek bir akış tasarlayın. Buna ek olarak mesajı doğrudan görevli insana veya kliniğe aktarın; insan aktarımı acil yardım yönlendirmesinin yerine geçmesin. İletim ya da sistem çalışmazsa acil yardım yönlendirmesi geciktirilmemeli; alternatif iletişim kanalı ve sorumlu görevli klinikçe önceden belirlenmelidir. Bu yazıda kullanılan kaynaklar otomatik acil değerlendirme veya aktarım mimarisini tarif etmez: Hangi ifadelerin listeye alınacağını, hangi insanın devralacağını ve hata akışını kliniğin klinik onayı belirler. Otomasyon tanı, tedavi önerisi veya klinik karar yerine geçmez.