Uzaktan Sağlık ve Ölçüm Platformu

Problem

Bir sağlık uygulamasında Bluetooth desteği, yakındaki bir cihazı bulup “bağlan” demekten ibaret değil. Tansiyon aleti, şeker ölçüm cihazı, oksimetre, tartı, termometre ve EKG gibi cihazların her biri farklı biçimde yayın yapıyor; farklı servisler sunuyor ve farklı eşleştirme adımları bekliyor.

Üstelik aynı kullanıcı birden fazla cihaz kullanabiliyor. Uygulama açıldığında kayıtlı cihazların hangisinin yakında olduğunu bulmalı, uygun olanlara yeniden bağlanmalı ve her cihazdan gelen ölçümü doğru sağlık verisiyle eşleştirmeli. Bütün bunlar, Bluetooth ve konum izinlerinin işletim sistemine göre değiştiği bir ortamda gerçekleşiyor.

Buradaki hedef yalnızca çok sayıda modeli desteklemek değildi. Yeni bir cihaz eklemeyi mevcut cihazların davranışını riske atmayan, kullanıcıdan da Bluetooth bilgisi beklemeyen bir sisteme dönüştürmekti.

Bağlam ve kısıtlar

Tek Flutter kod tabanı üzerinden iOS ve Android uygulamaları geliştiriliyor.
Ürün; görüşme, sağlık kaydı, reçete, semptom takibi ve cihaz ölçümü gibi birçok bağımsız alanı aynı uygulamada bir araya getiriyor.
Kullanıcıların önemli bir bölümü teknik değil. Servis UUID’si, bağlantı modu veya eşleştirme türü gibi ayrıntılar kullanıcı deneyimine sızmamalı.
BLE bağlantısı doğası gereği kesintili. Cihazın kapalı, uzakta, başka telefona bağlı ya da henüz ölçüm moduna alınmamış olması olağan durumlar.
Bazı cihazlar sistem seviyesinde PIN isterken bazıları ek işlem olmadan bağlanıyor; bazılarıysa bağlantıdan sonra ayrıca bir veri şifreleme anahtarı istiyor.

Rolüm

Flutter takım lideri olarak modüler mimarinin sınırlarını, ortak cihaz bağlantı katmanını ve yeni cihazların sisteme nasıl ekleneceğini tanımladım. Üretici protokollerinin uygulanması, eşleştirme akışları, hata senaryoları, kod incelemeleri ve ekip içi teknik standartlar da sorumluluk alanımdaydı.

Çoklu cihaz mimarisi

Sistemin merkezinde büyük bir switch bloğu bulunmuyor. Her cihaz tipi kendi yeteneklerini ve davranışını taşıyan bir fabrika üzerinden kaydediliyor. Bu fabrika; cihazın tarama sonucunda nasıl tanınacağını, hangi eşleştirme ekranını kullanacağını, ölçüm verisini hangi bileşenin işleyeceğini ve otomatik bağlantıyı destekleyip desteklemediğini sisteme bildiriyor.

Bağlantı, veri işleme ve arayüz sorumlulukları birbirinden ayrılıyor:

Cihaz kataloğu → Arama ve eşleştirme → Bağlantı koordinasyonu → Cihaza özel protokol → Sağlık verisi

Ortak repository katmanı tarama, bağlanma, bağlantıyı kesme ve bağlantı durumunu izleme işlerini tek sözleşme altında topluyor. Üreticiye özel veri kaynakları ise servis keşfi, characteristic seçimi, byte çözümleme ve ölçüm protokolü gibi gerçekten farklı olan ayrıntıları sahipleniyor. Bağlantı durumu cihaz kimliğine göre tutulduğu için bir cihazdaki değişiklik diğer cihazın oturumunu ezmiyor.

Bu ayrım sayesinde yeni bir model eklemek; ortak akışı değiştirmek yerine yeni bir cihaz adaptörü ve onun fabrika kaydını eklemek anlamına geliyor.

Kapsamlı cihaz arama

Arama başlamadan önce Bluetooth adaptörü, platform izinleri ve Android’de gerekli konum koşulları kontrol ediliyor. İzin verilmemişse boş bir cihaz listesi göstermek yerine kullanıcı doğru aksiyona yönlendiriliyor.

