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

Problem

Bir sağlık uygulamasında Bluetooth desteği, yakındaki cihazı bulup bağlanmaktan çok daha fazlasını gerektiriyor. Tansiyon aleti, şeker ölçüm cihazı, oksimetre, tartı, termometre ve EKG cihazlarının her biri farklı biçimde yayın yapıyor, farklı servisler sunuyor ve farklı eşleştirme adımları bekliyor.

Aynı kullanıcı birden fazla cihaz da kullanabiliyor. Uygulama açıldığında kayıtlı cihazlardan 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. Üstelik Bluetooth ve konum izinleri işletim sistemine göre değişiyor.

Çok sayıda modeli desteklemek tek başına yetmiyordu. Yeni bir cihaz eklemenin mevcut cihazları riske atmaması ve kullanıcıdan Bluetooth bilgisi beklememesi gerekiyordu.

Bağlam ve kısıtlar

iOS ve Android uygulamaları tek bir Flutter kod tabanından 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 topluyor.
Kullanıcıların önemli bir bölümü teknik değil. Servis UUID’si, bağlantı modu ya da eşleştirme türü gibi ayrıntılar kullanıcının karşısına çıkmamalı.
BLE bağlantısı doğası gereği kesintili. Cihazın kapalı, uzakta, başka bir telefona bağlı ya da henüz ölçüm moduna alınmamış olması sıradan durumlar.
Bazı cihazlar sistem seviyesinde PIN istiyor, bazıları ek işlem olmadan bağlanıyor, bazıları da 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 belirledim. Üretici protokollerinin uygulanması, eşleştirme akışları, hata senaryoları, kod incelemeleri ve ekip içi teknik standartlar da bendeydi.

Çoklu cihaz mimarisi

Sistemin merkezinde büyük bir switch bloğu yok. Her cihaz tipi, kendi yeteneklerini ve davranışını taşıyan bir fabrika üzerinden kaydediliyor. 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 bildiriyor.

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

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 bir sözleşmede topluyor. Servis keşfi, characteristic seçimi, byte çözümleme ve ölçüm protokolü gibi gerçekten cihazdan cihaza değişen ayrıntılar üreticiye özel veri kaynaklarında duruyor. Bağlantı durumu cihaz kimliğine göre tutulduğu için bir cihazdaki değişiklik başka bir cihazın oturumunu ezmiyor.

Yeni bir model eklemek, ortak akışa dokunmadan yeni bir cihaz adaptörü ve onun fabrika kaydını eklemekten ibaret.

Kapsamlı cihaz arama

Arama başlamadan önce Bluetooth adaptörü, platform izinleri ve Android’deki konum koşulları kontrol ediliyor. İzin yoksa kullanıcıya boş bir cihaz listesi gösterilmiyor, doğru aksiyona yönlendiriliyor.

Tarama sonuçları yalnızca cihaz adına göre filtrelenmiyor. Modele göre yayın adı, üretici verisi, servis bilgisi ve daha önce kaydedilmiş cihaz kimliği birlikte değerlendirilebiliyor. Kullanıcıya çevredeki bütün BLE cihazları gösterilmiyor; yalnızca seçtiği medikal cihaz ailesine uyan sonuçlar listeleniyor. Daha önce eşleştirilmiş cihazlar da yeni cihaz listesinde çıkmıyor.

Kayıtlı tek bir cihaz aranıyorsa tarama doğrudan onun kimliğine daraltılıyor. Birden fazla kayıtlı cihaz varsa her biri için ayrı tarama başlatılmıyor, bütün kimlikler tek bir tarama isteğine veriliyor. Sonuç geldiğinde cihaz kimliği kendi cihaz tipiyle eşleştiriliyor, bulunan her cihaz bağlantı akışına yalnızca bir kez alınıyor ve bütün hedefler bulununca tarama duruyor. Bu 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ışıyor. Ek doğrulama istemeyen cihazlarda ortak akış doğrudan başarılı sayılıyor. Servis keşfi, bildirim açma ya da characteristic okuma gerektiren modeller bu adımları kendi adaptörlerinde tamamlıyor.

Sistem seviyesinde güvenli eşleştirme isteyen cihazlarda Android bond durumu izleniyor; PIN ekranını iOS ve Android kendisi gösteriyor. Yanlış kod girildiğinde platformlar aynı hatayı üretmediği için sonucu hata koduna göre değil, eşleştirmenin gerçekten tamamlanıp tamamlanmadığına göre değerlendiriyoruz. Bağlantı kritik bir anda düşerse kısa bir gecikmeden sonra kontrollü bir ikinci deneme yapılabiliyor; yine başarısız olursa kullanıcıya yeniden deneme seçeneği sunuluyor.

