--- { "title": "Wearable- und medizinische IoT-Geräte auf FHIR: Ein Leitfaden", "description": "Wie man Wearable- und IoT-Gerätedaten als FHIR Device- und Observation-Ressourcen modelliert. Architektur, Mapping-Beispiele und eine Aidbox Open-Source-Demo.", "date": "2024-03-24", "author": "Mike Ryzhikov", "reading-time": "5 min read", "tags": [ "Aidbox", "Integrations" ], "seo-tags": [ "fhir", "fhir-backend", "fhir-platform", "fhir-server", "fhir-time-series", "fhir-device", "fhir-wearable", "fhir-database", "fhir-first" ] } --- ## Warum Healthcare-IoT auf FHIR aufbauen? Medizinische IoT-Geräte und Wearables erzeugen große Mengen an Daten, die zur Verbesserung von Gesundheitsergebnissen beitragen. Diese Daten entfalten ihren Nutzen jedoch nur, wenn sie in die medizinischen Akten der Patienten integriert und für umfassende Analysen, Echtzeit-Alarmsysteme und die klinische Entscheidungsunterstützung (CDS) verfügbar sind. Die Herausforderung besteht darin, dass diese Zeitreihendaten eine andere Natur und Struktur aufweisen als andere [FHIR-Daten](https://www.hl7.org/fhir/resourcelist.html) wie Patientendaten, Allergien, Diagnosen usw. Zeitreihendaten erfordern einen speziellen Ansatz für ihre Verarbeitung und Speicherung. Dieser Beitrag zeigt, wie Daten, die von medizinischen Geräten erzeugt werden, effektiv in eine FHIR-Lösung integriert werden können, die auf der [Aidbox FHIR-Plattform](https://www.health-samurai.io/aidbox) basiert. Sie finden hier das FHIR-Modell, einen Leitfaden zur Anpassung der Aidbox-Plattform sowie einen Link zu dem Open-Source-Projekt, das dieses Konzept veranschaulicht. ## Wearable-Geräte auf FHIR: Lösungsarchitektur Stellen Sie sich vor, wir müssen Daten einer Smartwatch und eines EKG-Monitors in die [FHIR-Patientenakten](https://www.hl7.org/fhir/resourcelist.html) integrieren, die wir bereits in unserer [Aidbox-basierten Lösung](https://www.health-samurai.io/aidbox) verwalten. Wir werden folgende Messwerte empfangen: Herzfrequenz (HR), Atemfrequenz (RR), SpO2 und EKG-Diagnoseergebnisse. [![iot wearables devices](image-1.avif)](https://www.health-samurai.io/aidbox) Die Rohdaten sehen folgendermaßen aus: ![medical wearable iot development](image-2.avif) ### 1. Von Rohdaten zu FHIR-Daten Zunächst müssen wir die Rohdaten in FHIR konvertieren. [HL7 FHIR](https://www.hl7.org/fhir/resourcelist.html) empfiehlt die Verwendung der [Observation-Ressource](https://www.hl7.org/fhir/observation.html) für den Austausch von Vitalzeichen, EKG und anderen messbaren Patientendaten. Eine mögliche Lösung besteht darin, die von den Geräten erzeugten Daten gemäß der [FHIR Observation-Ressource](https://www.hl7.org/fhir/observation.html) mit den folgenden Komponentenattributen zu modellieren: ![iot wearables for health](image-3.avif) ### 2. Von generischem zu hybridem PostgreSQL Als Nächstes: Aidbox basiert auf PostgreSQL und wir speichern FHIR-Ressourcen als JSONB. Für unseren Anwendungsfall müssen wir das leistungsstarke Postgres in einen hybriden Speicher umwandeln, der sowohl mit JSONB als auch mit Zeitreihendaten effektiv arbeiten kann. Den entscheidenden Unterschied macht die [TimescaleDB](https://www.timescale.com/)-Erweiterung für Postgres. Diese Erweiterung fügt lediglich einen speziellen Tabellentyp namens [Hypertable](https://docs.timescale.com/use-timescale/latest/) für Zeitreihendaten sowie mehrere zusätzliche Optionen hinzu, wie etwa [Komprimierung](https://docs.timescale.com/use-timescale/latest/compression/), [kontinuierliche Aggregate](https://docs.timescale.com/use-timescale/latest/continuous-aggregates/) und weitere. Als Ergebnis sind wir in der Lage, grundlegende FHIR-Daten weiterhin als JSONB zu speichern und Observations als Zeitreihendaten in [Hypertables](https://docs.timescale.com/use-timescale/latest/). Diese Daten werden referenziert und funktionieren als ein einheitlicher Datensatz für externe Anforderungen. ![devices on fhir](image-4.avif) ### 3. Von Standard-Aidbox zu zeitreihenfreundlichem Aidbox Der dritte Schritt besteht darin, Aidbox beizubringen, Observations als Zeitreihendaten in Hypertables zu verarbeiten und zu speichern, während andere FHIR-Daten über den Standardmechanismus als JSONB gespeichert werden. Um dies zu erreichen, können wir den Handler des /Observation-Endpunkts vom Standard- auf einen benutzerdefinierten Handler umstellen. Aidbox-Kunden können dies über [den Aidbox-Apps-Mechanismus](https://www.health-samurai.io/docs/aidbox/tools/aidbox-sdk/aidbox-apps) realisieren und einen benutzerdefinierten Handler in einer Programmiersprache ihrer Wahl entwickeln. Darüber hinaus stehen [SDKs für Aidbox](https://www.health-samurai.io/docs/aidbox/tools/aidbox-sdk) und [zusätzliche APIs](https://www.health-samurai.io/docs/aidbox/api-1/reactive-api-and-subscriptions) zur Verfügung. ![iot wearables healthcare](image-5.avif) > > [Erkunden Sie unsere umfassende SDK-Dokumentation](https://hubs.ly/Q02y4Vsz0), um zu erfahren, wie Sie benutzerdefinierte Anwendungen erstellen und die Plattform an Ihre spezifischen Anforderungen anpassen können. ### 4. Die Leistungsfähigkeit von TimescaleDB für Alarme nutzen Voilà – Ihre Benutzeroberfläche oder externe Systeme können medizinische Akten und Observation-Daten über die Standard-FHIR-API abrufen und visualisieren. Das Sahnehäubchen ist jedoch die Möglichkeit, Zeitreihendaten, die mit FHIR-Daten verknüpft sind, effektiv für Alarme und die klinische Entscheidungsunterstützung (CDS) zu nutzen. [TimescaleDB](https://www.timescale.com/) bietet viele Engines auf Basis von Hypertables, und [die Engine für kontinuierliche Aggregate](https://docs.timescale.com/use-timescale/latest/continuous-aggregates/create-a-continuous-aggregate/#create-a-continuous-aggregate) ist eine davon. So können Sie beispielsweise in Echtzeit Alarme verfolgen und generieren, wenn die HR ansteigt oder die SpO2 abfällt. Die Bedingungen für Alarme können sich nicht nur auf Zeitreihendaten, sondern auch auf beliebige FHIR-Daten in Ihrer Lösung stützen. Um diese Alarme für Ihre Benutzeroberfläche oder externe Systeme/Module verfügbar zu machen, können Sie [die Aidbox-API durch benutzerdefinierte Operationen erweitern](https://www.health-samurai.io/docs/aidbox/tools/aidbox-sdk/aidbox-apps#operations). Die Handler für diese Endpunkte können SQL-basiert sein oder in Ihrer [Aidbox-App](https://www.health-samurai.io/docs/aidbox/tools/aidbox-sdk/aidbox-apps) in der Nähe des /Observation-Endpunkt-Handlers implementiert werden. ![wearable api](image-6.avif) ### 5. Ende-zu-Ende-Lösungsübersicht Fügen wir all diese Ideen zu einer Ende-zu-Ende-Lösung zusammen. **#1** – Geräte erzeugen rohe Zeitreihendaten, **#2** – Der FHIR-Konverter empfängt diesen Datenstrom, konvertiert ihn in FHIR Observations und sendet diese an Aidbox, **#3** – Aidbox verarbeitet Observations über den überschriebenen /Observation-Endpunkt mittels der [Aidbox-App](https://www.health-samurai.io/docs/aidbox/tools/aidbox-sdk/aidbox-apps), **#4** – Empfangene Observation-Ressourcen werden in einer [Hypertable](https://docs.timescale.com/use-timescale/latest/hypertables/) gespeichert und sind über eine Patientenreferenz verknüpft, **#5** – Die [TimescaleDB](https://www.timescale.com/)-Engine generiert Alarme auf Basis vordefinierter Bedingungen, **#6** – Aidbox stellt [FHIR-Daten](https://www.hl7.org/fhir/resourcelist.html) über die [FHIR-API](https://www.hl7.org/fhir/http.html) und Alarme über benutzerdefinierte Endpunkte bereit, **#7** – Die Web-Benutzeroberfläche visualisiert diese Daten und zeigt Alarme für Endbenutzer an. ![medical wearable iot development](image-7.avif) ## Bonus Wir untermauern Worte gerne mit der Praxis und haben [den Quellcode des Projekts veröffentlicht](https://github.com/Aidbox/timeseries), das die Implementierung dieses Konzepts zeigt – entwickelt von einem unserer Teammitglieder innerhalb des internen Weihnachts-Hackathons in 48 Stunden. Wenn Sie über einen technischen Hintergrund verfügen, können Sie diesen Code einsehen und die Ideen ohne Hürden direkt in der Praxis erkunden. ![wearable health data integration](image-8.avif)*Open-Source-Projekt: https://github.com/Aidbox/timeseries* ## Vorteile In diesem Beitrag haben wir eine sehr grundlegende Lösung beschrieben, wie Wearables und medizinische Geräte in ein FHIR-first-Ökosystem integriert werden können, das auf der Aidbox FHIR-Plattform basiert. Alle Teile dieser Pipeline können angepasst und verbessert werden, um die tatsächlichen Systemlasten Ihrer Umgebung zu unterstützen. Sie können beispielsweise Warteschlangen für Dateneingaben von Geräten oder eine optimierte FHIR-ähnliche API für Observations hinzufügen usw. Um zu erkunden, wie Aidbox die Integration von Daten aus Wearables und medizinischen Geräten erleichtern kann, testen Sie die [kostenlose Version von Aidbox](https://www.health-samurai.io/aidbox#run). Sie bietet eine vollständige Umgebung zum Testen und Entwickeln dieser Integrationen und stellt alle notwendigen Werkzeuge ohne Funktionseinschränkungen bereit. ### Zusammenfassung der Vorteile **# Einfachheit** – monolithische Lösung mit leistungsstarkem hybridem Speicher auf Basis von PostgreSQL, **# Alles an einem Ort** – FHIR-Daten und Zeitreihendaten als einheitlicher Datensatz, **# FHIR-first** – minimale interne Transformationen, wobei FHIR für den Austausch und die Speicherung von Daten genutzt wird, **# Anpassbar** – alle Teile der Lösung können dank des datengetriebenen Paradigmas individuell angepasst werden, **# Leistung** – Speicher und Engines sind stark für beide Datentypen optimiert. Autor:[ **Mike Ryzhikov**](https://www.linkedin.com/in/fhir-solutions/) COO bei Health Samurai [![Aidbox FHIR Platform Free Trial](image-9.avif)](https://www.health-samurai.io/aidbox) Siehe auch: [Topic-based Subscriptions: Top 5 Use Cases](/blog/topic-based-subscriptions-top-5-use-cases-for-digital-health) und [Using FHIR to Simplify Healthcare Development](/blog/using-fhir-to-simplify-healthcare-application-development).