Ana içeriğe atla

Medikal Yazılım Projesinde Verinin yÖNEtiMİ

Yoğun bakımda yatan bir hastanın medikal verilerini cihaz ve sensörlerden (IoT) alıp bu verileri ekranda görüntülemek ne kadar zor olabilir ki? Biraz IoT, biraz CRUD ve şöyle güzelinden bir şablondan oluşturulmuş bir web arayüzü ile proje çalışır hale getirilir. Gerçekten mi? Mesela yani!



Projede yaşadığımız ilk zorluk medikal cihazlardan veri almaktı. Hem Türkiye’de hem de diğer ülkelerde kullanılan çoğu medikal cihazlar eski ve üretimden kalkan cihazlar. Dolayısıyla üretici firmalar destek konusunda çok nazlılar. Yeni ve IoT özelliği olan medikal cihazların üreticileri ise lisans talep etmekte ya da şifreli iletişim gibi zorluklar çıkarabilmekteler. Siz de emin olun ki hangi sektör için çözüm geliştiriyorsanız o sektörün oyuncuları size zorluk çıkaracaklar!

İlk zorluk insanların (şirketlerin) tutumuydu. İkinci zorluk ise yine aynı sebepten ama biraz daha teknik bir konu: cihazların bağlantı seçenekleri. RJ45, WiFi, RS232, RS485 ve Bluetooth gibi birçok bağlantı seçeneklerine sahip cihazların yanında yalnızca SD karta veri kaydedebilen eski cihazlar ve sadece lisanslı yazılımı ile haberleşip yanağından makas bile aldırmayan nazlı cihazlarla çalıştık. Bağlantı seçeneklerinin çokluğu ekibimizi gerçekten zorladı. RFC dokümanlarının bağımlısı olduk.

TCP/IP ile haberleşebilmenin başlangıç, asekron ve paralel işlem yapabilen kodlarla çalışmanın kâbus olduğu bir projede ekibi motive edebilmek her şeyden daha zordu. Pandemi döneminde sağlık çalışanlarının işlerini kolaylaştırmak bizi motive etse de medikal verilerin eksiksiz ve hatasız görüntülenmesi sorumluluğu bizi strese soktu. Yanlış bir medikal veri nedeniyle yanlış uygulanacak bir tedavi, bir insanın hayatını olumsuz etkileyebilirdi.

Verinimetimiz olan veriyi yönetmek bu kâbusun devamı. Medikal bir verinin kesinlikle doğru olması gerekiyor. Eksik, eski, tekrarlanmış veya doğrulama yöntemlerinden geçemeyen verilerin sisteme girmemesi gerekiyor. Örneğin bir saniye önce vücut ısısı 36 °C iken birdenbire vücut ısısının 70 °C olması yanlış bir sensör okumasını gösterirken vücut ısısının 36 °C’den 38 °C’e çıkması normal mi diye araştırmaya başladık. Yaklaşık yüz çeşit veri türü için yanlış okumaları ve yanlış alarmları (false positive) önlemek amacıyla böyle bir çalışmaya girince latinceyi sökmeye başladık. Tabiki böyle olmadı! Makine öğrenmesi ile elimizdeki veri setleri sayesinde hangi veri türlerinin hangi aralıklarda değişebildiğini makinelerle beraber öğrendik.

Bonus bölüm:

Mevzuat gereği proje kullanıcı kaynaklarında (on premises) çalıştı. İşin teknik kısmını bir tarafa atalım gelelim on prem çalışan bir sistemde neler olabilir:
  • Sanal makineniz size haber verilmeden kapatılabilir veya silinebilir
  • Güvenlik duvarı ayarları bir gece ansızın değiştirilebilir
  • SSL sertifikaları biranda geçersiz olabilir
  • IoT cihazların fişleri çekilebilir
  • IoT cihazlara takılan kablolar nasıl yanlış takılabilecekse o şekilde yanlış takılabilir
  • Olur da bir cihaza reset atmak için bir tuşa basılması gerekiyorsa o tuşa basılması için birçok telefon araması yapmanız gerekebilir
  • Eğer bir cihazın düğmelerine basılmaması gerekiyorsa o düğmelere basılır
  • Endüstriyel olarak tasarlanmış fabrikada bile kırılmayan sensörler kargo esnasında kırılabilir
  • Kullanıcıya emanet ettiğiniz yedek donanım ve cihazlara ulaşmak için zimmet belgesi imzalamak zorunda kalabilirsiniz
  • Bozulan bir IoT cihazı zaten sahada bulunan yedek bir cihazla değiştirmek için (sadece iki tane kablo yuvasından çıkarılıp yeni cihaza takılacak) kilometrelerce uzağa personel göndermek gerekebilir. Çünkü bozulan cihazın yakınında bulunan müşterinin IT görevlileri sizin için parmağını kımıldatmayabilir
