Tworzenie systemu telemedycznego na platformie Azure

Database for PostgreSQL
Funkcje
Kubernetes Service
Storage
Traffic Manager

W tym artykule wyjaśniono, jak utworzyć system telehealth przy użyciu usług w chmurze platformy Azure. Szczegółowe informacje są oparte na rzeczywistej implementacji klienta, która łączy profesjonalną organizację opieki zdrowotnej ze swoimi zdalnymi pacjentami. Chociaż istnieją inne sposoby tworzenia takiego systemu, opisane rozwiązanie pomyślnie umożliwia komunikację między pacjentami i ich zdalnym dostawcą usług, a także zdalnie dostraja urządzenia medyczne, które są przenoszą.

Około 700 milionów osób ma niepełnosprawność słuchu. Jednak tylko 10% z nich używa urządzeń do słuchu, aby poprawić swoje życie. W niektórych lokalizacjach geograficznych lub sytuacjach nie jest możliwe, aby pacjent w razie potrzeby uzyskać bezpośrednią pomoc. Rozważmy na przykład pacjentów, którzy:

  • Potrzebna jest pomoc w konkretnej sytuacji słuchowej (na przykład podczas chodzenia do parku, chodzenia na zajęcia lub jest w domu), której nie można odtworzyć w biurze specjalisty ds. słuchu.
  • Mieć problemy z mobilnością lub znajdować się w długich odległościach od specjalisty od opieki nad słuchem.
  • Mieszkaj w rozwijającym się kraju/regionie, który ma ograniczoną liczbę specjalistów ds. słuchu.

Aby pokonać te trudności, ważne jest, aby mieć możliwość zdalnego świadczenia usług słuchu. W takim przypadku specjalista ds. opieki zdrowotnej korzysta z czatu lub komunikacji wideo, aby angażować zdalnych pacjentów. Osoby, które mają trudności ze słuchem, używają smartfonu, aby umożliwić dostęp do urządzenia ze słuchem podczas sesji zdalnej. Pacjent natychmiast doświadcza ulepszonego słuchu, gdy specjalista obsługi słuchu wdraża zmiany w konfiguracji urządzenia do obsługi słuchu w czasie rzeczywistym.

Potencjalne przypadki użycia

Następujące dodatkowe przypadki użycia mają podobne wzorce projektowe:

  • Każde Bluetooth z włączoną obsługą sieci jest dostępne i zdalnie dostrojone przy użyciu takiego rozwiązania.
  • Komunikacja (tekst, głos, wideo) lub wymiana wiedzy (edukacja, ankiety zadowolenia) w zdalnym ustawieniu/kontekście.
  • Globalnie dystrybuowane zarządzanie zawartością internetową.
  • Internet rzeczy (IoT)

Architektura

Omówienie architektury składników platformy Azure dostępnych w systemie telehealth

Rozwiązanie jest zbudowane na czterech filarach, takich jak:

  • Klienci
  • Składniki komunikacyjne
  • Interfejsy API i logika biznesowa
  • Storage i usługi infrastruktury

Po lewej stronie diagramu architektonicznego znajdują się klienci w dwóch grupach: specjalista ds. opieki zdrowotnej i pacjent. Specjalista ds. opieki zdrowotnej używa odpowiedniego oprogramowania i klientów portalu internetowego do komunikowania się ze swoimi pacjentami. Z kolei pacjenci korzystają z aplikacji mobilnej połączonej z urządzeniem medycznym za pośrednictwem Bluetooth danych. Ta komunikacja między stronami jest osiągana przy użyciu usług zaplecza:

  • Publiczne interfejsy API
  • Wewnętrzne mikrousługi, które są odpowiedzialne za przepływy pracy, takie jak wywołania wideo za pośrednictwem sieci Web RTC lub komunikacji klient-klient przy użyciu usługi Signal. Signal to biblioteka oprogramowania dla Microsoft ASP.NET która umożliwia kodowi serwera wysyłanie asynchronicznych powiadomień do aplikacji internetowych po stronie klienta.

Stan tych usług jest utrwalany w kilku usługach platformy Azure (po prawej stronie diagramu), takich jak Azure Database for PostgreSQL. Pliki multimedialne są zapisywane na kontach usługi Azure Storage. Wszystkie dzienniki ze wszystkich usług są zbierane w rozwiązaniu do scentralizowanego rejestrowania, które korzysta z usługi Azure Application Szczegółowe informacje. Na koniec można osiągnąć asynchroniczną komunikację między klientami za pośrednictwem powiadomień wypychanych przy użyciu usługi Azure Notification Hub.

