Üç Hafta Boyunca Kimsenin Fark Etmediği Hastane Faturalandırma Hatası

Giriş

Geçen bahar, Orta Batı'daki bir bölgesel hastane sistemi, olağan değişiklik süreci kapsamında bir planlama yaması uyguladı. Önemli bir şey değildi — taburculuk saatlerinin faturalandırma modülüyle senkronize edilmesine yönelik rutin bir güncellemeydi. Üç hafta sonra, alacak hesapları departmanından biri, zaman damgalarının uyuşmaması nedeniyle reddedilen bir dizi talebi fark etti. BT ekibi sorunun kaynağını tespit ettiğinde, bu düzeltmenin dört yüzden fazla hastanın sigorta başvurularını etkilediği ortaya çıktı. Aslında kimse yanlış bir şey yapmamıştı. Güncelleme, kontrol listesindeki tüm testleri geçmişti. Sadece doğru kontrol listesi değildi.

Bu hikaye aklımda kalıyor çünkü aslında hastanelerle ilgili değil. Bu hikaye, bir kuruluşun arka planında sessizce çalışan sistemlerin, düzenli denetime ihtiyaç duyan canlı bir altyapı yerine bitmiş ürünlermiş gibi ele alındığında neler olabileceğini anlatıyor.

İki yıl önce kurduğunuz otomasyon, sandığınız gibi bir otomasyon değildir

Çoğu şirket, ilk iş akışı otomasyonlarını belirli ve göze çarpan bir sorunu çözmek için oluşturur. Bir İK ekibi, yıllık izin taleplerini manuel olarak yönlendirmekten bıkar. Bir satış operasyonları çalışanı, satış temsilcilerinin en kolay işleri seçmesini önlemek için potansiyel müşteri atamalarını otomatikleştirir. Bunlar, Power Automate’e benzer otomasyon araçlarıyla oluşturulur — yapılandırması hızlıdır, sorumluluğunu üstlenmek isteyen herhangi birine devredilmesi kolaydır ve çalışmaya başladıklarında büyük ölçüde görünmez hale gelirler.

Sorun şu ki, “çalışmaya başladıklarında” bu durum kalıcı hale gelir. Kimse bir gözden geçirme planlamaz. Otomasyonu kuran kişi başka bir ekibe geçer veya şirketten ayrılır. Bu arada iş dünyası otomasyonun etrafında değişir — yeni CRM alanları, farklı bir onay hiyerarşisi, yarı yük için tasarlanmış bir sistemden geçen hacmi ikiye katlayan bir birleşme. Otomasyon tam olarak tasarlandığı gibi çalışmaya devam eder ve asıl sorun da budur. Artık tam olarak o şekilde var olmayan bir şirket için tasarlanmıştır.

Bir lojistik firmasının, bir tedarikçinin API alan adını değiştirmesi nedeniyle otomatik istisna yönlendirme akışının on bir aydır fark edilmeden hatalı çalıştığını keşfettiğine şahit oldum. Çözüm ne miydi? Birisi, bunun tek seferlik bir durum olduğunu varsayarak, kimseye haber vermeden hatalı vakaları manuel olarak yeniden giriyordu. Bu bir araç hatası değil. Herkesin istikrarlı olduğunu varsaydığı bir şeyi yeniden gözden geçirmekteki kurumsal bir başarısızlıktır.

Hastaneler de aynı riski taşıyor, ancak riskin bedeli çok daha yüksek

Aynı örneği bir hastanenin klinik ve idari sistemlerine uyguladığımızda, hata payı sıfıra iner. Hastane yazılım geliştirme süreçleri, genellikle uyarlanabilirlikten ziyade uyumluluk ve kesintisiz çalışmaya öncelik vermiştir — bu anlaşılabilir bir durumdur, zira başarısız bir dağıtım, bir hemşirenin sabah saat 2’de ilaç geçmişini görüntüleyememesi anlamına gelebilir. Ancak bu aynı ihtiyatlılık, eski sistemlerin genellikle olması gerekenden çok daha uzun süre üretimde kalmasına ve yeniden inşa edilmek yerine yamalarla düzeltilmesine neden olur; çünkü kimse, sistemin işleyişini sağlayan bir şeyi bozan kişi olmak istemez.

Sonuçta, kimsenin aldığını hatırlamadığı kararların biriktiği bir mimari ortaya çıkar. Bir randevu modülü, hastanenin 2019’da kullanmayı bıraktığı bir tedarikçi için 2016’da oluşturulan bir entegrasyon aracılığıyla faturalandırma sistemiyle iletişim kurar. Çoğunlukla hâlâ çalışır. Ancak “çoğunlukla” kelimesi, hasta verilerinin yanında kullanılmasını isteyeceğiniz bir kelime değildir.

Yavaş yavaş değişen şey ise, sağlık hizmetleri BT’sinde dayanıklılığın değişimden kaçınmakla ilgili olmadığı, her düzenleme değişikliğinde veya yeni bir EHR modülünün eklenmesinde küçük bir mucizeye ihtiyaç duymadan değişimi absorbe edebilecek kadar esnek sistemler kurmakla ilgili olduğunun farkına varılmasıdır.

Neden “bozuk değilse” yanlış bir testtir?

Her iki senaryoda da durum şudur: sistemler bozuk değildi. Tam olarak yapılandırıldıkları gibi çalışıyorlardı. İşte tam da bu yüzden kimse onlara bakmadı.

Bozuk sistemler, tanımı gereği dikkat çeker — biri şikayet eder, bir şey durur, bir bilet açılır. Tehlikeli sistemler ise, yüzeysel olarak sorunsuz çalışırken, kuruluşun gerçek ihtiyaçlarından sessizce uzaklaşan sistemlerdir. Hala çalışır durumda olan ancak yanlış departmana yönlendiren bir iş akışı otomasyonu. Hala veri ileten ancak artık bir alt sistemin bağlı olduğu bir alanı çıkaran bir hastane arayüzü.

Denetim göz alıcı bir iş değildir, ancak alternatifi de öyle değildir

Çözüm, uygulamada sıkıcı olsa da kavram olarak karmaşık değildir: geçmişte ne kadar iyi performans göstermiş olursa olsun, gözetimsiz çalışan her şeyin periyodik olarak gözden geçirilmesini planlayın. Şu anda kimin sorumlu olduğunu sorun. Oluşturulduğundan bu yana yukarı ve aşağı akışta neler değiştiğini sorun. Yarın sessizce çalışmayı durdursa kimse fark eder mi diye sorun.

Çoğu kuruluş bunu atlar çünkü bu, ilerleme değil bakım gibi algılanır ve bakım nadiren bütçe veya takdir alır. Ancak bunu atlamanın bedeli ortadan kalkmaz — sadece, alacak hesapları departmanından birinin rakamların tutmadığını fark edeceği anı sessizce bekler.