Tarama sonuçları yalnızca cihaz adına göre filtrelenmiyor. Modele bağlı olarak yayın adı, üretici verisi, servis bilgisi ve daha önce kaydedilmiş cihaz kimliği birlikte değerlendirilebiliyor. Böylece çevredeki tüm BLE cihazlarını kullanıcıya gösterip doğru cihazı seçmesini beklemek yerine, yalnızca seçilen medikal cihaz ailesine uyan sonuçlar listeleniyor. Daha önce eşleştirilmiş cihazlar da yeni cihaz listesinden çıkarılıyor.

Kayıtlı tek bir cihaz yeniden aranıyorsa tarama doğrudan onun kimliğine daraltılıyor. Birden fazla kayıtlı cihaz içinse her cihaz adına ayrı tarama başlatmak yerine kimliklerin tamamı tek tarama isteğine veriliyor. Sonuç geldiğinde cihaz kimliği kendi cihaz tipiyle eşleştiriliyor; bulunan her cihaz yalnızca bir kez bağlantı akışına alınıyor ve tüm hedefler bulunduğunda tarama durduruluyor. Bu yaklaşım hem yarış durumlarını hem de gereksiz tarama maliyetini azaltıyor.

Eşleştirme: şifre isteyen ve istemeyen cihazlar

Bağlantı kurulduktan sonra cihazın kendi eşleştirme politikası çalıştırılıyor. Ek doğrulama istemeyen cihazlarda ortak akış doğrudan başarılı sayılıyor. Servis keşfi, bildirim açma veya karakteristik okuma gerektiren modeller ise bu adımları kendi adaptöründe tamamlıyor.

Sistem seviyesinde güvenli eşleştirme isteyen cihazlarda Android bond durumu izleniyor; iOS ve Android’in gösterdiği PIN ekranı işletim sistemine bırakılıyor. Kullanıcı yanlış kod girdiğinde platformlar aynı hatayı üretmediği için sonuç hata koduna değil, eşleştirmenin gerçekten tamamlanıp tamamlanmadığına göre değerlendiriliyor. Bağlantının kritik anda düşmesi halinde kısa bir gecikmeden sonra kontrollü bir ikinci deneme yapılabiliyor; başarısızlık sürerse kullanıcıya yeniden deneme yolu sunuluyor.

Bazı cihazlarda PIN ile Bluetooth eşleştirmesi yeterli değil. Ölçüm paketi ayrıca cihazın verdiği bir anahtarla şifrelenebiliyor. Bu durumda kullanıcı anahtarı elle yazabiliyor veya cihazdaki Data Matrix kodunu okutabiliyor. Anahtar cihaz kaydıyla birlikte saklanıyor ve yalnızca ilgili cihazın verisini çözmek için kullanılıyor. Böylece şu üç senaryo aynı üst akışta, fakat birbirine karıştırılmadan yönetiliyor:

Ek doğrulama istemeyen cihazlar,
İşletim sisteminin PIN/bond sürecini kullanan cihazlar,
Bağlantı sonrasında ölçüm verisi için ayrı şifreleme anahtarı isteyen cihazlar.

Eşleştirme tamamlanmadan cihaz kalıcı listeye eklenmiyor. Başarılı sonuçtan sonra cihaz kimliği, tipi, eklenme zamanı ve gerekiyorsa şifreleme bilgisi yerel kayda alınarak sonraki oturumların temeli oluşturuluyor.

Otomatik bağlantı altyapısı

Her cihaz sürekli bağlı kalmaya uygun değil. Bu nedenle otomatik bağlantı tek bir global ayar olarak değil, cihaz tipi yetenekleri üzerinden yönetiliyor. Bir model için ilk bağlantıda otomatik modun kullanılması, uygulama açılışında yeniden bağlanılması ve Bluetooth durumu değiştiğinde global bağlantı yönetimine katılması ayrı ayrı tanımlanabiliyor.

Uygulama açıldığında kayıtlı cihazlar okunuyor, yeniden bağlanmayı destekleyen cihazların bağlantı durumları dinleniyor ve uygun strateji başlatılıyor. Doğrudan otomatik bağlantının yeterli olmadığı durumlarda koordinatör, kayıtlı cihazları tek taramada arayıp görünür olanlara bağlanıyor. Uygulama arka plana geçtiğinde aktif tarama durduruluyor; yeniden öne geldiğinde kullanıcı tercihi ve mevcut durum korunarak devam ediyor.

