Medizinische IoT-Lösung für die Notfallversorgung

Lösung

Entdeckungsphase

In Anbetracht der Komplexität der Lösung schlug Itransition vor, das Projekt mit einer Erkundungsphase zu beginnen, um zunächst eine solide Architektur- und UX-Grundlage zu schaffen. Das Hauptziel bestand darin, die geplanten Lösungsfunktionen und Geschäftsabläufe zu vertiefen, die ersten Konzepte der wichtigsten Schnittstellen zu entwerfen und die technischen Aspekte der Hardware-Integration und Interoperabilität zu erörtern.

Die Erkundungsphase stellte eine zweimonatige Zusammenarbeit zwischen den Interessenvertretern des Kunden und einem Teil des Itransition-Teams dar, das für dieses Projekt abgestellt wurde. Auf Kundenseite waren ein Product Owner und ein technischer Leiter beteiligt, während das Team von Itransition aus einem Delivery Manager, zwei Business Analysten, einem technischen Architekten, einem UX/UI-Designer und einem Projektmanager bestand. Da der Kunde nur eine vorläufige Vision der Lösung sowohl aus geschäftlicher als auch aus technischer Sicht hatte, bestand unser Ziel darin, mehr Projektdetails zu sammeln, um einen High-Level-Projektumfang auszuarbeiten und zu bewerten. Hauptansprechpartner war der Product Owner des Kunden, der einen medizinischen Hintergrund hatte und mit dem wir ständig kommunizierten. Gelegentlich nahm auch der technische Leiter des Kunden an unseren Gesprächen teil, um die Anforderungen zu ermitteln.

Zunächst gab es keinen klaren Projektfahrplan mit ausgearbeiteten Funktionen. Der Product Owner teilte unserem Team seine allgemeinen geschäftlichen Anforderungen mit, wobei er oft während unserer Gespräche Ideen entwickelte, und unser Team half, diese in Softwareanforderungen zu übersetzen. Anschließend diskutierten wir sie, wandelten diese Anforderungen in bestimmte Systemeinheiten um und überlegten uns Verbindungen und Abhängigkeiten zwischen ihnen.

Das Team von Transition verfolgte einen flexiblen Ansatz, um allen Anforderungen des Kunden gerecht zu werden, und gab gleichzeitig Ratschläge und schlug mögliche Umgehungslösungen vor, wenn einige Optionen technisch nicht machbar waren. Unsere Business-Analysten erwogen mit Hilfe des technischen Architekten und des UX-Designers mögliche Implementierungsoptionen und erstellten Mockups. Während der Telefonate demonstrierten sie dem Product Owner mehrere Realisierungsoptionen, um sie bei Bedarf weiter zu iterieren. Gemeinsam mit dem PO probierten wir oft verschiedene Ansätze aus und übten Brainstorms. Dies wurde in unserem Projekt-Wiki festgehalten, wobei jede Seite einem bestimmten Feature gewidmet war, das nach Fertigstellung vom Product Owner genehmigt wurde. Unser technischer Architekt kommunizierte mit dem technischen Leiter des Kunden in separaten Sitzungen. Nichtsdestotrotz stimmten sich unsere Business-Analysten regelmäßig mit ihm ab, um sicherzustellen, dass wir auf derselben Seite standen und dass die geschäftlichen Anforderungen nicht im Widerspruch zu den technischen Anforderungen aus geschäftlicher und architektonischer Sicht standen.

Als Ergebnis der Erkundungsphase erstellte Itransition einen strategischeren Lieferplan für die Entwicklung einer Software zur Verwaltung von Medikamenten und Geräten. Wir erstellten ein architektonisches Dokument, in dem beschrieben wurde, wie die Lösung ungefähr aussehen sollte, und in dem die wichtigsten Bereiche hervorgehoben wurden. Danach trafen sich unsere Business-Analysten mit unserem technischen Architekten, um ein WBS-Dokument (Work Breakdown Structure) zu erstellen, in dem der Gesamtumfang des Projekts in Aufgaben zerlegt und geschätzt wurde.

Lösung für die Verwaltung von Arzneimitteln und Geräten

