Entwicklung einer HIPAA-konformen Rules-Engine für textbasierte Dienstleistungen
Das MedTech-Start-up Jiseki Health bietet einen Concierge-Service, der Kunden dabei unterstützt, die Kontrolle über ihre Gesundheit zu erlangen und ihr Wohlbefinden zu verbessern. Zu den bedeutendsten Kunden des Unternehmens zählen mitunter mehrere große amerikanische Versicherungsgesellschaften. Die von Jiseki entwickelte Lösung kommt auch in den Fabriken von Tesla zum Einsatz. Jiseki ist der erste und einzige Anbieter für Ganzpersonenpflege („Whole-Person Care“), der sich speziell an benachteiligte Einzelpersonen und Gemeinschaften richtet. Das Start-up betreibt einen Full-Stack-Multi-Tenant-Marktplatz, der durch Gleichheit in puncto Gesundheit überzeugt und alle sozialen Determinanten in diesem Bereich berücksichtigt sowie einen personenzentrierten Ansatz bei der Erbringung von Pflegeleistungen verfolgt.
Das Unternehmen erkennt die Risiken, die mit einer standardisierten Versorgung verbunden sind, und setzt Strategien zur Verbesserung der Bereitstellung personenzentrierter Pflege um. Dies regt ein größeres Engagement der Mitglieder zur Beteiligung an gesunden Verhaltensweisen an. Die Mitglieder erhalten über Textnachrichten, Video- sowie Sprachanrufe, WhatsApp, Webdienste und auch persönlich Zugang zu bequemer Ganzpersonenpflege. Die Plattform von Jiseki stellt die Infrastruktur für ein Versorgungssystem im Bereich der persönlichen Pflege dar, das die Mitglieder mit virtueller Pflege, physischen Kliniken und gemeinschaftlichen Pflegeeinrichtungen verbindet.
Die Herausforderung
Kurz bevor das Team von Jiseki sich an uns wandte, präsentierte es seinen Kommunikations- und Koordinierungsservice, der darauf abzielte, telemedizinische Dienste für eine große Zahl von Menschen bereitzustellen. Sie suchten nach einem Technologiepartner, der ihnen dabei helfen konnte, ihre Demo Wirklichkeit werden zu lassen, einige Verbesserungen im Backend vorzunehmen, um so die Skalierung des HealthTech-Start-ups zu ermöglichen, und einige neue Funktionen zu realisieren. Ihr primäres Ziel war allerdings, eine Dashboard-Lösung und eine Rules-Engine zu entwickeln, um ausgehende Nachrichten an Mitglieder, Patienten und Dienstleister zu steuern und zu generieren, die mit ihnen interagierten.
Die Business-Rules-Engine würde allen Benutzern helfen, einschließlich der medizinischen Fachleute und Vertreter der bei dem Dienst registrierten Unternehmen, der Epidemiologen und Agenten, welche die zu implementierenden Nachrichtenregeln festlegen, sowie der Mitglieder des Dienstes und Patienten, welche die Nachrichten erhalten. Früher wurden Kommunikations-, Messaging- und Benachrichtigungsprozesse zwischen den Mitgliedern der Plattform manuell über reguläre Textnachrichten realisiert, aber als Tesla und mehrere andere große Kunden sich mit dem Dienst zusammenschlossen, wurde es notwendig, den Vorgang mithilfe automatisierter Messaging-Systeme zu optimieren.
Die Aufgabe
Jiseki rechnete mit einer großen Anzahl an Benutzern, die am System teilnehmen würden. Da es sich beim Hauptservice um eine textbasierte Lösung für die Ganzpersonenpflege handelte, wollte das Unternehmen die Arbeitskosten und die für ausgehende Textnachrichten erforderlichen Ressourcen reduzieren. Das Start-up wünschte sich automatisierte Nachrichten, welche die Benutzer dazu anregen, sich an einen gewissen Anbieter zu wenden oder eine bestimmte Aktion durchzuführen. Die Rules-Engine würde also dazu verwendet werden, die Anforderungen für diese ausgehenden Nachrichten festzulegen: Falls dies „wahr“ und das „wahr“ ist, sollte „jenes“ nach X Tagen verschickt werden, nachdem X eintritt.
Die Aufgabe bestand im Wesentlichen darin, die technische Lösung zu beschreiben und zu entwerfen, Empfehlungen für die Architektur und den Stack der Messaging-Rules-Engine abzugeben und diese von Grund auf zu entwickeln, wobei Potenzial für zukünftige Skalierung sowie Flexibilität gegeben sein sollte.
Entwicklung der Rules-Engine
Der Kunde trat mit seiner Idee an uns heran. Wir definierten die Anforderungen und gestalteten das PRD. Nach sorgfältiger Untersuchung der Spezifikation und Recherche der Best Practices für ein automatisiertes Nachrichtensystem für telemedizinische Apps hatten wir eine Lösung, um die Rules-Engine auf die für die Benutzer bequemste Art und Weise zu implementieren. Wir haben die Lösung gemeinsam mit dem Kunden erstellt, den User-Flow und die Benutzerszenarios vorbereitet, die Dashboard-Mock-ups gezeichnet und eine regelbasierte Python-Engine zur Ausführung von Regeln nach einem bestimmten Algorithmus entwickelt.
Wir bestimmten, dass es drei Hauptphasen der Rules-Engine-Funktionalität geben sollte: das Festlegen der Regel, das Ausführen einer Aktion und das Planen oder Auswählen des Runners (Zeitplan, nachdem die Aktion ausgeführt werden soll). Es folgt ein praktisches Beispiel: Die Anbieter medizinischer Dienstleistungen treffen die Entscheidung, dass eine bestimmte Gruppe von Patienten, die in einem gewissen Gebiet oder Staat leben, sich für einen regelmäßigen Gesundheitscheck registrieren muss. Dann verwendet der Epidemiologe die von uns entwickelte Rules-Engine, um die Daten einzugeben und jene Regeln festzulegen, die diese Patientengruppe definieren. Anschließend wird die Aufgabe erstellt, eine automatisierte Nachricht an alle Mitglieder dieser festgelegten Gruppe zu verschicken, z. B. eine SMS an alle weiblichen Mitarbeiter einer bestimmten Firma im Alter von 20 bis 35 Jahren, die diese daran erinnert, sich in 7 Tagen für eine Untersuchung in der Klinik zu registrieren.
Die Rules-Engine erfüllt alle angegebenen Regeln sowie Aktionen und die Patienten erhalten automatisch hilfreiche Nachrichten/Benachrichtigungen. Bei den Eingabedaten handelt es sich hauptsächlich um Gesprächsdaten, aber in Zukunft wird es möglich sein, Notizen, Beurteilungen, EMR-Angaben, Laborwerte, Rezeptinformationen und einige demografische sowie finanzielle Überlagerungen einzugeben.
Der Kunde verwendete Druid, eine verteilte spaltenorientierte Datenbank, um alle notwendigen Daten zu speichern. Druid ist eine sehr flexible Engine, die schnelle Ad-hoc-Abfragen ermöglicht. Deshalb haben wir die neue Messaging-Engine mit dem Druid-Analysesystem verbunden.
API-orientierte Architekturentwicklung
Während die Entwicklung der Messaging-Engine weitestgehend unkompliziert zu sein schien, gab es einige Vorbehalte, die umsichtig behandelt werden mussten. Die meisten von ihnen betrafen die Arbeit mit den Daten über eine API.
So mussten wir beispielsweise alle Daten aus der EMR über die REST-API zugänglich machen. Das einzige exportfähige Datenformat im Gesundheitswesen ist jedoch HL7, sodass wir uns auf die Rationalisierung des Datenaustauschprozesses unter Verwendung der HL7-API konzentrieren mussten. Mithilfe der HL7-FHIR-API haben wir das Datenformat in eine für die Messaging-Engine geeignete Aufmachung konvertiert.
Unser Rules-Engine-Design übermittelt einen Call über die REST-API an den Dienst des Unternehmens, damit dieser eine Textnachricht an ein Mitglied senden kann. Die Rules-Engine allein verfügt über keine direkte Verbindung zu einem SMS-Serviceprovider oder Messaging-Dienst.
Die Regelausführung umfasst mehrere API-Aufrufe zu dem Zeitpunkt, an dem die Regel als „wahr“ bewertet wird. Wenn die Messaging-Engine zum Beispiel eine Dankesnachricht verschickt („Danke, dass Sie unsere Umfrage ausgefüllt haben. Wir melden uns in Kürze bei Ihnen“), übermittelt sie auch einen API-Call, um das Mitglied in die Prioritätsliste (im Agenten-Dashboard) aufzunehmen. Außerdem wird eine Meldung für den Agenten erstellt.
Wir haben weiterhin Mechanismen implementiert, die es ermöglichen, ein analytisches Dashboard auf ELK-Basis zu organisieren. Auf diesem Wege kann nachvollzogen werden, wie gut die Regeln funktionieren. Statistiken über die Umsetzung der Regeln sind dort ebenfalls einsehbar. In zukünftigen Versionen wird der Kunde in der Lage sein, zufällige oder kontrollierte Tests durchzuführen und die Ergebnisse zu bestimmen.
Die Regeln der Messaging-Engine werden auf alle Benutzerbasen angewendet und neue User werden dem System automatisch hinzugefügt. Alles, einschließlich angehängter Daten, wird über eine API bezogen, sodass keine Informationen manuell hinzugefügt werden müssen. Darüber hinaus haben wir einen Mechanismus zum Abgleich von Benutzerdaten mit der internen Struktur des Dienstes entwickelt, um die Systemwartung zu erleichtern und die Notwendigkeit entwicklerseitiger Hilfe beim Hinzufügen zusätzlicher Daten zu reduzieren.
Regelplanung
Die Regeln können so geplant werden, dass sie zu bestimmten Zeiten ausgeführt werden. Alternativ ist auch die Auslösung auf Grundlage bestimmter Aktivitäten möglich. Ein Beispiel: Nachdem ein Mitglied im System aktiviert und das Onboarding durchgeführt wurde, sendet die Messaging-Engine ihm eine Einladung zu einer bestimmten Umfrage. Diese wird immer am dritten Tag verschickt. Unmittelbar im Anschluss an die Teilnahme kann Jiseki dem Mitglied jedoch eine Dankesnachricht schicken und abhängig von den Ergebnissen der Umfrage ist es möglich, nach fünf Tagen eine Mitteilung zu einem bestimmten Thema folgen zu lassen. Falls Jiseki ein Mitglied zu einer Umfrage einlädt und dieses die Einladung nicht annimmt, wird am siebten Tag automatisch eine Erinnerung verschickt.
Technologiestack
Der Dienst wurde mit Python implementiert, während die REST-API für den Client in Django und DRF geschrieben wurde. Airflow wird gemeinsam mit Celery und Redis genutzt, um Aufgaben auszuführen sowie Regeln zu planen. Die Admin-Benutzeroberfläche wurde mit Django erstellt, während Postgresql zum Speichern von Daten verwendet wird und DynamoDB die Interaktion zwischen den Dienstkomponenten organisiert. Die Bereitstellung wurde mit Docker sowie Docker Compose für die lokale Entwicklung und Kubernetes als Produktionsinfrastruktur realisiert.
Das System musste in ein einfaches Interface verpackt werden, das es den Benutzern ermöglicht, Messaging-Regeln festzulegen und zu verwalten. Daher haben wir mithilfe von React eine Control-Interface-Application erstellt.
Unter Einsatz von React und Typescript haben wir eine Anwendung zur Verwaltung von Kundenbenachrichtigungsregeln entwickelt. Wir haben im Rahmen dieser Anwendung nicht den Global State verwendet, sondern auf den Global Cache im Zusammenspiel mit React Query gesetzt. Dadurch konnten wir die Anwendungsarchitektur vereinfachen und die Menge an Code für die Interaktion mit dem Server erheblich reduzieren.
HIPAA-Konformität
Eine einzigartige Herausforderung, mit der wir uns bei der Entwicklung der Telemedizin-Plattform konfrontiert sahen, war der Umgang mit Daten in Übereinstimmung mit den HIPAA-Vorschriften. Der HIPAA legt die Standards für den Schutz sensibler Patientendaten fest. Da das System mit geschützten Gesundheitsinformationen arbeitet, mussten wir Sicherheitsvorkehrungen treffen, welche die HIPAA-Konformität gewährleisten. Entsprechend war es notwendig, mehr als nur die üblichen Schutzmaßnahmen für Messaging-Engines zu ergreifen. Die ungewöhnlichsten Daten, mit denen wir zu tun hatten, waren EMR-Informationen, da sie ausschließlich ins HL7-Format exportieren werden konnten. Also haben wir alle Daten standardisiert und in eine HIPAA-konforme Datenbank eingetragen, auf welche die Rules-Engine zugreifen konnte.
Wie sieht das Ergebnis aus?
Wir haben die erste Version des Produkts vollständig entwickelt, die Geschäftsanforderungen ausgearbeitet, das Interface entworfen und die technische Architektur des Dienstes gestaltet.
Jiseki rechnet nach Liveschaltung des Service mit einer Benutzerbasis von 40.000 bis 60.000 Usern. Das Unternehmen möchte im Wesentlichen kontinuierlich Versuche durchführen, verschiedene Interventionsmuster testen, die Ergebnisse messen und feststellen, was funktioniert und was nicht. Es ist geplant, die Anwendung der Regeln einzugrenzen. In der von uns entwickelten ersten Version sind die Regeln universell, aber in späteren Versionen werden sie weiter verfeinert und auf Grundlage bestimmter Statistiken sowie KI-Modelle für jede Person unterschiedlich sein.
Das langfristige Ziel von Jiseki ist es, die Mitglieder besser zu verstehen und den Service auf deren spezifische Bedürfnisse zuzuschneiden. Das Team von Evrone freut sich darauf, weiterhin neue Dienste und Lösungen zu implementieren, um Jiseki dabei zu unterstützen, bessere personenzentrierte Pflegedienste anzubieten. Kontaktieren Sie uns, um weitere Informationen über die besten neuen Funktionen in telemedizinischen Apps zu erhalten oder um herauszufinden, wie wir Ihnen bei der Entwicklung Ihres MedTech-Start-ups behilflich sein können!