Eine HIPAA-konforme Plattform für Teams zur Bewältigung der Opioid-Krise

Die Arbeit lebte auf Papier. Jeder Bezirk führte eigene Tabellen, daher ließ sich nichts vergleichen und kein Programm über eine einzelne Zuständigkeit hinaus bewerten.

Ein Mensch existierte nur, wenn jemand eine Überweisung ausstellte. Hatten Rettungsdienst oder Krankenhaus niemanden überwiesen, erfuhr das Team nie von der Person, und niemand wusste, wie viele Menschen so verloren gingen.

Übergaben zwischen Einrichtungen verschwanden. Eine Überweisung an eine Klinik oder ein Wohnprogramm war ein Anruf und eine Notiz im Notizbuch. Auf „Ist die Person dort angekommen?“ gab es keine Antwort, und genau diese Frage zählt.

Im Außendienst gab es gar kein System. Outreach findet in Autos, Notunterkünften, Zeltlagern und ländlichen Gegenden ohne Netz statt. Alles, was Internet brauchte, wurde zu einer zweiten Schicht, abends aus dem Gedächtnis erledigt.

Die regulatorische Hürde ist ungewöhnlich hoch. Daten zu Substanzkonsum fallen sowohl unter HIPAA als auch unter 42 CFR Part 2, das bei der Weitergabe strenger ist. Mehrere unabhängige Einrichtungen arbeiten mit derselben Person, und keine darf mehr sehen, als ihr zusteht.

Akveo hat drei Anwendungen entwickelt: eine mobile App für den Außendienst, eine Web-App, deren Funktionen sich nach der Rolle des Nutzers richten, und eine Super-Admin-Konsole zur Verwaltung aller Bezirke. Dahinter stehen eine Pipeline, die Daten aus Rettungsdienstsystemen abruft, und eine öffentliche API für Integrationen.

KI-Erkennung in jedem Rettungsdienstprotokoll

Jedes Einsatzprotokoll des Rettungsdienstes läuft jetzt durch das System, nicht nur die Fälle, die jemand überwiesen hat. Ein KI-Dienst markiert Protokolle, die nach einer substanzbezogenen Episode aussehen. Er arbeitet nur mit de-identifizierten Daten und liefert eine Entscheidung mit Konfidenz, Begründung und den wichtigsten Merkmalen, damit ein Mensch widersprechen kann. Structured Output hält die Klassifizierung reproduzierbar, und ein regelbasierter Fallback übernimmt, wenn das Modell nicht verfügbar ist.

Jeder Bezirk hat ein eigenes Regelprofil mit eindeutigen Ja- und Nein-Bedingungen, kalibriert mit klinischen Fachkräften des Bezirks an Live-Daten. Es trennt die echten Grenzfälle, etwa Verschlucken ohne weitere Anzeichen, Kinder, Alkohol ohne genannte Substanz, Überdosierungen verschriebener Medikamente und Haushaltschemikalien. Ein Fehler in die eine Richtung kostet das Team eine Fahrt, in die andere einen Menschen.

Die Daten kommen über vier Kanäle, weil niemand eine saubere API hat: ESO und ImageTrend, die zwei führenden Dokumentationsplattformen für den US-Rettungsdienst; HL7 v2 über MLLP mit mTLS und Deduplizierung; verschlüsselte E-Mail; und Webformulare mit eigenen Handlern pro Zuständigkeit.

Wir sind vom Werkzeug zur Arbeitsorganisation zu einer lebensrettenden Erkennungsplattform geworden.

Überweisungs-Workflow zwischen Einrichtungen

Eine Überweisung ist keine Nachricht, sondern eine Anfrage mit einem klaren Lebenszyklus, den beide Seiten sehen: nicht gesendet, gesendet, empfangen, angenommen, in Bearbeitung, abgeschlossen oder abgelehnt, nicht empfangen und storniert. Der Absender wird bei jedem Schritt benachrichtigt, sodass niemand mehr wegen des Status herumtelefoniert.

Zwei unabhängige Organisationen bearbeiten dieselbe Überweisung mit unterschiedlichen Rechten auf dieselben Felder. Das Recht an einem Feld hängt davon ab, wer man im Verhältnis zum Datensatz ist, in welchem Status er sich befindet und welchen Typ er hat. Die Logik steckt in einer eigenen Engine mit einer dokumentierten Zustandsmatrix, gegen die das Team testet, statt in Bedingungen, die über die Oberfläche verstreut sind.

Offline-First-App mit versionssicherer Synchronisierung

Ein Besuch im Keller, in einer Notunterkunft oder in einem Auto ohne Netz wird trotzdem erfasst. Das Telefon ist der echte Datensatz, kein Entwurf bis zur Rückkehr ins Büro. Ein Kontakt lässt sich unvollständig speichern, Pflicht sind nur Typ und Erfassungsart.