Itransition lieferte eine HIPAA- und FDA-konforme Lösung für das Medikamenten- und Gerätemanagement. Endnutzer der Lösung sind Krankenschwestern, Apotheker und anderes Personal, das in US-Krankenhäusern arbeitet und Patienten im Falle eines Herzstillstands versorgt. Das System ermöglicht die Verwaltung des Inventars (Medikamente und Zubehör) in intelligenten Wagen und die Konfiguration von Arbeitsabläufen für das Code Blue-Ereignis und hilft dem Personal zu dokumentieren, wie bei solchen Ereignissen medizinische Hilfe geleistet wurde. Es leitet das Pflegepersonal an, was bei einem bestimmten Patientenzustand mit bestimmten Lebensmerkmalen zu tun ist, während es diesen Prozess dokumentiert, Statistiken über die geleistete Pflege durch die Anzeige von Qualitätsstufen sammelt und Diagramme erstellt. Das System ist auch in der Lage, mit zusätzlichen Hardware-Geräten auf der Karte zu interagieren.

Da der Kunde plante, mit verschiedenen Krankenhäusern zusammenzuarbeiten, war es wichtig, dass die Daten eines Krankenhauses nicht von den Nutzern eines anderen Krankenhauses eingesehen werden können. Daher unterstützt die gelieferte Lösung Multi-Tenancy, bei der eine Datenbank von allen Mandanten genutzt wird, wobei alle Mandanten voneinander isoliert sind, während Daten und Infrastruktur für verschiedene Mandanten unterschiedlich sind.

Lösungsarchitektur

Die gelieferte Lösung besteht aus drei Hauptkomponenten: Zentralsystem, Cart-System und Tablet-System. Das Zentralsystem ist ein integraler Bestandteil der Lösung und funktioniert je nach Kundenbedürfnissen in Verbindung mit dem Cart System, dem Tablet System oder beiden Subsystemen gleichzeitig.

Das Zentralsystem ist eine Cloud-basierte Webanwendung, die als Mittel zur Verwaltung des gesamten Systems dient und von jedem Computer aus über das Anmeldeformular zugänglich ist. Es umfasst unter anderem folgende Funktionen:

• Code Blue Einstellungen
• Benutzerverwaltung und Authentifizierung
• Warenkorbverwaltung
• Verwaltung des Arzneimittelbestands
• Qualitätsberichte
• Auditprotokollierung
• HL7-Schnittstellen

Das Cart System ist eine Anwendung, die 2 Arten von Wagen unterstützt: Wiederbelebungswagen für Erwachsene und Kinder. Es ist auf einem SBC (Single Board Computer) installiert, der auf einem Wagen montiert und mit einem Wi-Fi-Modul ausgestattet ist. Das System ist für die Benutzer-, Patienten- und Bestandsverwaltung eines bestimmten Wagens sowie für die Durchführung der Code Blue-Dokumentation und der Wagenprüfung zuständig. Jeder Wagen ist im Zentralsystem registriert, und das Wagensystem erhält die Konfigurations- und Benutzerdaten vom Zentralsystem über einen implementierten Synchronisierungsdienst.

Um die Daten zwischen dem Zentralsystem und dem Warenkorbsystem jedes Mal zu synchronisieren, wenn sich ein Warenkorb mit dem Internet verbindet, haben wir die Dienste Central Sync und Cart Sync implementiert.

Das Cart System ist außerdem in der Lage, mit den folgenden Hardware-Geräten auf dem Wagen zu interagieren:

• Barcode-Scanner, um die Identifizierung von Medikamenten für die Inventur sicherzustellen
• Biometrisches Lesegerät für die Authentifizierung über Fingerabdrücke
• RFID-Lesegerät für die Authentifizierung über eine RFID-Karte
• Elektronisches Schubladenschloss
• Temperatur- und Feuchtigkeitssensoren
• Netzanschluss für Defibrillator
• Herzplatine
• Dockingstation für Tablets

