Muayenehane ya da özel sağlık kuruluşu için yazılım seçen herkes bir noktada aynı kısaltmalarla karşılaşır: KTS, MBYS, USS, e-Nabız, SKRS. Satıcıların bir kısmı bu kısaltmaları birbirine karıştırır, bir kısmı da gerçek duruma uymayan ifadelerle satış yapar. Bu yazı, kısaltmaların ne anlama geldiğini, yazılım firması ile kliniğin sorumluluklarının nerede ayrıldığını ve bir yazılım satıcısına hangi soruları sormanız gerektiğini anlatır. Hukuki görüş niteliği taşımaz; hangi yükümlülüğün size uygulandığını Sağlık Bakanlığı kaynaklarından ve danışmanınızdan doğrulayın.
Kısaltmalar: kim kimdir?
KTS (Kayıt ve Tescil Sistemi): Sağlık Bakanlığı'nın, sağlık alanında kullanılan bilgi sistemlerinin kayıt ve tescilini yürüttüğü sistem. Yazılım üreticileri ürünlerini bu sistem üzerinden başvuru ve değerlendirme sürecine sokar; kayıtlı yazılımlar yayımlanan listelerde görünür. Resmî bilgi için KTS kayıt aşamaları(yeni sekmede açılır) sayfasına bakabilirsiniz.
MBYS (Muayenehane Bilgi Yönetim Sistemi): Muayenehane ölçeğindeki sağlık işletmelerinin kullandığı bilgi yönetim yazılımı kategorisi. Bakanlık, bu kategori için kayıt ve tescil bilgilerini ayrı bir sayfada duyurur: MBYS kayıt ve tescil(yeni sekmede açılır).
USBS (Uzaktan Sağlık Bilgi Sistemi): Uzaktan sağlık hizmetinde kullanılan yazılım kategorisi. Ayrı bir kayıt sürecine tabidir; ayrıntı için telehealth yazımıza bakabilirsiniz.
USS / e-Nabız veri gönderimi: Kuruluşun, belirlenen asgari sağlık verisini ulusal sisteme iletmesi. Veri gönderiminin biçimi, kodlaması ve zamanlaması Bakanlığın yayımladığı veri tanımlarına göre belirlenir.
SKRS: Sağlık Kodlama Referans Sunucusu; veri gönderiminde kullanılan standart kodların kaynağı.
Bu kategoriler arasındaki fark önemlidir: bir yazılımın MBYS olarak kayıtlı olması, USBS olarak kayıtlı olduğu anlamına gelmez; veri gönderimi yapabiliyor olması da kayıtlı olduğu anlamına gelmez. Her biri ayrı bir yeterlilik ve doğrulama konusudur.
Klinik olarak yükümlülük nerede başlar?
Ayakta teşhis ve tedavi yapılan özel sağlık kuruluşlarına ilişkin yönetmelik ve sağlık bilgi yönetim sistemlerine ilişkin düzenlemeler, belirli kuruluşların Bakanlıkça kayıtlı bir bilgi yönetim sistemi kullanmasını ve belirlenen verileri ulusal sisteme göndermesini öngörür. Bu hükümlerin kuruluşunuza nasıl uygulandığı; kuruluş türüne (muayenehane, poliklinik, tıp merkezi, tanı merkezi vb.), faaliyet iznine ve güncel düzenlemelere bağlıdır.
Pratik yaklaşım şudur: kullanacağınız yazılımın, sizin kuruluş türünüz için kayıtlı ve veri gönderimi yapabilir olduğunu yazılı doğrulatın ve bu doğrulamayı Bakanlığın resmî kaynaklarından da kontrol edin. Satıcının sözlü beyanı yeterli değildir.
Yazılım firması neyi gerçekleştirmek zorunda?
Bir yazılım firmasının kayıt sürecinde karşılaştığı işler genel hatlarıyla şunlardır:
- Ön değerlendirme. Ürünün hangi kayıt kategorisine girdiğinin, denetim kapsamının ve gerekli belgelerin netleştirilmesi.
- Kurumsal belgeler. Firma bilgileri, yetkili kayıtları, gizlilik ve güvenlik taahhütleri.
- Bilgi güvenliği ve süreç yeterliliği belgeleri. Bilgi güvenliği yönetim sistemi sertifikası ve yazılım süreç olgunluğu belgeleri gibi, güncel kılavuzda tarif edilen yeterlilik kanıtları. Hangilerinin hangi kategori için aranacağı güncel kılavuza bağlıdır.
- Gereksinim-kanıt izlenebilirliği. Kılavuzdaki her maddenin tasarım, test ve operasyon kanıtına bağlanması.
- Entegrasyon ve standart testleri. Ulusal servislerle veri gönderimi, hata durumları ve veri tanımı uyumu testleri.
- Denetim bulgularının kapatılması. Eksik görülen noktaların düzeltilmesi.
- Aktif listeye giriş ve süreklilik. Kayıt sonrası sürüm değişikliklerinde ve mevzuat güncellemelerinde yeniden uyum.
Resmî kaynaklarda yazılım kaydı için uçtan uca bir süre garantisi ya da önceden ilan edilmiş sabit bir ücret bulunmadığından, yazılım firmalarının kesin bir tescil tarihi taahhüt etmesi beklenmemelidir. Kesin tarih veren bir satıcıya dikkat edin.
"Başvuru yapıldı" ile "kayıtlı" aynı şey değildir
Yazılım pazarında en sık rastlanan yanıltma budur. Bir firma başvuru yapmış olabilir; başvuru süreci sürüyor olabilir; ürün henüz listede olmayabilir. Bu durum, ürünün kayıtlı olduğu anlamına gelmez. Müşteri olarak sorulacak sorular:
- Ürün hangi kategoride ve hangi sürümle kayıtlı? Aktif listede yer alıyor mu?
- Kayıt belgesi ya da Bakanlık yazısı gösterilebiliyor mu?
- Kayıt tarihi ve geçerlilik koşulları nelerdir?
- Kayıt sonrası sürüm değişikliklerinde yeniden doğrulama gerekiyorsa bunu kim yönetiyor?
- Sözleşmede kayıt durumu açıkça yazılı mı; kayıt kaybedilirse müşterinin hakları nedir?
Bu soruların yanıtını yazılı almak, satın alma kararını gerçek duruma dayandırır. HekimBis'in USS/e-Nabız yaklaşımını e-Nabız entegre yazılım sayfasında bulabilirsiniz.
Mutabakat tamam
Gönderilen paket, makbuz ve kaynak kayıt eşleşir; gönderim kapanır.
- Süreç burada tamamlanır.
- P-0044Hata kodu E-17 · eksik alanÇözülecek
- P-0045DüzeltildiYeniden gönderim
Ekrandaki ad, saat ve kayıtlar örnek olarak hazırlanmıştır.
Adımların tamamı
- 01 Klinik olay (Klinik kayıt) İmzalı bir muayene ya da tanısal sonuç, ulusal veri paketi doğuran bir olay olarak işaretlenir.
- 02 Sürümlü eşleme (Eşleme) Olay, geçerli SKRS/USVS kurallarına göre eşlenir; eşleme sürümü kayda yazılır.
- 03 Veri paketi ve kaynak izi (Eşleme) Paket oluşturulur; kaynak kayda değişmez bağ (provenance) kurulur.
- 04 Tek seferlik gönderim (Gönderim) Paket, tek seferlik anahtarla Bakanlık servisine gönderilir; aynı anahtar ikinci kez kabul edilmez.
- 05 Makbuz (receipt) (Bakanlık servisi) Bakanlık servisi kabul eder ve makbuz döner. Hata dönerse mutabakat kuyruğuna girer.
- 06 Mutabakat tamam (Mutabakat) Gönderilen paket, makbuz ve kaynak kayıt eşleşir; gönderim kapanır.
04 Tek seferlik gönderim adımından ayrılan yol; 04 Tek seferlik gönderim adımında ana akışa katılır.
- 04a Servis kesintisi: şifreli kuyruk (Gönderim) Bakanlık servisi yanıt vermez. Paket şifreli kuyrukta bekler; klinik kayıt etkilenmez ve kaybolmaz.
- 04b Yeniden deneme (Gönderim) Servis dönünce kuyruk sırayla yeniden denenir; tek seferlik anahtar çift kaydı engeller.
05 Makbuz (receipt) adımından ayrılan yol; 04 Tek seferlik gönderim adımında ana akışa katılır.
- 05a Hata kodu (Bakanlık servisi) Servis paketi bir hata koduyla reddeder (ör. eksik ya da geçersiz alan). Gönderim başarısız sayılır.
- 05b Ölü kuyruk (dead-letter) (Gönderim) Otomatik denemeyle düzelmeyecek paket ölü kuyruğa alınır; kaybolmaz, insan müdahalesini bekler.
- 05c Mutabakat kuyruğu (Mutabakat) Yetkili kullanıcı hata kodunu ve düzeltilecek alanı görür, kaydı düzeltir.
- 05d Yeniden gönderim (replay) (Gönderim) Düzeltilen paket yinelenmeden yeniden gönderilir ve makbuz beklenir.
01 Klinik olay adımından ayrılan yol; 02 Sürümlü eşleme adımında ana akışa katılır.
- 01a Düzeltme veya iptal (Klinik kayıt) Klinik kayıt sonradan düzeltilir ya da iptal edilirse, kaynak değiştirilmez; sürüm ve iptal zinciri olarak yeni bir gönderim hazırlanır.
06 Mutabakat tamam
Veri gönderimi pratikte nasıl çalışır?
Kayıtlı bir yazılımın ulusal veri gönderimi şu mantıkla işler:
- Klinik olay. İmzalanmış bir muayene ya da işlem kaydı, gönderime konu bir olay oluşturur.
- Eşleme. Kaydın alanları, Bakanlığın yayımladığı sürümlü veri tanımlarına ve kodlarına eşlenir. Veri tanımları değişince eşleme de güncellenir.
- Paketleme. Gönderilecek veri paketi oluşturulur ve hangi kayda dayandığı izlenebilir biçimde saklanır.
- Gönderim. Paket servise iletilir. Aynı paketin tekrar gönderilmesi yinelenen kayıt oluşturmamalıdır.
- Alındı bilgisi (receipt). Servis kabul ettiğinde alındı bilgisi döner ve kayda bağlanır.
- Mutabakat. Klinikteki kayıt ile gönderilen kayıt karşılaştırılır; eksik ya da reddedilen gönderiler bir kuyrukta kullanıcıya çözülmek üzere sunulur.
Servis geçici olarak kullanılamıyorsa, gönderim kuyrukta bekler, yeniden denenir ve sonunda başarısız olursa kullanıcıya görünür bir duruma düşer. Bu mantık HekimBis'te USS veri gönderimi özelliğinde tarif edilir; entegrasyon yaklaşımı ise e-Nabız ve USS entegrasyonu sayfasında yer alır.
Kayıt, e-Reçete ve diğer ulusal süreçler: karıştırmayın
KTS kaydı ve veri gönderimi; e-Reçete, e-Rapor, SGK süreçleri ve e-Belge ile aynı kapsamda ele alınmaz. Her birinin ayrı bir uyum gereksinimi ve test süreci vardır. HekimBis zorunlu asgari USS/e-Nabız veri gönderimini sürümlü eşleme, gönderim ve mutabakat kuyruğuyla yürütür. e-Reçete konusu için e-Reçete rehberimize bakın.
Sık karşılaşılan yanlış anlamalar
"KTS kaydı olan yazılım bütün yükümlülükleri karşılar." Hayır. Kayıt, yazılımın belirli teknik ve güvenlik gereksinimlerini karşıladığını gösterir; kliniğin kendi yükümlülükleri (aydınlatma, yetki yönetimi, doğru kayıt tutma, çalışan eğitimi) devam eder. Yazılım bir araçtır; uyum, aracı kullanma biçiminizle birlikte oluşur.
"Bulut yazılımı KTS'ye kayıt olamaz." Kayıt, yazılımın dağıtım biçimine değil, kategorisine ve gereksinimlere bağlıdır. Bulut yazılımlarında ek olarak veri yeri, çok kiracılı mimarinin denetim kabulü ve alt hizmet sağlayıcıların değerlendirilmesi gibi sorular gündeme gelir. Bu soruların yazılı cevabı kayıt sürecinin parçasıdır.
"Veri gönderimi bir kez kuruluyor, sonra unutuluyor." Veri tanımları ve kodlama sürümleri zamanla değişir. Gönderim mantığı bu değişikliklere uyum sağlamazsa reddedilen gönderiler birikir. Yazılım sağlayıcısının mevzuat ve veri tanımı değişikliklerini izleyen bir sorumlusu ve bir acil uyarlama prosedürü olmalıdır.
"Gönderim başarısızsa hekimin yapacağı bir şey yok." Tersine, çözülebilir hataların çoğu (eksik kimlik bilgisi, boş zorunlu alan, geçersiz kod) kullanıcı düzeyinde düzeltilebilir. Bu nedenle mutabakat kuyruğunun anlaşılır hata mesajlarıyla kullanıcıya açık olması gerekir.
Kısa bir zaman çizelgesi: yeni açılan muayenehane
Yeni bir muayenehane açan hekim için yazılım ve kayıt tarafı şöyle ilerleyebilir:
- Faaliyet izni süreci. Kurumun kendi izin ve ruhsat işlemleri; bu, yazılımdan bağımsız ve ilk adımdır.
- Yazılım seçimi. Kayıtlı ve veri gönderimi yapabilen bir yazılımın seçimi; kayıt kanıtının talep edilmesi.
- Kurulum ve tanımlar. Hekim, hizmet, oda ve kullanıcı tanımları; kimlik doğrulama ve yetkilendirme ayarları.
- Deneme günü. Sentetik ya da test verisiyle bir günün oynanması; veri gönderiminin test ortamında doğrulanması.
- Üretime geçiş. Sözleşme, aktivasyon kapısı ve gerçek hasta verisinin girişi.
- İzleme. Gönderim kuyruğunun ve mutabakatın düzenli izlenmesi.
HekimBis'te deneme dönemi sentetik veriyle çalışır; gerçek hasta verisi ve canlı ulusal servis bağlantısı, üretim aktivasyonu tamamlandıktan sonra kullanılır. Böylece kayıt ve doğrulama adımları tamamlanmadan canlı sağlık verisine geçilmez. Adımlar nasıl çalışır sayfasında anlatılır.
Çok hekimli ve çok şubeli yapılarda ek konular
Poliklinik, tıp merkezi ya da çok şubeli bir yapıda veri gönderimi hekim, şube ve kuruluş kimliklerinin doğru eşlenmesini gerektirir. Bir hekim birden fazla şubede çalışıyorsa, gönderilen kaydın hangi şubeye ve hangi kuruma ait olduğu net olmalıdır. Şube bazlı operasyon ekranları, hangi şubenin gönderiminde birikme olduğunu görmeyi sağlar. Ayrıca, kuruluşun tüzel kişiliği, tesis ve şube yapısı Bakanlık kayıtlarıyla yazılımdaki yapının uyuşması gerekir; uyuşmazlık, gönderimin reddedilmesinin yaygın bir nedenidir. Bu konularda ekibinizde bir sorumlu belirleyin ve yazılım sağlayıcınızla yapı eşlemesini yazılı doğrulayın.
Satın almadan önce 10 soru
- Yazılım, benim kuruluş türüm için KTS'de kayıtlı mı? Kanıtı nedir?
- Kayıt aktif listede yer alıyor mu, hangi tarihte ve hangi sürümle?
- Zorunlu veri gönderimini yapıyor mu? Hangi veri paketleri için?
- Gönderim başarısız olursa ne oluyor? Yeniden gönderim yolu var mı?
- Alındı bilgisi (receipt) ve mutabakat kuyruğu gösterilebiliyor mu?
- Veri tanımları değiştiğinde kim güncelliyor, ne kadar sürede?
- Hasta verisi gönderim sırasında ve sonrasında nerede tutuluyor?
- Gönderim kayıtları ve hata günlükleri hassas veriyi açığa çıkarıyor mu?
- Sözleşmede kayıt durumu yazılı mı, kayıt kaybı halinde müşteriye hakkı ne?
- e-Reçete, e-Rapor, SGK gibi ayrı süreçlerin hangisinin yazılımın kapsamında olduğu açık ve yazılı mı?
Klinik tarafında hazırlık
Yazılım kayıtlı olsa bile, veri gönderiminin kalitesi kliniğin kayıt disiplinine bağlıdır. Eksik tanı kodu, boş zorunlu alan ya da yanlış kimlik bilgisi, gönderimin reddedilmesine yol açar. Bu nedenle: tanı ve işlem kodlarının kullanımı konusunda hekimleri bilgilendirin, zorunlu alanların boş bırakılmamasını sağlayın, reddedilen gönderilerin kuyruğunu düzenli izleyecek bir kişi belirleyin ve gönderim durumunu aylık gözden geçirin. Kuyruk yönetimi küçük bir iştir; ihmal edildiğinde büyük bir birikime dönüşür.
Sonuç
KTS, MBYS ve veri gönderimi, bir yazılımın "özelliği" değil, mevzuat ve doğrulama konusudur. Yazılım seçerken kategori, kayıt durumu, veri gönderimi, hata yönetimi ve kapsam sınırını yazılı olarak netleştirin; "başvuru yapıldı" ile "kayıtlı" arasındaki farkı hiçbir zaman göz ardı etmeyin. Muayenehane ölçeği için muayenehane yazılımı, çok hekimli yapılar için poliklinik yazılımı sayfalarındaki kapsam notlarına da bakabilirsiniz.