(bonus bölüm sonu)

Sensörlerden ve medikal IoT cihazlardan veri aldıktan sonraki adım bu veriyi merkeze iletmek. Ya merkezdeki sunucuya ulaşılamazsa, ya networkde bir gecikme veya paket kaybı olursa? Yedek sunucu ve yedek network ekleriz olur biter! Yok öyle dünya! Yedek uygulama sunucusu, yedek kuyruk sistemi (RabbitMQ gibi), yedek veri tabanı sunucusu, farklı ağdan sunucu ağına yedek ağ yolu gibi çözümler projenin kullanıcı kaynaklarında (on premises) çalışması nedeniyle uygulanabilir değildi. Bu nedenle tüm sistemin sağlıklı çalışması gerekiyordu. Eğer sistem sağlıklı çalışmıyorsa, sistemde yoğunluk varsa, sistemde gecikme varsa bundan haberdar olmalıydık ve kullanıcı arayüzünde eksik veya hatalı medikal veri göstermemeliydik. Bir sorun olduğunda o sorundan haberdar olmak yetersizdi, o sorunun tekrar etmemesi için sorunun kaynağını bulmalıydık.

Sıra geldi veriyi kaydetmeye. Sunucuya gelen veriyi kaydetmek ne kadar zor olabilir ki! IoT cihazlar ve sensörler bazen tekrarlı, eksik ve hatalı veri paketleri gönderiyordu. Gelen verinin doğrulamasını yaptıktan sonra kaydetmemiz ve kullanıcı ekranına göndermemiz gerekiyordu. Bunları yapmak için çok zaman yoktu. Hangi doktor EKG grafiğinde bir boşluk ister ki! Verinin kısa sürede işlenmesi ve kullanıma sunulması gerekiyordu. Milisaniyelerle olan savaşımızda sunucunun işlem yükünü azaltmak için bazı network paketlerini işleyebilen IoT cihazlar geliştirdik, çok da faydasını gördük. Projemize heyecan katan kendi IoT çözümlerimizin de (Raspberry Pi ve Arduino) kararlı ve sağlıklı çalışması gerekiyordu. Aldık mı başımıza bir tatlı bela daha!

Ana işimizden çok monitoring, logging ve tracing işlemleri zamanımızı aldı. Kullanıcılar için yardım masasını işletmek, bir gece yarısı oluşabilecek sistemsel sorunları halletmek için nöbet sistemini (incident management) oluşturmak derken ana odağımızı korumak zorlaştı. Eğer veri kritik ise yazılımcının işi zor.

Yoğun bakıma giren yazılımcı

En sonunda sağlıklı bir şekilde çalışan projemizi teslim ettik. Biz de isterdik makine öğrenmesi, yapay zekâ, veri madenciliği gibi konularda çalışalım. Şimdilik veri toplayıp işleyebilen bir ürün geliştirdik. İleride inşallah toplanan verilerle katma değer oluşturabilecek bir proje üzerinde çalışırız.

Teknik terim isteyenlere araştırmalık:
FreeRTOS
Software as a Medical Device
Data Distribution Service (DDS)
RTPS (Real-Time Publish-Subscribe Protocol)

Yorumlar

Bu blogdaki popüler yayınlar