In Anbetracht der Tatsache, dass nicht alle potenziellen Kunden die vereinheitlichte Hardware-Software-Plattform kaufen möchten und es vorziehen, nur den Software-Teil zu nutzen, um den Code Blue-Prozess zu dokumentieren, bat der Kunde Itransition, eine Idee für eine Alternative zum Cart-System zu realisieren - das Tablet-System. Die implementierte Lösung kann auf Tablets gestartet werden, ohne sie mit den Smart Carts des Kunden zu koppeln, und kann auch zusammen mit der eigenen Hardware des Endkunden, d.h. mit kundenspezifischen Non-Smart Carts, verwendet werden. Das Tablet-System stellt eine abgespeckte mobile Version des Zentralsystems dar, die zusätzlich mit Code Blue verwaltet wird. Von der Benutzeroberfläche her ist die Lösung identisch mit dem Cart System - die App verbindet sich über das Internet mit der gemeinsamen Datenbank und erhält die über das Central System definierten Code Blue-Einstellungen.

Code Blue

Die Carts mit der dazugehörigen Software werden verwendet, um das Code Blue-Ereignis zu dokumentieren und die einem Patienten verabreichten Medikamente und Hilfsmittel zu verfolgen. Das Hauptziel des Code Blue Prozesses ist es, alle Schritte zu dokumentieren, die während des Notfallereignisses für einen Patienten durchgeführt wurden und am Ende eine abschließende Ereignisdokumentation zu erhalten. Die meisten Krankenhäuser erfassen diesen Prozess in der Regel manuell auf Papier. Die mitgelieferte Software für Carts automatisiert diesen Prozess und ermöglicht die weitere Bearbeitung und das Hinterlassen von Kommentaren. Um einen unterbrechungsfreien Betrieb der Wagen während des Code Blue zu gewährleisten, wenn kein Internetzugang besteht oder die Wi-Fi-Verbindung zwischen dem Wagen und dem Tablet unterbrochen wird, haben wir den Offline-Modus implementiert.

Die Lösung ermöglicht die Durchführung der folgenden Phasen des Code Blue Prozesses:

Einleitende Informationen
Angabe des aktuellen Patientenzustandes (Puls, Ansprechbarkeit, Atmung), der Altersgruppe, des Gewichts und des Zeitpunkts, zu dem der Code Blue gestartet wurde.

Ereignisdokumentation
Auswahl und Dokumentation aller Ereignisse, die während des Code Blue für einen Patienten angewandt wurden, wie z. B. Auflistung des Rhythmus, Interventionen usw., wobei das System alle Aktivitäten ständig im Ereignisprotokoll aufzeichnet. Während des Code Blue passt das System die Zeitvorgaben automatisch an die Algorithmen des Advanced Cardiac Life Support (ACLS) an. Das System gibt auch Hinweise darauf, was in einer bestimmten Situation zu tun ist, indem es eine Reihe von notwendigen Maßnahmen anzeigt, wenn ein bestimmter Patientenzustand ausgewählt wird.

Zusätzliche Informationen
Nachdem der Code Blue-Prozess gestoppt wurde, können die Pflegekräfte allgemeine Patienteninformationen und Daten nach dem Ereignis mit dem Grund für die Beendigung des Code Blue eingeben und gleichzeitig die Teammitglieder und ihre Rollen angeben. Auf der Grundlage der eingegebenen Daten erstellt das System einen Abschlussbericht, der in der Patientenakte gespeichert wird.

Das zentrale System ermöglicht auch die Auswahl des Datumsbereichs, um Statistiken für alle Code Blue-Ereignisse auf der Grundlage bestimmter Kriterien zu visualisieren, um ein globales Bild der Patienten in einem Krankenhaus zu erhalten und Metriken in Form von Qualitätsberichten zu sammeln, die exportiert werden können.

Qualitätsberichte stellen eine Reihe von Parametern und Indikatoren dar, die es dem Krankenhauspersonal ermöglichen, Statistiken zu erstellen und die Effizienz von Code Blue zu bewerten. Die Daten werden in verschiedenen Arten von interaktiven Diagrammen dargestellt, die die berechneten Qualitätsparameter veranschaulichen. Das System erstellt die Qualitätsberichte auf der Grundlage der Ereignisse, die während des Codes im Ereignisprotokoll aufgezeichnet wurden.

Bestandsverwaltung