Bağlantı kesilmesi tek başına hata kabul edilmiyor. Sistem, cihazın daha önce gerçekten bağlanıp bağlanmadığını izliyor; bağlı bir oturum sona erdiğinde son senkronizasyon zamanı güncelleniyor ve cihaza özel dinleyiciler temizleniyor. Bu, geçici bağlantı kayıplarıyla hiç bulunamayan cihazları aynı sepete koymamayı sağlıyor.

Ölçüm akışı

Cihaz bağlandığında ilgili adaptör servislerini keşfediyor, ihtiyaç duyduğu bildirim kanallarını açıyor ve ham paketleri alan modeline dönüştürüyor. Tansiyon, kan şekeri, oksijen, ağırlık, ateş, EKG ve INR gibi farklı sonuçlar ortak sağlık kayıtlarına taşınmadan önce kendi kurallarıyla doğrulanıyor.

Kullanıcı birden fazla kayıtlı cihazı seçerek sıralı ölçüm de başlatabiliyor. Her ölçüm kendi cihaz oturumunda ilerlerken sonuçlar ortak olay akışı üzerinden ilgili adıma ulaşıyor. Böylece çoklu cihaz desteği yalnızca “birden fazla cihaz kaydetmek” düzeyinde kalmıyor; evdeki ölçüm rutininin tek akışta tamamlanmasını sağlıyor.

Zorlayıcı noktalar

Üretici farklılıkları. Aynı BLE standardını kullanan cihazlar bile aynı sırayla davranmıyor. Bazısı veriyi canlı yayınlıyor, bazısı son kaydı istiyor, bazısı bildirim açılmadan önce okuma veya yazma bekliyor. Bu farklılıkları ortak sınıfa zorla taşımak yerine cihaz adaptörlerinde görünür tutmak sistemi daha anlaşılır yaptı.

Platform farklılıkları. Bluetooth izni, tarama ve bond davranışı iOS ile Android’de aynı değil; Android sürümleri arasında da değişiyor. Platform farkları tek bir Bluetooth yöneticisinde toplandığı için cihaz ekranları bu ayrıntıları bilmiyor.

Asenkron yarışlar. Tarama sonucu, bağlantı durumu ve kullanıcı aksiyonu aynı anda gelebiliyor. Tarama aboneliklerini kontrollü kapatmak, bulunan cihazları kimlik üzerinden tekilleştirmek ve manuel/otomatik taramayı sıraya koymak tekrarlı bağlantıları önledi.

Sessiz veri hataları. Bağlantının kurulmuş olması ölçümün geçerli olduğu anlamına gelmiyor. Aralık kontrolleri, paket bütünlüğü, son alınan ölçüm zamanı ve cihaza özel çözümleme kuralları bağlantı başarısından ayrı ele alınıyor.

Sonuç

Ortaya çıkan altyapı, farklı bağlantı ve güvenlik beklentilerine sahip çok sayıda medikal cihazı tek kullanıcı deneyiminde birleştirdi. Yeni cihaz entegrasyonları ortak tarama ve bağlantı akışını büyütmeden eklenebilir hale geldi; kayıtlı birden fazla cihaz tek taramayla bulunup bağımsız olarak yönetilebildi. Kullanıcı açısından süreç ise cihazını seçmek, gerekiyorsa PIN veya cihaz anahtarını girmek ve ölçüm yapmak kadar basit kaldı.

Öğrendiklerim

Cihaz tipi yalnızca bir isim değil, bir yetenek kümesidir. Otomatik bağlantı, ilk bağlantı davranışı ve protokol gereksinimleri veri olarak tanımlandığında koşullu kod hızla azalıyor.
Tarama paylaşılan bir kaynaktır. Manuel arama, yeniden bağlanma ve yaşam döngüsü tek bir koordinasyon noktası olmadan güvenilir çalışmıyor.
Bluetooth bağlantısı ile eşleştirme aynı şey değildir. Fiziksel bağlantı, sistem PIN’i ve uygulama seviyesindeki veri anahtarı ayrı durumlar olarak modellenmelidir.
Ortaklaştırılması gereken şey protokol ayrıntıları değil, yaşam döngüsüdür. Tarama ve durum yönetimi ortak kalabilir; üretici paketlerini zorla tek biçime sokmak ise soyutlamayı kırılganlaştırır.
Başarısızlık akışları kullanıcı deneyiminin parçasıdır. Yanlış PIN, kapalı cihaz ve yarıda kesilen bağlantı sonradan eklenecek istisnalar değil, baştan tasarlanacak temel senaryolardır.