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

Türkiye'de Yazılım Şirketi Açmak ve Çıldırmamak

Aklında bir fikir vardı. Piyasada bunu karşılayan yazılımlar vardı ama hepsi eksikti. Hayalindeki yazılım ürününe hiçbiri yaklaşamıyordu. Gördüğü kadarıyla piyasanın böyle bir ürüne ihtiyacı vardı. Kullanıcılar mevcut ürünlerden şikayetçiydi. Kendi ekibini toplayıp hayalindeki şirketi kurmaya niyetlendi. Rüzgarlara dikkat!- Francesco Ungaro -  Pexels İşinden istifa etmeden önce piyasa araştırmasını yaptı, rakip ürünleri inceledi. En önemlisi ekibini kurdu. Ürününün MVP hali için çalışmaları başlattı. Girişim kurmak ile ilgili birçok kitap ve blog okudu, podcastler dinledi. Girişimci birkaç kişinin çayını kahvesini içti. Öngörebildiği her şey için önlemini aldı ve istifa edip kendi yazılım şirketini kurdu. Şirket kurmak için gerekli süreçler düşündüğünden daha kolay geçti. Şirketin adı ve logosu zaten hazırdı. Şirket teknoparkta yerini almıştı. Kendisi etiketlere çok önem vermiyordu ama yine de LinkedIn’deki profiline “Founder of the …” ibaresini ekledi. MVP’nin ortaya çıkması hedefini

Yazılımcılar İçin Yan Proje Oluşturma Rehberi

İster hobi amaçlı olsun ister maddi amaçlı her yazılımcının bir yan projesi olmalıdır. Peki yan proje oluştururken nelere dikkat edilmelidir, nasıl bir yan projemiz olmalıdır? Organize olalım beyler Yan proje (side project) için öncelikle bir fikir bulmak gerekli. Bu projenin amacı ne olacak? Hangi ihtiyacı çözecek? Yeni bir fikir mi olacak yoksa mevcut bir fikrin daha iyi uygulanmış bir hali mi olacak? Sadece yeni bir teknolojiyi öğrenmek için mi? Deneysel mi olacak ya da eğlenceli mi? Yoksa maddi bir getirisi olacak mı? Bu proje ürün olursa kimler kullanacak? Ürünü kullanacak kişilere erişip geri bildirim alabilecek miyim? . . . Bu soruların doğru bir cevabı yok, cevaplar size bağlı. Ama proje bir amaca hizmet edip bir ihtiyacı çözecekse, hele birde maddi getirisi olacaksa motivasyonunuz yükselecektir. Bunun yanında sadece eğlence amaçlı olan deneysel bir proje yapmak stressiz bir öğrenme ortamı sağlayacaktır. Gün içinde proje için aklınıza gelen her şeyi not alın. Not almazsan