Bazı cihazlarda PIN ile Bluetooth eşleştirmesi de yetmiyor, çünkü ölçüm paketi ayrıca cihazın verdiği bir anahtarla şifrelenebiliyor. Kullanıcı bu anahtarı elle yazabiliyor ya da cihazdaki Data Matrix kodunu okutabiliyor. Anahtar cihaz kaydıyla birlikte saklanıyor ve yalnızca o cihazın verisini çözmek için kullanılıyor. Sonuçta üç senaryo aynı üst akışta ama birbirine karışmadan yönetiliyor:

Ek doğrulama istemeyen cihazlar,
İşletim sisteminin PIN/bond sürecini kullanan cihazlar,
Bağlantıdan sonra ö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 olarak kaydediliyor; sonraki oturumlar bu kayıttan devam ediyor.

Otomatik bağlantı altyapısı

Her cihaz sürekli bağlı kalmaya uygun değil. Bu yüzden otomatik bağlantıyı tek bir global ayarla değil, cihaz tipinin yetenekleriyle yönetiyoruz. Bir model için ilk bağlantıda otomatik modun kullanılıp kullanılmayacağı, uygulama açılışında yeniden bağlanılıp bağlanılmayacağı ve Bluetooth durumu değiştiğinde global bağlantı yönetimine katılıp katılmayacağı ayrı ayrı tanımlanabiliyor.

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

Bağlantının kesilmesi tek başına hata sayılmıyor. Sistem cihazın daha önce gerçekten bağlanıp bağlanmadığını takip ediyor. Bağlı bir oturum sona erdiğinde son senkronizasyon zamanı güncelleniyor ve cihaza özel dinleyiciler temizleniyor. Böylece geçici bağlantı kayıpları ile hiç bulunamayan cihazlar ayrı ele alınıyor.

Ölçüm akışı

Cihaz bağlanınca 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 sonuçlar ortak sağlık kayıtlarına taşınmadan önce her biri kendi kurallarıyla doğrulanıyor.

Kullanıcı birden fazla kayıtlı cihaz seçip sıralı ölçüm de başlatabiliyor. Her ölçüm kendi cihaz oturumunda ilerliyor, sonuçlar ortak olay akışı üzerinden ilgili adıma ulaşıyor. Evdeki ölçüm rutini böylece tek bir akışta tamamlanabiliyor.

Zorlayıcı noktalar

Aynı BLE standardını kullanan cihazlar bile aynı sırayla davranmıyor. Bazısı veriyi canlı yayınlıyor, bazısından son kaydı istemek gerekiyor, bazısı bildirim açılmadan önce bir okuma ya da yazma bekliyor. Bu üretici farklılıklarını ortak sınıfa zorla taşımadık, cihaz adaptörlerinde açıkça görünür bıraktık. Sistem bu sayede daha anlaşılır oldu.

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

Tarama sonucu, bağlantı durumu ve kullanıcı aksiyonu aynı anda gelebiliyor. Tarama aboneliklerini kontrollü kapatmak, bulunan cihazları kimliğe göre tekilleştirmek ve manuel ile otomatik taramayı sıraya koymak tekrarlanan bağlantıları önledi.

Bağlantının kurulmuş olması ölçümün geçerli olduğunu göstermiyor. Aralık kontrolleri, paket bütünlüğü, son ölçüm zamanı ve cihaza özel çözümleme kuralları bağlantının başarısından ayrı kontrol ediliyor.

Sonuç

Bu altyapı, bağlantı ve güvenlik beklentileri birbirinden farklı çok sayıda medikal cihazı tek bir kullanıcı deneyiminde topladı. Yeni cihaz entegrasyonları ortak tarama ve bağlantı akışını büyütmeden eklenebiliyor; birden fazla kayıtlı cihaz tek taramayla bulunup birbirinden bağımsız yönetilebiliyor. Kullanıcı için süreç cihazını seçmek, gerekiyorsa PIN’i ya da cihaz anahtarını girmek ve ölçüm yapmaktan ibaret.

Öğrendiklerim

Cihaz tipini bir isim olarak değil, bir yetenek kümesi olarak düşünmek işe yaradı. Otomatik bağlantı, ilk bağlantı davranışı ve protokol gereksinimleri veri olarak tanımlanınca koşullu kod hızla azaldı.
Tarama paylaşılan bir kaynak. 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 ayrı şeyler. Fiziksel bağlantıyı, sistem PIN’ini ve uygulama seviyesindeki veri anahtarını ayrı durumlar olarak modellemek gerekiyor.
Ortak tutulabilecek kısım yaşam döngüsü: tarama ve durum yönetimi. Üretici paketlerini zorla tek biçime sokmak soyutlamayı kırılganlaştırıyor.
Yanlış PIN, kapalı cihaz ve yarıda kesilen bağlantı, sonradan eklenecek istisnalar olarak değil, baştan tasarlanması gereken senaryolar olarak ele alınmalı.