Geräte können wochenlang offline bleiben, während im Außendienst verschiedene App-Versionen laufen. Offline-Änderungen werden als Absicht gespeichert, als Befehl mit seiner Schemaversion, und beim Eintreffen auf dem Server auf das aktuelle Modell gehoben. In der Gegenrichtung erhält jedes Gerät Daten in dem Format, das seine Version versteht. Das Produkt hat sich ständig weiterentwickelt, und niemand im Außendienst musste nur für die Synchronisierung aktualisieren.

Die Synchronisierung lädt nur Änderungen herunter. Der Server führt für jede Entitätsfamilie eine eigene Uhr, und IDs werden auf dem Gerät erzeugt, sodass Offline-Datensätze den Weg zum Server überstehen und aufeinander verweisen können.

Die Patientenkarte enthält eine KI-Zusammenfassung, die abschnittsweise über Server-Sent Events gestreamt und nie gespeichert wird.

Kontextbasierte Zugriffskontrolle

Niemand konfiguriert Zugriffe von Hand. Man sieht einen Patienten, weil man in seinem Team ist, eine Aufgabe für ihn hat oder einen Besuch durchführt; endet die Arbeit, endet der Zugriff. Jede Freigabe speichert die Quelle, die sie erzeugt hat, damit sie automatisch entzogen und später erklärt werden kann. Zugriffsänderungen reisen mit den Daten: Ein Gerät erfährt, was es nicht mehr sehen darf, und löscht es.

Für einen Patienten, der der Fachkraft nicht zugewiesen ist, aber sofort Hilfe braucht, kann ein Bezirk einen kontrollierten Weg freischalten. Die Fachkraft findet die Person nur über den vollständigen Nachnamen, sieht eine streng begrenzte Auswahl an Feldern zur Identitätsprüfung und erhält Zugriff erst nach Bestätigung der geleisteten Hilfe. Die Freigabe wird in der Patientenhistorie als Zeitfenster festgehalten.

Es gibt sechs Rollen mit jeweils eigenem Zugriff auf Bereiche, und dieser Zugriff unterscheidet sich zwischen mobiler App und Web.

Mandantentrennung mit Row-Level Security

Alle Bezirke teilen sich ein Schema, und Row-Level Security in PostgreSQL beschränkt jede Anweisung auf den aktuellen Mandanten. Ist kein Mandant gesetzt, passt nichts, sodass ein Fehler ein leeres Ergebnis liefert statt der Daten eines anderen Bezirks. Die mandantenübergreifende Verwaltung liegt hinter einer separaten API mit eigener Rolle. Ein neuer Bezirk wird in einem Vorgang eingerichtet, der jeden Schritt in AWS und in der Datenbank zurückrollt, wenn einer fehlschlägt.

De-identifizierte Analyseschicht

Dashboards für Bezirke und Geldgeber laufen auf einem separaten de-identifizierten Schema. Datenbank-Trigger entfernen oder maskieren in Echtzeit alle 18 Identifikatoren nach HIPAA Safe Harbor. Datumsangaben werden auf Monat und Jahr gekürzt, Patienten-IDs werden zu Einweg-Hashes, sodass sich der Weg einer Person über die Zeit verfolgen lässt, ohne zu wissen, wer sie ist. Die Analysen eines Bezirks können keine Daten des Nachbarbezirks zeigen.

Echtzeit-Chat und SMS an Patienten

Die gesamte Kommunikation liegt in einem Bereich: SMS an Patienten, interne Patientenbesprechungen, Kanäle und Direktnachrichten, jeweils mit Zähler für Ungelesenes. SMS sind optisch und technisch getrennt, damit sie nicht mit Nachrichten an Kollegen verwechselt werden.

Jeder Bezirk hat eine eigene Nummer. Eine Patientenunterhaltung wird über die Telefonnummer statt über den Patienten zugeordnet, weil ein Telefon oft mehreren Menschen gehört. Der Chat läuft über eine Live-Verbindung, nur für Unterhaltungen, die der Nutzer sehen darf, mit Push-Benachrichtigungen bei geschlossener App.

Ein Domänenmodell für klinische und soziale Leistungen

Die Plattform deckt mehr als 30 Leistungsarten ab, die meisten davon nicht klinisch: Essen, Telefon, Kleidung, Notunterkunft, dauerhafte Wohnung, Nebenkosten, Dokumente, Versicherung, Rechtshilfe, Arbeit und Transport. Klinisch umfasst sie Suchtbehandlung, Schadensminderung, Spritzentausch, Wundversorgung, HIV- und Hepatitis-C-Tests sowie Psychiatrie.

Klinische Abläufe sind fest eingebaut, nicht angehängt: Buprenorphin-Einleitung mit der COWS-Skala und Einschätzungen nach Kalender, von der Erstbewertung über 2, 3, 7 und 14 Tage bis zu 1, 2, 3, 6 und 9 Monaten.