Rozwiązanie zostało skonfigurowanie w ten sposób, aby:

  • Korzystaj ze skalowalności usług w chmurze działających w za zaplecza.

  • Zwiększenie autonomii zespołów budowania rozwiązania. Każdy zespół nadzoruje domeny funkcjonalne i kieruje ewolucją swoich składników. Ponieważ domeny funkcjonalne nie nakładają się na siebie, każdy zespół może wprowadzać innowacje we własnym tempie. Ponadto, ponieważ bazy kodu usług są niezależne, potok cicha/cd dla całego rozwiązania jest uproszczony.

  • Tworzenie mechanizmu komunikacji i koordynacji między usługami wymaganego przez dystrybucję funkcji między mikrousługami. Rozwiązanie opisane w tym dokumencie używa Azure Cache for Redis do wykonania tego zadania.

  • Uzyskaj centralne monitorowanie i zwiększ możliwości rozwiązywania problemów z rozwiązaniem.

Składniki

  • Azure Database for PostgreSQL przechowuje dane użytkowników (pacjentów i specjalistów ds. opieki zdrowotnej) oraz dane dotyczące urządzeń. Usługa została wybrana, ponieważ jest stabilna, lekką i nie ma blokady dostawcy.
  • Azure Kubernetes Service obsługuje logikę biznesową aplikacji i zapewnia łatwość wdrażania oraz elastyczność dostosowywania. Usługa abstrastrajuje również rozwiązanie od rzeczywistego sprzętu używanego poniżej.
  • Azure Cache for Redis hostuje dane tymczasowe używane dla danych wewnątrz usługi (dane udostępnione). Usługę można odtworzyć z bazy danych w przypadku, gdy dane wygasną z pamięci podręcznej
  • Usługa Azure Notification Hub powiadamia pacjentów o zawartości przychodzącej: czatach, połączeniach wideo, ustawieniach konfiguracji urządzenia.
  • Azure Functions planuje zadania. Na przykład szeroka komunikacja z dużym zestawem użytkowników, koordynacja działań analitycznych w za zaplecza (agregacje...).
  • Usługa Azure Application Szczegółowe informacje centralizuje sygnały/zdarzenia z systemu (dzienniki, dane telemetryczne z dzienników z mikrousług, frontony i urządzeń) na potrzeby rozwiązywania problemów.
  • Usługa Azure Content Delivery Network (CDN) służy do konserwacji i aktualizacji (dostarczania pliku skryptów Java) do portalu internetowego oraz do dostarczania plików multimedialnych (wideo, obrazów) za pośrednictwem portalu. Cała ta zawartość jest przechowywana na kontach usługi Azure Storage w tle.
  • Azure Traffic Manager równoważenia obciążenia między lokalizacjami geograficznymi.
  • Usługa Azure SignalR umożliwia kodowi serwera wysyłanie powiadomień asynchronicznych do aplikacji internetowych po stronie klienta. Urządzenia użytkowników końcowych można skonfigurować w trybie standardowym lub zaawansowanym.

Tryb standardowy

W trybie standardowym odpowiednie oprogramowanie przygotowuje powiadomienie, które zawiera konfiguracyjne pliki JSON lub zawartość dla urządzenia. Powiadomienie jest następnie przekazywane do usługi Azure Notification Hub, która wypycha powiadomienie na telefon użytkownika.

Tryb zaawansowany

W trybie zaawansowanym specjalista pomocy słuchu używa odpowiedniego oprogramowania do wypychania szczegółowej konfiguracji do urządzenia. Wymaga to stabilnego i niezawodnego połączenia między zapleczami a urządzeniem, które signalr osiąga przy użyciu urządzeń WebSocket. Telefon użytkownika końcowego znajduje się na końcu tego kanału. Z telefonu urządzenie Bluetooth końcowe połączenie komunikacyjne z urządzeniem.

Alternatywy

Po stronie bazy danych można użyć innych usług bazy danych PaaS. Do hostowania logiki aplikacji można zamiast Azure Kubernetes Service usługę Azure Application Service lub usługę Azure Service Fabric.

Wiedza

Zalecamy używanie usługi Traffic Manager przed różnymi klastrami w celu optymalizacji pod kątem opóźnień między regionami i jako mechanizmu rezerwowego, gdy klastry staną się niedostępne. W przypadku baz danych zalecamy używanie replik tylko do odczytu dla zapytań, które wymagają ładowania i agregowania dużej ilości danych. Zalecamy globalne dostarczanie statycznych plików internetowych (.html, .js, obrazów itp.) przy użyciu sieci dostarczania zawartości (CDN) w celu zwiększenia szybkości dzięki buforowaniu.

Wdrożenie

