Tento článek vysvětluje, jak vytvořit systém telehealth pomocí cloudové platformy Azure.
Architektura
Stáhněte si soubor aplikace Visio s touto architekturou.
Workflow
Řešení je postavené na čtyřech pilířích, mezi které patří:
- Klienti
- Komunikační komponenty
- Rozhraní API a obchodní logika
- Služby úložiště a infrastruktury
Na levé straně architektonického diagramu jsou klienti ve dvou skupinách, zdravotník a pacient. Zdravotnický pracovník používá k komunikaci se svými pacienty odpovídající software a klienty webového portálu. Pacienti na druhé straně používají mobilní aplikaci, která je propojená s lékařským zařízením prostřednictvím připojení Bluetooth. Tato komunikace zpět a zpět se dosahuje pomocí back-endových služeb:
- Veřejná rozhraní API
- Interní mikroslužby zodpovědné za pracovní postupy, jako jsou videohovory prostřednictvím webového RTC nebo komunikace mezi klienty pomocí signálu. signal je softwarová knihovna pro Microsoft ASP.NET, která umožňuje kódu serveru odesílat asynchronní oznámení webovým aplikacím na straně klienta.
Stav těchto služeb je trvalý v několika službách Azure (na pravé straně diagramu), jako je Azure Database for PostgreSQL. Multimediální soubory se ukládají do účtů úložiště Azure. Všechny protokoly ze všech služeb se shromažďují v centralizované řešení protokolování, které používá Aplikace Azure Přehledy. Asynchronní komunikace se dá nakonec dosáhnout mezi klienty prostřednictvím nabízených oznámení pomocí centra oznámení Azure.
Řešení bylo nastaveno tímto způsobem:
Využijte výhod škálovatelnosti cloudových služeb běžících v back-endu.
Zvyšte autonomiitýmůch Každý tým dohlíží na funkční domény a řídí vývoj jejich komponent. Vzhledem k tomu, že se funkční domény nepřekrývají, každý tým může inovovat vlastním tempem. Vzhledem k tomu, že jsou základy kódu služeb nezávislé, je kanál CI/CD pro celé řešení zjednodušený.
Sestavte komunikační a koordinační mechanismus mezi službami, který vyžaduje distribuce funkcí napříč mikroslužbami. Řešení popsané v tomto dokumentu používá k provedení této úlohy službu Azure Cache for Redis.
Dosažení centrálního monitorování a vylepšení schopnosti řešení řešit potíže.
Zjednodušená správa tajných kódů, přihlašovacích údajů, certifikátů a klíčů, které využívají spravované identity k zabezpečení komunikace mezi službami.
Komponenty
- Azure Database for PostgreSQL ukládá data týkající se uživatelů (pacientů a zdravotní péče) a dat souvisejících se zařízeními. Služba byla vybrána, protože je stabilní, odlehčená a nemá žádný zámek dodavatele.
- Azure Kubernetes Service hostuje obchodní logiku aplikace a poskytuje snadné nasazení a flexibilitu pro přizpůsobení. Služba také abstrahuje řešení od skutečného hardwaru použitého pod ním.
- Azure Cache for Redis hostuje dočasná data použitá pro data uvnitř služby (sdílená data). Službu je možné z databáze vytvořit znovu v případě, že vyprší platnost dat z mezipaměti.
- Azure Notification Hub upozorní pacienta na příchozí obsah: chat, videohovory, nastavení konfigurace zařízení.
- Azure Functions plánuje úlohy. Například široká komunikace s velkou sadou uživatelů, koordinace analytické práce v back-endu (agregace...).
- Aplikace Azure Přehledy centralizuje signály a události ze systému (protokoly, telemetrie z protokolů z mikroslužeb, front-endu a zařízení) pro účely řešení potíží.
- Azure Content Delivery Network (CDN) se používá k údržbě a aktualizacím (doručování souborů skriptů Java) na webový portál a k doručování mediálních souborů (videí, obrázků) prostřednictvím portálu. Veškerý tento obsah je uložený v účtech úložiště Azure na pozadí.
- Vyrovnávání zatížení Azure Traffic Manageru mezi geograficky umístěními
- Azure SignalR umožňuje serverovým kódu odesílat asynchronní oznámení webovým aplikacím na straně klienta. Zařízení koncových uživatelů je možné nakonfigurovat v režimu Standard nebo Advanced .
Alternativy
Na straně databáze je možné použít všechny ostatní databázové služby PaaS. Při hostování logiky aplikace místo použití služby Azure Kubernetes Service můžete zvážit použití služby Aplikace Azure Service.
Podrobnosti scénáře
Podrobnosti vycházejí z implementace skutečného zákazníka, která propojuje profesionální zdravotnickou organizaci se svými vzdálenými pacienty. I když existují i další způsoby, jak takový systém vytvořit, bylo popsané řešení úspěšné při komunikaci mezi pacienty a jejich poskytovatelem vzdálené péče a také vzdálené ladění zdravotnických zařízení, která pacienti nosí.
Existuje asi 700 milionů lidí, kteří trpí sluchovým postižením. Pouze 10 % z nich však ke zlepšení svého života používá zařízení s sluchadlem. V některých zeměpisných oblastech nebo situacích není možné, aby pacient v případě potřeby získal přímou pomoc. Zvažte například pacienty, kteří:
- Potřebujete pomoc v konkrétní situaci sluchu (například při procházce v parku, účasti na večírku nebo doma), které není možné reprodukovat v kanceláři profesionální péče o sluch.
- Máte problémy s pohyblivostí nebo se nacházejí na dlouhé vzdálenosti od svého pracovníka v oblasti sluchové péče.
- Žije v nově vznikající zemi nebo oblasti, která má omezený počet odborníků na sluchovou péči.
Aby bylo možné tyto potíže překonat, je důležité mít schopnost poskytovat služby sluchové péče vzdáleně. V tomto případě zdravotnický pracovník používá chat nebo video komunikaci, aby se zapojil se svými vzdálenými pacienty. Lidé, kteří neslyší, používají smartphone, aby byl během vzdálené relace přístup k zařízení s sluchovou pomůckou. Pacient okamžitě zaznamená lepší sluch, protože odborník na sluchové péči nasadí změny konfigurace zařízení s sluchovým pomocníkem v reálném čase.
Potenciální případy použití
Toto řešení je ideální pro zdravotnictví. Následující další případy použití mají podobné vzory návrhu:
- K libovolnému zařízení s podporou Bluetooth je možné přistupovat a vzdáleně ladit pomocí takového řešení.
- Komunikace (text, hlas, video) nebo výměna znalostí (vzdělávání, průzkumy spokojenosti) ve vzdáleném nastavení a kontextu.
- Globálně distribuovaná správa webového obsahu
- Internet věcí (IoT)
Režimy
Standardní režim
V režimu Standard připraví fitování software oznámení, které obsahuje určitý konfigurační soubor JSON nebo obsah zařízení. Oznámení se pak předá do Centra oznámení Azure, které odešle oznámení do telefonu uživatele.
Rozšířený režim
V rozšířeném režimu specialista na sluchová pomoc používá fitující software k nabízení podrobné konfigurace zařízení. To vyžaduje stabilní a spolehlivé připojení mezi back-endem a zařízením, které SignalR dosahuje pomocí WebSockets. Telefon koncového uživatele je na přijímajícím konci tohoto kanálu. Připojení Bluetooth z telefonu vytvoří konečné komunikační propojení se zařízením.
Důležité informace
Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.
Ke optimalizaci latence mezi oblastmi a jako záložní mechanismus doporučujeme použít Traffic Manager před různými clustery, aby clustery byly nedostupné. Pro databáze doporučujeme používat repliky jen pro čtení pro dotazy, které vyžadují načítání a agregaci velkého množství dat. Doporučujeme poskytovat statické webové soubory (.html, .js, obrázky atd.) globálně pomocí sítě pro doručování obsahu (CDN), aby se zlepšila rychlost ukládání do mezipaměti.
Nasazení
Nejdůležitějším aspektem, který je potřeba vzít v úvahu při nasazování tohoto scénáře, je koordinace nasazení napříč cloudovým back-endem a front-endem (telefony nebo zařízení). Zvažte použití konceptu příznaku funkce k dosažení tohoto cíle.
Správa
Pokud chcete lépe sladit myšlenku, že se každá funkční doména zabývá používáním konkrétní mikroslužby v dlouhodobém horizontu, existuje příležitost rozdělit databázi na několik menších databází. Tím umožníte zásadovou izolaci a autonomii toku souvisejícího s každou mikroslužbou, a ne soustředit data související se všemi službami do jedné databáze. Dosažení tohoto cíle bude vyžadovat automatizaci zřizování a správy těchto databází, což je jedna ze základních funkcí databázové služby PaaS v cloudu. Tato vrstva správy databáze by měla být integrovaná do řešení i do sjednoceného řešení monitorování.
Sledování
Je důležité monitorovat každou vrstvu a každá omezující vlastnost monitorování by měla být federovaná do jednoho kontejneru v cloudu. Je důležité povolit korelaci všech těchto protokolů a datových bodů telemetrie, aby se zajistilo holistické přehledy napříč komponentami a vrstvami.
Dnes monitorované vrstvy zahrnují:
- Aplikace pro Windows (fitování softwaru na stolním počítači profesionální péče o sluch)
- Logika hostované aplikace
- Cloudové služby
Změna velikosti a škálování
Nezapomeňte optimalizovat konfiguraci clusterů Azure Kubernetes tak, aby odpovídaly požadavkům na škálování, které kolísá s časem dne nebo oblastí. Zvažte snižování zátěže čtení (například agregace dotazů) pomocí replik pro čtení ve službě Azure Database for PostgreSQL.
Použití rozšíření TimescaleDB postgreSQL umožní efektivnější zpracování dat souvisejících s časem přicházejících z lékařských zařízení. Zvažte použití řešení škálování na více instancí, jako je Azure Database for PostgreSQL – Hyperscale (Citus), abyste dosáhli globálního škálování zřízením několika databázových uzlů.
Zabezpečení a dodržování předpisů
Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v tématu Přehled pilíře zabezpečení.
Toto řešení zpracovává PHI a osobní údaje. Proto je důležité používat služby, které jsou certifikované pro zdravotnické aplikace (certifikace HIPAA, nejen pro data, která zůstávají v databázi, ale také protokoly a telemetrická data). Podrobnosti najdete v části HIPAA v Centru zabezpečení Microsoftu.
Spravovaná identita by se měla používat ve všech službách Azure, které podporují tento typ ověřování bez hesla, aby se zjednodušila správa hesel: AKS, PostgreSQL, Redis Cache, Notification Hub, Azure Key Vault a Azure Functions. Prohlédněte si všechny služby, které podporují spravované identity pro prostředky Azure.
Optimalizace nákladů
Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.
V případě nasazení v jedné oblasti jsou v cenové kalkulačce k dispozici například informace o cenách.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autoři:
- Jean-Yves Devant | Hlavní produktový manažer
Další kroky
Pokud chcete začít s implementací srovnatelné architektury pro vaši firmu, zvažte vytváření dovedností v oblasti webových služeb, databází, jako je Azure Database for PostgreSQL, a technik a technologií vývoje mobilních aplikací, jako je .NET MAUI.
Dokumentace k produktu:
- Co je Azure Database for PostgreSQL?
- Azure Kubernetes Service
- Účty úložiště Azure
- Informace o službě Azure Cache for Redis
- Seznámení s Azure Functions
- Azure Application Insights
- Co je Azure Notification Hubs?
Komunikace v reálném čase:
Další informace o tom, jak WebRTC poskytuje možnosti komunikace v reálném čase pro mobilní aplikace, je k dispozici na webu projektu WebRTC.
Servery pro otáčení:
Ke správě otočných serverů* a typů připojení (tcp, udp, p2p) použijte klientskou knihovnu, jako je Icelink (načtená aplikací na telefonu a fitování softwaru pro stolní sluchovou pomoc) a typy připojení (tcp, udp, p2p) mezi dvěma klienty (fitování softwaru a aplikace na telefonu). Klientská knihovna:
- Vytvoří streamovací kanál.
- Vytvoří připojení.
- Spravuje připojení v případě chyb, chybějící pakety, automaticky upraví streamování na varianty šířky pásma.
- Kódování a dekódování volání (zvuku nebo videa) během volání
*Turn servers are network entities in charge of relaying media in VoIP related protocols. V tomto řešení jsou hostované https://xirsys.com/ v několika datacentrech po celém světě. Vytvoří přímé připojení mezi dvěma klienty ve stejné relaci.