Jeder Wagen enthält Inventar - Medikamente und Verbrauchsmaterialien, die während eines Code Blue verwendet werden könnten. Das Inventar kann in das Tablett des Wagens gelegt werden, einen tragbaren Behälter mit verschiedenen Konfigurationen, wie z.B. die Anzahl der Taschen, die Größe der Taschen und ihre Anordnung, oder direkt in die Schublade des Wagens. Alles ist so konfiguriert, dass festgelegt werden kann, was genau und in welcher Menge in eine bestimmte Schublade gelegt werden soll. Auf der Grundlage der erstellten Regeln ermöglicht das System die Verwaltung und Nachverfolgung des Inhalts eines bestimmten Wagens zu einem bestimmten Zeitpunkt und des Verfallsdatums von Medikamenten und erzeugt bei Bedarf Warnmeldungen.

Da die Warenkörbe bis zu mehreren Wochen inaktiv bleiben können, bis ein Code Blue eintritt, müssen sie regelmäßig überprüft werden, um ihre Bereitschaft für den Code Blue Prozess sicherzustellen. Um diesen Prozess zu erleichtern, haben wir die Funktion Cart Check eingeführt. Das Pflegepersonal füllt täglich in regelmäßigen Abständen (z. B. alle 8 Stunden/12 Stunden/24 Stunden) mit Hilfe eines Tablets einen Fragebogen aus, um den Zustand des Wagens anhand definierter Kriterien zu überprüfen, die konfiguriert werden können. Zu diesen Kriterien gehören beispielsweise die Überprüfung des Verfallsdatums von Medikamenten, der Temperatur und der Luftfeuchtigkeit, ob ein Defibrillator vorhanden ist usw. Auf der Grundlage der in den Fragebogen eingegebenen Daten legt das System fest, ob zusätzliche Maßnahmen mit dem Wagen erforderlich sind, und erzeugt gegebenenfalls Warnmeldungen, die die Benutzer darüber informieren, was zu tun ist.

Für jeden wichtigen Prozess generiert das System Warnmeldungen und benachrichtigt die Benutzer durch den Versand von SMS und E-Mails über bestimmte Aktionen, die durchgeführt werden müssen. Zum Beispiel, wenn ein Medikament oder ein Vorrat abgelaufen ist, ein Einkaufswagen aufgefüllt werden sollte, ein unbefugter Zugriff auf eine Schublade eines Einkaufswagens, eine Inspektion des Einkaufswagens oder bestimmter Schubladen nach Code Blue erforderlich ist, usw. Warnungen werden sowohl im Warenkorbsystem als auch im Zentralsystem hervorgehoben, solange es mindestens eine ungelöste Warnung gibt.

EHR-Integration

Die Lösung kann mit internen EHR-Systemen von Einrichtungen des Gesundheitswesens integriert werden, um Code Blue-bezogene Patientendaten und Abrechnungsanforderungen zu übertragen und gleichzeitig allgemeine Patientendaten zu erhalten und Bestätigungsnachrichten über die erfolgreiche Lieferung der Bestellgebühr zu empfangen. Die Kommunikation zwischen EHR-Systemen und dem Zentralsystem der Lösung erfolgt über eine Schnittstellen-Engine eines Drittanbieters als Schicht zwischen beiden Systemen, die das HL7-Protokoll nutzt. Gleichzeitig können die Patientendaten im System manuell angelegt und verwaltet werden.

IoT-Hub

Azure IoT Hub ermöglicht eine sichere und zuverlässige Kommunikation zwischen der Lösung und den Wagen. Er dient dazu, einen Wagen im System zu registrieren und Konfigurationsparameter an ihn zu senden. Wenn ein Einkaufswagen in IoT Hub mit dem Device Provisioning Service (DPS) als Hilfsdienst registriert wird, wird dieses Ereignis von Azure Function erkannt, das einen eindeutigen Schlüssel für den Einkaufswagen generiert, ihn in Azure KeyVault speichert und ihn über Gerätezwillinge an den Einkaufswagen sendet - JSON-Dokumente, die Gerätezustandsinformationen einschließlich Metadaten, Konfigurationen und Bedingungen speichern. Azure IoT Hub verwaltet einen Gerätezwilling für jedes Gerät, das mit IoT Hub verbunden ist. Mithilfe dieses Schlüssels wird der Wagen während der Synchronisierung authentifiziert. Nach der erfolgreichen Registrierung des Wagens findet der erste Synchronisierungsprozess statt, und dann wird der Wagen zur Datenbank hinzugefügt und ist voll funktionsfähig. Sicherheit und HIPAA/FDA-Konformität

