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:
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.
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)
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
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
Yorum Gönder