Sağlık bilişiminde projelerin zamanını modüller değil entegrasyonlar yer. Devlet servisleri ve cihaz bağlantılarında maliyetin nerede saklandığı.
Geciken hep aynı yer
Hastane bilgi yönetim sistemi projelerinde takvimi sarkıtan şey neredeyse hiçbir zaman modüllerin kendisi olmuyor.
Poliklinik ekranı, yatış süreci, eczane stoğu — bunlar tanımlı işlerdir, süresi kestirilebilir. Projeyi geciktiren yer, o modüllerin dışarıyla konuştuğu noktalardır: devlet servisleri, laboratuvar cihazları, radyoloji sistemleri, muhasebe tarafı.
Bunu birkaç projede yaşadıktan sonra tahmin yöntemimi değiştirdim: modülleri değil, bağlantı noktalarını saymaya başladım.
Entegrasyon bir bağlantı değil, bir sözleşmedir
Bir servise bağlanmak teknik olarak yarım günlük iştir. Asıl iş, o servisin kurallarını öğrenmektir: hangi alan zorunlu, hangi durumda hata döner, hata dönerse süreç nerede devam eder.
Bu kuralların çoğu belgede yazmaz. Sahada öğrenilir ve genellikle canlıya geçtikten sonra öğrenilir. Bir alanın belgede “opsiyonel” yazıp pratikte zorunlu olması, benim en sık karşılaştığım sürprizdir.
İkinci sürpriz zamanlamadır: test ortamı çalışır, canlı ortam farklı davranır. Bu yüzden artık her entegrasyon için takvime canlı ortamda doğrulama adı altında ayrı bir kalem yazıyorum.
Cihaz entegrasyonları apayrı bir dünya
Yazılım-yazılım entegrasyonu tahmin edilebilir. Cihaz entegrasyonu değil. Laboratuvar ve görüntüleme cihazları çoğu zaman kendi yaşlarının teknolojisini konuşur; bazıları seri port, bazıları eski bir dosya paylaşımı, bazıları da hiç belgelenmemiş bir formatla veri üretir.
Burada karşılaştığım en pahalı durum şuydu: cihaz sonucu üretiyor ama hangi hastaya ait olduğunu yazılım tarafının anlayabileceği biçimde vermiyor. Bu tek sorun, birkaç haftalık bir eşleştirme çalışmasına dönüşebiliyor.
Görünmeyen maliyet kalemleri
| Kalem | Neden teklifte görünmez |
|---|---|
| Kural keşfi | Belgede yazmayan davranışlar sonradan çıkar |
| Hata senaryoları | Mutlu yol test edilir, hata yolu üretimde bulunur |
| Karşı taraf beklemesi | Yetki, erişim ve test hesabı süreçleri size bağlı değildir |
| Veri temizliği | Eski kayıtların yeni kurala uymaması |
| Sürüm değişikliği | Karşı servis güncellenir, entegrasyon bozulur |
Son satır özellikle önemli: entegrasyon bir kez yazılıp bitmiyor, bakımı olan bir varlık hâline geliyor. Projeyi teslim ettiğinizde iş bitmiyor.
Teklif verirken sorduğum sorular
Artık bir HBYS projesine bakarken önce şu üç soruyu soruyorum: kaç dış sistemle konuşacak, bu sistemlerin belgeleri var mı, ve karşı taraf bir test ortamı sağlayacak mı?
Üçüncü sorunun cevabı “hayır” ise takvimin üstüne ciddi bir pay ekliyorum. Test ortamı olmayan bir entegrasyon, canlı sistemde denenerek geliştirilir — ve sağlıkta canlı sistemde deneme yapmanın bedeli hep yüksektir.
Öğrendiğim en net ders şu: bir HBYS projesinin gerçek boyutu, modül listesinde değil entegrasyon listesinde yazar.
Bu üç sorunun yanına dördüncüyü de eklemeyi öğrendim: karşı tarafta bu işi kim yapacak? Entegrasyonun teknik zorluğu kadar, karşı kurumdaki muhatabın erişilebilirliği de takvimi belirliyor. Tek bir kişinin bilgisine bağlı bir servis, o kişi izne çıktığında projeyi durdurabiliyor.
Bir başka öğrendiğim şey, entegrasyonları en başa almak. Ekipler genellikle önce görünen işi — ekranları — yapmak ister; çünkü ilerleme oradan görünür. Ama entegrasyonu sona bırakan her proje, sürprizle sonunda karşılaşıyor ve düzeltmek için zaman kalmıyor. Ben artık en riskli entegrasyonu ilk haftalarda, basit bir denemeyle test ediyorum.
Bu deneme çoğu zaman tam bir çözüm olmuyor; sadece “bağlanabiliyor muyuz, hangi alanlar geliyor, hata nasıl dönüyor” sorularını cevaplıyor. Bir haftalık bu çalışma, ilerleyen aylarda haftalar kazandırıyor. Riski erken görmek, riski küçültmenin en ucuz yolu.
Bir konuda daha net fikrim var: entegrasyon maliyetini tekliften saklamak, kimseye iyilik etmiyor. Düşük tutulmuş bir kalem, proje ortasında değişiklik talebi olarak geri geliyor ve o noktada hem güven hem takvim zedeleniyor. Kalemi baştan yazmak zor bir konuşma; ortada yaşamak ise çok daha zor.
Son olarak, entegrasyon işini yapan kişinin sahayı görmesi gerektiğini düşünüyorum. Bir laboratuvar cihazının sonucu nasıl ürettiğini ekranın başında değil, cihazın yanında anlıyorsunuz. Bir hemşirenin hangi alanı neden boş bıraktığını da poliklinikte on dakika durarak öğreniyorsunuz.
Uzaktan yazılan entegrasyonların çoğu teknik olarak doğru, pratikte kullanışsız oluyor. Sahayı gören biri, belgede yazmayan ama işin yürümesi için kritik olan ayrıntıyı yakalıyor. Bu yüzden bu tür projelerde geçirilen ilk günü hep sahada geçirmeye çalışıyorum.
Daha fazlası: Sağlıkta veriyle çalışan sistemlerin arkasındaki modelleri anlattığım videoda konunun teknik tarafına giriyorum.
Videoyu sitemizde izle · YouTube'da aç · Bapati kanalına abone ol