Bir Uluslararası Yazılım Şirketinin Batış Hikayesi

 Güzel başlamıştı hikaye. Yazılımcılar mutlu, kullanıcılar memnundu. Sonra pandemi başladı. Sorun para değildi. Olmayan şey huzurdu… Durdurun hype trenini, inecek var kırık kalpler durağında  — Photo by Kelly Sikkema on  Unsplash Gerçek olamayacak kadar güzeldi çalışma ortamı. Yazılımcılara istedikleri eğitim ve donanım alınıyordu, personel arası hiyerarşik bir yapı yoktu, sorumluluğun yanında yetki de veriliyordu, esnek çalışma saatleri yazılımcılara göre esnekti, izin isteyen hiç kimse geri çevrilmiyordu, pandemiden önce bile uzaktan çalışma vardı. Ne oldu bu şirkete? Nazar mı değdi? Şirketin yazılım ürünü Türkiye’de doğmuştu. Ürün birçok ülkede hem kamu tarafından hem de özel sektör tarafından kullanılıyordu. Yazılım geliştirme ekipleri hem Türkiye’de hem de diğer ülkelerde bulunuyordu. Yazılımın argesi için gelen geri bildirimlerin çoğu Türkiye’den geliyordu. Yazılımın kalbi Türkiye’de atıyordu.  Koronavirüs pandemisi nedeniyle Türkiye’de kamu kuruluşları hizmet alımı ile aldıklar

Uluslararası Yazılım Firmasında Çalışmak

Türkiye merkezli 5 ülkede ofisi olan 50’den fazla mühendisi bulunan ve müşterileri hariç 8 farklı milliyetten kişiler bulunan bir yazılım firmasında yaklaşık 11 aydır çalışmaktayım. Bu süreç boyunca hem çalıştığım şirkette hem de iletişimde bulunduğum diğer uluslararası şirketlerde gözlemlediğim noktaları paylaşmak istedim. Buradaki görüşlerim tamamen kişiseldir ve firmadan firmaya değişebilir. Eleştiriyi önce en günahsız olanınız yapsın! Photo by Kyle Glenn on Unsplash İşe giriş ve mülakat süreçleri zor. İş ilanlarını mantıklı ve açıklayıcı olarak açılıyorlar. Öyle her şeyden anlayan süper yazılımcı aramıyorlar. Şirketin ihtiyacını göz önüne alarak ve her yazılımcının şirkette kullanılan teknolojileri bilemeyeceğini göz önüne alınarak iş ilanını açılıyor. Özgeçmişimde yazan her kelime ile ilgili sorguya çekildim. Başvurduğum pozisyon için gereken yeteneklerle ilgili zor sorular soruldu. Nasıl yaptılar bilmiyorum ama şirket kültürüne uyumumu ve iletişim yeteneğimi de ölçmüşler. Açık

Kamuda Yazılımcı Ol(ma)mak

Yazılımcı olarak 8 yıl kamuda, 2 yıl özel sektörde çalıştım. Bir yandan da freelance olarak çalıştım. Yurtdışındaki firmalarla da güzel yurdumun esnafıyla da çalıştım. En garip manzara bence kamudaki yazılım manzarası. Şu anda bir kamu kurumu için geliştirilen yazılım projesini yönetiyorum. Girdiğim toplantılarda, aldığım e-postalarda, yaptığım telefon konuşmalarında eski kamu anılarım depreşti. Kağıtların arasında hayalleri yıkılmış bir yazılımcı bulabilirsiniz Kamuda çalışırken hem benim hem de arkadaşlarımın başına gelen olaylardan ve şu anda kamuda çalışmaya devam eden tanıdıklarımdan aldığım bilgilerle, kamudaki yazılım dünyasını size sanayi diliyle aktarmaya çalışacağım. Bu yazı şahsi görüşlerimi içerir. Yine de kamuda 8 yılın yeterince objektif bir bakış açısı sunacağını düşünüyorum. Kamuya yazılım projesi geliştirirken karşılaşabileceğiniz durumlar: Bir kamu kurumu ile görüşmeye başlamak için bağlantı gerekir. Kamu kurumuna “sizin şöyle bir ihtiyacınız var ben bunu çözen yazılı