Sorunun Tarihi
IoMT (Tıbbi Nesnelerin İnterneti) cihazlarının çoğalması kalite güvencesini işlevsel doğrulama yönteminden hasta güvenliği kritik doğrulamaya kaydırdı. BLE 5.0+ protokolleri genişletilmiş reklam ve 2M PHY desteği getirdi, ancak iOS ve Android arka plan yürütme politikaları birbirinden farklılık göstererek bağlantı manzarasını parçalamaktadır. Tarihsel olarak, tıbbi periferiklerin manuel testi ön planda eşleştirme ile sınırlandırılmıştır; ancak gerçek dünya kullanımı, cihaz kilit durumları ve eşzamanlı uygulama kullanımı sırasında kesintisiz izleme gerektirmektedir.
Sorun
Temel zorluk, mobil işletim sisteminin pili muhafaza etmek için arka plan süreçlerini agresif bir şekilde kısıtlaması nedeniyle GATT (Generic Attribute Profile) sunucusu (sensör) tarafından kontrol edilen BLE bağlantı aralıklarının belirsiz doğasında yatmaktadır. Mobil ana bilgisayar ile tıbbi cihaz arasındaki MTU uyuşmazlıkları, glikoz trend verisi paketlerinin sessizce kesilmesine neden olarak tehlikeli dozaj kararlarına yol açabilir. Ayrıca, düzenleyici çerçeveler, sensör kesintileri için değiştirilemez denetim izleri gerektirirken, çoğu RTOS tabanlı tıbbi cihazlar, sinyal kaybı sırasında gönderilmeyen okumaları tamponlamak için depolama kapasitesine sıklıkla sahip değildir; bu da teknik işlevsellik ile uyumluluk gereksinimleri arasında bir doğrulama boşluğu oluşturur.
Çözüm
Bağlantı yaşam döngüsü doğrulama için durum geçiş testi, 2.4 GHz aralığının sınırındaki RSSI (Received Signal Strength Indicator) eşik değerleri için sınır değer analizi ve elektromanyetik parazit senaryoları için keşif oturum bazlı test gibi sistematik risk tabanlı manuel test metodolojisi uygulanması. Bu, vücut engelleyici zayıflamayı simüle etmek için Faraday kafesi koruması ile yapılan scriptli kaos mühendisliği testlerini içerir ve iOS Arka Plan Uygulama Yenilemesi askıya alma olayları sırasında hiçbir PDU (Protocol Data Units) düşmediğini doğrulamak için nRF Sniffer veya Ellisys donanımı kullanılarak paketlerin izlenmesini sağlar. Uyum doğrulaması, ömürü dolmuş sensör uyarılarının HIPAA-uyumlu yerel bildirimleri ve CR2032 pilinin düşük voltaj kilidi girmeden önce değiştirilemez günlüğe girişleri tetikleyip tetiklemediğini doğrulamayı gerektirir.
FDA 510(k) başvurusuna hazırlık için ayrılan bir sprint sırasında, ekibimiz, 12% beta kullanıcıların tam olarak 60 dakikalık iOS arka plan çalışmasında veri boşlukları yaşadığını keşfetti. Sensör iletmeye devam etti, ancak React Native köprüsü BluetoothManager线程ini askıya aldı ve hızlı düşük glikoz olayları için onaylanmamış uyarılara neden oldu ve bu da ciddi hasta riskleri oluşturdu.
Kök nedeni izole etmek için üç farklı test yaklaşımını değerlendirdik.
İlk yaklaşım, BLE reklamlarını simüle etmek için mevcut otomatik Appium test suite'mizi genişletmekti ve bir Raspberry Pi 4'ü periferik taklit olarak kullanarak. Bu, tekrar eden sinyal gücü ve öngörülebilir bağlantı kesilme zamanlaması sağladı, böylece birden fazla iOS sürümü boyunca hızlı regresyon testleri yapılabildi. Ancak, CoreBluetooth çerçevesi, fiziksel Texas Instruments CC2640R2F yongaları ile sanal periferalar arasında farklı davranış sergiliyor; özellikle LL (Link Layer) bağlantı parametre güncellemeleri konusunda; arka plan askıya alım hatasını yeniden üretemedik, bu da bu yaklaşımı güvenlik kritik sertifikasyon için yetersiz hale getirdi.
İkinci yaklaşım, 2.4 GHz Wi-Fi parazitleşmesini ortadan kaldırmak için korumalı anechoik odalarda kontrol edilen bir laboratuvar ortamında kapsamlı manuel test yapmayı öneriyordu. Bu, mükemmel RSSI okumaları sağladı ve 100 metre maksimum teorik aralığı doğruladı, ancak gerçek dünya vücut gölgeleme etkilerini ve hastane ortamlarındaki 802.11 kablosuz ağlarla olan birlikte varoluşu hesaba katmadı. Mükemmel ortam, yüksek yoğunluklu elektromanyetik ortamlarda, commuter trenleri gibi, Android JobScheduler ve BLE tarama geri dönüş çağrıları arasındaki zamanlama ile ilgili yarış koşullarını gizledi.
Nihayetinde, scriptli kaos mühendisliği ile düzenleyici izlenebilirliği birleştiren bir hibrit alan testi metodolojisini seçtik. Testçiler, tipik kullanıcı yolculukları boyunca üretim sensörleri ile eşleştirilmiş iPhone 12 ve Samsung Galaxy S21 cihazlarını taşıdılar: metro yolculukları (tünel sinyal kaybı), diğer metal nesnelerle ceplerde (çoklu yol zayıflaması) ve eş zamanlı Zoom görüşmeleri (CPU kısıtlaması). Gerçek zamanlı GATT özellik denetimi için LightBlue Explorer ve hava paketlerini yakalamak için Wireshark ile Nordic Semiconductor sniffer'ları kullandık. Bu yaklaşım, iOS 14.5+ arka planda çalışırken MTU müzakeresinin 185 byte'ı aşması durumunda uygulamamızın askıya alındığını tespit etti, bu da simüle edilmiş ortamlarda tespit edilmesi imkansız bir senaryoydu. Arka plan yürütmesini gösteren UIApplication.shared.applicationState değeriyle 23 byte ATT varsayılan MTU boyutuna geri dönüş gerçekleştirdik, veri kaybını çözdük ve başarılı bir şekilde TÜV SÜD tıbbi cihaz denetimini geçtik.
Bir kullanıcı akıllı telefonunu yükselttiğinde, bir BLE tıbbi cihazının bağlanma bilgilerini doğru bir şekilde nasıl elinde tuttuğunu doğruluyorsunuz?
Birçok aday, Bluetooth eşleştirme penceresine odaklanırken, iOS Anahtarı veya Android Anahtarı LTK (Long Term Key) değerlerinin sürekliliğini göz ardı ediyor. Doğru metodoloji, DFU (Device Firmware Update) gerçekleştirirken, aynı anda bir telefon geçişini iTunes şifreli yedekleme geri yüklemesi ile simüle etmeyi içerir. Testçiler, CGM sensörünün GAP (Generic Access Profile) reklam verilerindeki Bonding bayraklarının tutarlı kalmasını doğrulamalıdır, böylece yeniden eşleştirmenin bir Service Changed bildirimini tetiklemesini ve tam bir yeniden kalibrasyon sürecini değil. Bu, Xcode Packet Logger kullanarak periferalin daha önce bağlanmış ana bilgisayarı, yeni bir MAC adresi rastgeleleştirme planına rağmen tanıdığını doğrulamak için IRK (Identity Resolving Key) çözümleme sürecini denetlemeyi gerektirir.
Sensör arızası anında (hata durumu 0x06: Sensör Ömrü Doldu) glikoz değeri iletimine yönelik sistematik yaklaşım nedir?
Acemi testçiler genellikle sürekli akışın olumlu yolunu doğrularken, Durum Makinesi geçiş validasyonunu göz ardı ediyor. Doğru yaklaşım, BLE periferik üzerindeki RTC (Real-Time Clock) hızlandırarak sensör süresini dolmuş hale getirmeyi içerir, bu, üretici hata ayıklama komutları veya süresi dolmuş test sensörleri kullanılarak yapılabilir. Testçiler, son Glucose Measurement karakteristik bildirimlerinin Zaman Offset alanının sona erme zaman damgasına ayarlandığını, hemen ardından veritabanı sıfırlama belirtimi olan Record Access Control Point (RACP) bildirimini ilettiklerini doğrulamalıdır. Kritik olarak, mobil uygulamanın bu son okuma değerini Core Data veya SQLite'a, Disconnect olayından önce 0x08 (Connection Timeout) neden koduyla kaydettiğini doğrulamak gerekir; böylece sona erdikten sonra hiç "hayalet" okumaların görünmemesi sağlanır, bu da yanlış insülin dozlama hesaplamalarına neden olabilecektir.
Mobil uygulamanın sensörün iç saatinin ve telefonun duvar saatindeki zamanın yaz saati uygulaması geçişleri boyunca zaman senkronizasyonu doğruluğunu nasıl sağlıyorsunuz?
Bu zamansal sınır koşulu, tıbbi cihaz testi sırasında sıkça göz ardı edilmektedir. Adaylar, iOS NSDate veya Android System.currentTimeMillis() değerini yaz saati uygulaması değişikliği sabahı 01:59'a manuel olarak ayarlayarak testi gerçekleştirmelidir, ardından bir sensör oturumu başlatmalıdır. Testçi, geçmiş veri alma istekleri için E2E (End-to-End) CRC (Cyclic Redundancy Check) doğrulamasının geçip geçmediğini ve CGM trend grafiğinin kaybolan veya tekrar eden saati açık vermeden görselleştirdiğini doğrulamalıdır; zira bu durum diyabetik hastaların glikoz eğilimleri hakkında yanlış yönlendirilebilir.