Die Sicherheit des Systems entspricht den gesetzlichen Anforderungen von HIPAA und FDA. Zu den Anforderungen gehören technische Sicherheitsvorkehrungen wie Benutzerauthentifizierung und -autorisierung, Datenprüfungskontrolle, Datenverschlüsselung/-entschlüsselung und das Fehlen von Schwachstellen in der Geschäftslogik.

Datenprüfung

Einige Systemeinheiten, wie Code Blue-bezogene Informationen, Schubladenzugangsdaten oder verschiedene Konfigurationseinstellungen werden einem Audit unterzogen. Der Audit-Prozess wird auf Datenbankebene aktiviert. Audit-Datensätze enthalten Informationen über den Autor der Änderung sowie deren Datum und Uhrzeit.

Authentifizierung und Autorisierung

Die Funktionalität des Systems erlaubt keinen unauthentifizierten Zugriff. Um das Sicherheitsniveau zu erhöhen, erfolgt die Abmeldung automatisch nach einer konfigurierten Zeitspanne. Um Brute-Force-Angriffe zu verhindern, gibt das System außerdem eine begrenzte Anzahl von Anmeldeversuchen vor. Ist diese Grenze erreicht, wird das Benutzerkonto deaktiviert. Um Versuche einer Sicherheitsverletzung zu erkennen, werden Aufzeichnungen über erfolglose Anmeldeversuche gespeichert und stehen für Analysen zur Verfügung. Um die Identität des Benutzers zu schützen, verlangt das System in festgelegten Abständen eine Änderung des Passworts und überprüft die Komplexität des Passworts.

Datenverschlüsselung

Alle Daten, die die Grenzen des Systems verlassen, werden verschlüsselt. Daher ist die HTTPs (TLS)-Verschlüsselung für die Datenübertragung aktiviert. Alle ePHI-Daten werden in der Datenbank in verschlüsselter Form gespeichert. Backups ganzer Datenbanken sind ebenfalls verschlüsselt.

Verfahren

Kommunikation

Das Team von Transition bestand aus dem Delivery Manager, dem Projektmanager, den Business Analysten, dem Solution Architect, dem UX/UI Designer, den Entwicklern und den QA-Ingenieuren. Der Kunde wurde durch den Product Owner vertreten, um die allgemeinen Anforderungen zu klären; der technische Leiter, um technische Fragen und Architekturangelegenheiten zu besprechen; und SVP nahm an Management-Meetings teil, um unseren Fortschritt zu klären und zu erfahren, ob es irgendwelche Risiken oder Hindernisse gibt. Später kam der Director of Engineering des Kunden hinzu, der die endgültige Entscheidung darüber traf, ob eine bestimmte Funktion entwickelt werden sollte.

Die Erfassung der Anforderungen erfolgte durch mündliche und schriftliche Kommunikation zwischen unseren Business-Analysten und dem Product Owner des Kunden. Der Product Owner, der über das entsprechende Wissen verfügt, teilte unserem Team die Produktvision des Kunden mit, und wir wandelten sie in Low-Level-Anforderungen um. Die besprochenen Anforderungen wurden analysiert und zu der in Confluence gespeicherten Software-Anforderungsspezifikation hinzugefügt. Die Spezifikation wurde von unserem Team (Business-Analysten, Entwickler und QA-Ingenieure) und dem Kunden auf Inkonsistenzen, Widersprüche und Mehrdeutigkeiten geprüft. Sobald die Anforderungen geklärt waren, wurden sie in Confluence festgehalten. Wenn es eine vom Kunden genehmigte Änderung gab, aktualisierten wir die erforderlichen Seiten entsprechend.