Najważniejszym aspektem, który należy wziąć pod uwagę podczas wdrażania tego scenariusza, jest koordynacja wdrożeń w zadumieniu opartym na chmurze i frontonie (telefony/urządzenia). Rozważ użycie flagi funkcji, aby to osiągnąć.

Zarządzanie

Aby lepiej dopasować do koncepcji, że każda domena funkcjonalna zajmuje się używaniem konkretnej mikrousługi w dłuższym okresie, istnieje możliwość podzielenia bazy danych na kilka mniejszych baz danych. Umożliwi to izolację jednostkową i autonomię przepływu związanego z każdą mikrousługą w przeciwieństwie do bierania danych związanych ze wszystkimi usługami do pojedynczej bazy danych. Osiągnięcie tego celu będzie wymagało automatyzacji aprowzowania tych baz danych i zarządzania nimi, co jest jedną z podstawowych możliwości usługi bazy danych PaaS w chmurze. Ta warstwa zarządzania bazami danych powinna być zintegrowana w rozwiązaniu oraz w ujednoliconym rozwiązaniu do monitorowania.

Monitorowanie

Ważne jest, aby monitorować każdą z warstw, a każdy aspekt monitorowania powinien być federowany w jednym zasobniku w chmurze. Ważne jest, aby umożliwić korelację wszystkich tych dzienników i punktów danych telemetrycznych, aby zapewnić całościowe szczegółowe informacje między składnikami i warstwami.

Obecnie monitorowane warstwy obejmują:

  • Windows aplikacji (dopasowywanie oprogramowania na pulpicie specjalisty do opieki nad słuchem)
  • Hostowana logika aplikacji
  • Usługi w chmurze

Rozmiaru i skalowania

Upewnij się, że konfiguracja klastrów usługi Azure Kubernetes jest zoptymalizowana pod kątem wymagań skalowania, które wahają się wraz z czasem lub wzorcami regionalnymi. Rozważ odciążanie obciążeń odczytu (takich jak agregowanie zapytań) przy użyciu replik do odczytu w Azure Database for PostgreSQL.

Użycie rozszerzenia TimescaleDB bazy danych PostgreSQL umożliwi wydajniejszą obsługę danych związanych z czasem pochodzących z urządzeń medycznych. Rozważ użycie rozwiązania skalowania w poziomie, takiego Azure Database for PostgreSQL — Hiperskala (Citus) osiągnąć skalę globalną przez aprowizowanie wielu węzłów bazy danych.

Zabezpieczenia i zgodność

To rozwiązanie obsługuje phi i dane osobowe. W związku z tym ważne jest, aby korzystać z usług certyfikowanych dla aplikacji medycznych (certyfikatów HIPAA, nie tylko dla danych, które pozostają w bazie danych, ale także dzienników i danych telemetrycznych). Aby uzyskać szczegółowe informacje, zapoznaj się z sekcją HIPAA Centrum zaufania firmy Microsoft.

Cennik

W przypadku wdrożenia w jednym regionie przykładowe informacje o cenach są dostępne w kalkulatorze cen

Następne kroki

Aby rozpocząć wdrażanie porównywalnej architektury dla swojej firmy, rozważ zbudowanie umiejętności w zakresie usług internetowych, baz danych, takich jak Azure Database for PostgreSQL, oraztechnik i technologii tworzenia aplikacji mobilnych, takich jak Xamarin i .Net Core.

Komunikacja w czasie rzeczywistym

Więcej informacji na temat sposobu, w jaki webRTC zapewnia możliwości komunikacji w czasie rzeczywistym z aplikacjami mobilnymi, znajduje się w witrynie projektu WebRTC.

Włączanie serwerów

Użyj biblioteki klienta, takiej jak Icelink (ładowana przez aplikację na telefonie i przez odpowiednie oprogramowanie komputera specjalisty od aparatów słuchu), aby zarządzać serwerami turn i typami połączeń * (tcp, udp, p2p) między dwoma klientami (dopasowywanie oprogramowania i aplikacji na telefonie). Biblioteka klienta:

  • Tworzy kanał przesyłania strumieniowego
  • Nawiązywanie połączeń
  • Zarządza połączeniem w przypadku błędów, braku pakietów, automatycznie dostosowuje przesyłanie strumieniowe do zmian przepustowości
  • Kodowanie/dekodowanie wywołań (audio i/lub wideo) podczas wywołań

*Serwery są jednostkami sieci odpowiedzialnymi za przekazywanie multimediów w protokołach związanych z VoIP. W tym rozwiązaniu są one hostowane w https://xirsys.com/ kilku centrach danych na całym świecie. Ustanawia bezpośrednie połączenie między dwoma klientami w ramach tej samej sesji.