Unsere Business-Analysten hatten in der Regel zweimal wöchentlich mündlichen Kontakt mit dem Product Owner, wenn nichts Dringendes anstand, während die Gespräche zwischen den Managern beider Seiten einmal pro Woche stattfanden. Alle zwei Wochen, nach Abschluss eines jeden Sprints, hielten wir eine Demositzung ab, bei der unser gesamtes Team anwesend war und an der auch der technische Leiter und manchmal der SVP auf Kundenseite teilnahmen. Die technischen Leiter auf unserer Seite und auf der Seite des Kunden kommunizierten in der Regel einmal pro Woche.

Der Kunde war offen für unsere Ideen und schätzte unseren Input, was unserem Team eine gewisse Entscheidungsfreiheit gewährte. Wir organisierten gemeinsame Brainstormings in enger Abstimmung mit dem Kunden, durchdachten mögliche Umsetzungsoptionen und schlugen den praktikabelsten Weg vor, wobei wir sowohl die Lieferbedingungen als auch die finanzielle Seite des Projekts im Auge behielten. Es gelang uns, einen Kompromiss zu finden, und der Kunde hörte auf die Ansichten unseres Teams.

Agil

Das Entwicklungsteam arbeitete nach dem Scrum-Rahmenwerk und überprüfte in täglichen Besprechungen den Fortschritt auf dem Weg zum Sprint-Ziel. Am Ende eines jeden Sprints wurde ein Sprint-Review abgehalten, um das Inkrement zu überprüfen und das Product Backlog bei Bedarf anzupassen. Während des Sprint-Reviews tauschten sich unser Team und die Stakeholder des Kunden darüber aus, was im Sprint getan worden war. Die Sprint-Retrospektiven boten dem Team die Möglichkeit, sich selbst zu überprüfen und einen Plan für Verbesserungen zu erstellen, die im nächsten Sprint umgesetzt werden sollten. Um den Gesamtarbeitsumfang für die Releases effizienter zu planen und die Release-Termine genauer vorherzusagen, bewertete unser Team den Gesamtaufwand, der für die vollständige Implementierung eines Product-Backlog-Elements erforderlich ist, in Story-Points. Story-Points wurden in Abhängigkeit von der Komplexität der Arbeit, dem Arbeitsumfang und dem Risiko bzw. der Ungewissheit vergeben, was genauere Schätzungen ermöglichte, die Planungszeit reduzierte und die Teamleistung verbesserte.

Zunächst gingen wir von dem nach der Discovery-Phase vereinbarten WBS-Umfang aus und teilten die Aufgaben in Meilensteine auf. Während der Besprechung des Projektumfangs mit dem PO tauchten im Vergleich zur Discovery-Phase viele neue Details, Änderungen und Funktionen auf. Das konnte zum Beispiel passieren, wenn wir Produktrückmeldungen von Ärzten und Krankenschwestern erhielten oder wenn sich die Gesetzgebung änderte, so dass beispielsweise ein zusätzliches Ereignis in den Code Blue-Prozess aufgenommen werden musste. Wenn wir zusätzliche Anforderungen erhielten, passte sich unser Team den neuen Anforderungen an, schätzte die ungefähre Umsetzungszeit und besprach mit dem Kunden, wie sich dies auf den gesamten Prozess auswirken könnte. Die Freigabe wurde in mehrere Meilensteine aufgeteilt - wir richteten regelmäßige Softwarelieferungen für anschließende Tests durch den Kunden ein, um frühes Feedback von ihm zu erhalten.

Um einen Blick von außen auf unsere Arbeit zu werfen, beauftragte der Kunde ein externes Prüfungsunternehmen, das eine Reihe von Gesprächen mit unserem Team organisierte, an denen Business-Analysten, Projektmanager und technische Leiter teilnahmen. Wir wurden zu unseren Prozessen befragt, wie wir Entscheidungen treffen und wovon wir uns leiten lassen, welche Art von Dokumentation wir führen und wie wir Probleme in verschiedenen Situationen lösen. Die Auditoren untersuchten auch die allgemeine Codequalität und das CI/CD-Setup. Als Ergebnis erhielten wir sowohl von der Auditfirma als auch vom Kunden selbst ein positives Feedback, das uns bestätigte, dass sie mit unserer Zusammenarbeit sehr zufrieden sind.