--- { "title": "CMS-Compliance-Implementierung: Ein FHIR-Ansatz", "description": "Implementierung von CMS-Interoperabilitätsregeln auf einer FHIR-Grundlage: Integrationsadapter, Datenkonsistenz, Sicherheit und die Ergebnisse eines realen Projekts.", "date": "2023-01-16", "author": "Paul Chayka, WaveAccess", "reading-time": "11 min read", "tags": [ "Integrations", "Compliance" ], "seo-tags": [ "compliance", "fhir", "integration", "cms rules", "payers" ] } --- Stehen Sie vor der Notwendigkeit, CMS-konform zu werden? In diesem Artikel möchte ich Ihnen von unseren Erfahrungen berichten, wie wir das Legacy-Medizinsystem eines US-amerikanischen Krankenversicherungsunternehmens CMS-konform gemacht haben. Lassen Sie uns zunächst besprechen, was CMS-Compliance eigentlich bedeutet. Gemäß der [CMS Interoperability and Patient Access final rule (CMS-9115-F)](https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index) muss ein Krankenversicherungsplan, der mit CMS-Patienten arbeitet, den CMS-Regeln entsprechen. Kurz gesagt: Um CMS-konform zu werden, müssen Krankenversicherungen ihre Anbieterverzeichnisse, Abrechnungen, Formulare und klinischen Daten mit ihren Mitgliedern teilen. Das bedeutet, dass diese Krankenversicherungen konsistente medizinische Daten im FHIR-Format vorhalten und einen FHIR-konformen API-Zugang zu diesen Daten bereitstellen müssen. Schauen wir uns nun unsere praktischen Erfahrungen im Umgang mit einem US-amerikanischen Krankenversicherungsunternehmen an und wie wir dieses mithilfe einer auf Aidbox basierenden neuen Lösung FHIR-konform gemacht haben. Wir werden auch auf unsere spezifischen technischen Herausforderungen eingehen und Ihnen genau erläutern, wie wir diese Probleme gelöst haben. Dieser Artikel richtet sich an CTOs, technische Manager, Projektmanager, Teamleiter und andere technische Fachleute, die dafür verantwortlich sind, ihr Gesundheitsinformationssystem CMS-konform zu machen. Lesen Sie weiter, um mehr zu erfahren über: - Den Ursprung des CMS-Compliance-Projekts - Anforderungen an die Aidbox-basierte Integrationslösung - Verwendete Aidbox-Funktionalitäten und -Features - Integrationsherausforderungen - Struktur und Arbeitsablauf des Integrationsadapters Und eine kurze Anmerkung zu meiner Person: Mein Name ist **Paul Chayka**. Ich bin Teamleiter und Projektmanager bei WaveAccess und arbeite mit Gesundheitsinformationssystemen und FHIR-Integration. # Projektherkunft Lassen Sie mich Ihnen einen kurzen Überblick über den Projektursprung geben. Der US-amerikanische Krankenversicherungsplan sah sich mit der Notwendigkeit konfrontiert, CMS-konform zu werden, und begann nach einer FHIR-Plattform zu suchen. Man entschied sich für Aidbox und bat **Health Samurai**, eine [Aidbox-basierte Lösung](https://www.health-samurai.io/aidbox) in das bestehende digitale Ökosystem zu integrieren und die FHIR-Integration der medizinischen Daten gemäß den CMS-Regeln umzusetzen. Die Ergebnisse der ersten Analyse zeigten, dass die Struktur der medizinischen Daten im System des Kunden proprietär war und eine individuelle Integrationslösung erforderlich war. Daher bat Health Samurai WaveAccess **als Partnerunternehmen**, bei der Implementierung der benutzerdefinierten FHIR-Integrationen und der Integration der Lösung in die Kundenumgebung zu helfen. # Anforderungserhebung Der erste Schritt ist die Anforderungserhebung. Unser Team analysierte die Kundenanfragen und erstellte eine Liste von Anforderungen, die die zukünftige Integrationslösung erfüllen sollte: - Medizinische Daten sollten gemäß den vordefinierten [FHIR Implementation Guides](/articles/how-to-create-a-fhir-implementation-guide) von CMS in FHIR-Ressourcen konvertiert werden - Medizinische Daten sollten im FHIR-Format in [Aidbox](https://www.health-samurai.io/aidbox) gespeichert werden - Der Integrationsprozess sollte regelmäßig gemäß den von CMS vorgegebenen Zeitrahmen durchgeführt werden - Die Lösung sollte einen FHIR-konformen API-Zugang zu diesen Daten bereitstellen - Einige Datensätze sollten öffentlich zugänglich und einige sollten geschützt sein Entsprechend diesen Anforderungen ist das grundlegende Schema der Lösung nachfolgend dargestellt: ![integration pipeline](image-1.avif) Das Legacy-System sendet medizinische Daten im CSV-Format an die FHIR-Plattform. Diese Daten werden von der Integrationsschicht empfangen, die gleichzeitig die Rolle eines Adapters zwischen dem System und Aidbox übernimmt. In diesem Modul werden medizinische Daten in FHIR-Ressourcen umgewandelt und an [Aidbox](https://www.health-samurai.io/aidbox) gesendet, das auch eine FHIR-konforme API bereitstellt. Diese kann von Entwicklern von Mitgliederportalen und mobilen Anwendungen genutzt werden, um Mitgliedern Zugang zu ihren Daten zu ermöglichen. # Aidbox Aidbox ist eine FHIR-basierte, metadatengesteuerte Plattform. Sie kann als FHIR-Speicher verwendet werden, der gleichzeitig eine FHIR-API bereitstellt, sowie als Backend für das Gesundheitsinformationssystem. Aidbox bietet bestimmte Funktionalitäten und Features, die wir in diesem Projekt genutzt haben. Lassen Sie uns diese näher betrachten. ### FHIR-Speicher Als fortschrittliche FHIR-Speicherlösung kann Aidbox zur Speicherung aller Arten von FHIR-Ressourcen verwendet werden, einschließlich der in den FHIR Implementation Guides der CMS-Regeln verwendeten Ressourcen. Darüber hinaus bietet Aidbox zusätzliche Funktionen zur Ressourcenanpassung und zur Erstellung neuer Ressourcen. ### FHIR-API Aidbox stellt eine FHIR-API und ein [API-Gateway](/articles/using-api-gateway-with-fhir-api) bereit. Es erfüllt alle HL7 FHIR-RESTful-Anforderungen und verfügt über alle Standard-Suchparameter aus den FHIR-Ressourcen. Aidbox-Benutzer können Suchparameter auch anpassen und neue erstellen. ### Daten hochladen Aidbox bietet mehrere Möglichkeiten zum Hochladen von Daten: - [REST API](https://www.health-samurai.io/docs/aidbox/api-1/api). Eine REST API ist eine einfache Lösung zum Erstellen und Aktualisieren einer Ressource. Wenn Sie jedoch mehrere Datensätze gleichzeitig laden müssen, ist diese Methode nicht geeignet, da Sie eine große Anzahl von API-Aufrufen durchführen müssen. - [Batch Upsert](https://www.health-samurai.io/docs/aidbox/api-1/batch-upsert). Für mehrere Datensätze bietet Aidbox Batch Upsert an. Dies ermöglicht es Benutzern, alle Vorteile der CRUD-API für mehrere Datensätze zu nutzen. Diese Methode ermöglicht es, den Upload-Status jedes einzelnen Datensatzes zu kontrollieren. Aidbox validiert sofort die Konformität der Datensätze mit dem angegebenen Profil und führt für jeden Datensatz eine Historie. Wenn Sie eine wirklich große Datenmenge hochladen müssen, ist diese Methode nicht optimal, da alle zusätzlichen Funktionen den Upload verlangsamen. - [Bulk Import API](https://www.health-samurai.io/docs/aidbox/api-1/bulk-api-1/usdimport-and-fhir-usdimport). Wenn Sie Zehntausende von Datensätzen oder mehr hochladen müssen, ist es besser, die Bulk API zu verwenden. Sie ermöglicht das Hochladen einer unbegrenzten Datenmenge mit maximaler Geschwindigkeit. Allerdings wird die Datenvalidierung standardmäßig nicht durchgeführt und die Historie ist deaktiviert. Sie müssen die Qualität der hochzuladenden Daten im Voraus kontrollieren. Um Daten hochzuladen, müssen Sie eine NDJSON-Datei generieren und in ein Repository mit einem öffentlichen Link oder mit signierten URLs von Amazon S3 oder Google Cloud Storage hochladen. Alternativ können Sie Anmeldeinformationen für den Zugang zum Speicher in Aidbox hinzufügen. ### Sicherheit Aidbox wird mit einem integrierten Auth-Modul ausgeliefert, das folgendes bereitstellt: - Verschiedene Authentifizierungsserver-Implementierungen (OAuth 2.0 und OpenID) - Domänenübergreifende Autorisierung und ein Gruppenverwaltungsmodul - Registrierungs-/Anmeldeabläufe per E-Mail oder Telefonnummer - Anmeldung mit Google, Facebook, Auth0 usw. - Zugang per JSON Web Token für Aidbox als Ressourcenserver [Aidbox](https://www.health-samurai.io/aidbox) bietet ein flexibles Modell zur Anpassung von Anfrage-Autorisierungsregeln. Benutzer können eine Reihe von Prüfungen für alle eingehenden Anfragen deklarieren. Wenn die eingehende Anfrage diese Prüfungen erfüllt, gilt sie als „Autorisiert" und wird weiterverarbeitet. Andernfalls wird die Anfrage abgelehnt und der Client erhält den Fehler „403 Unauthorized". Diese Prüfungen werden mithilfe der AccessPolicy-Ressource deklariert. ### Deployment Aidbox wird mit einer **automatisierten** Cloud-Infrastruktur geliefert, die auf Kubernetes (K8s) für AWS, Azure und GCP aufgebaut ist und sofort einsatzbereite Lösungen für Backups, Monitoring und Logging bereitstellt. Diese Infrastruktur kann auch für das Deployment anderer Teile der zu entwickelnden Anwendung genutzt werden. Eine vollständige Liste der Aidbox-Infrastruktur-Features finden Sie in der nachstehenden Aufzählung: - Automatisierte CI/CD-Pipeline: Drone CI / Kustomize für K8s - Datenbankreplikation und Backups für hohe Verfügbarkeit und Disaster Recovery - Audit-Log basierend auf Elasticsearch / Kibana / Grafana - Monitoring basierend auf Prometheus & Grafana - Dateispeicher für die Ablage von Dateien und Dokumenten - SSL-Zertifikatmanager zur Gewährleistung der Datenverschlüsselung bei der Übertragung - Alle weiteren technischen HIPAA-Schutzmaßnahmen > Starten Sie mit dem Aidbox [FHIR Server](https://www.health-samurai.io/aidbox) für Datenspeicherung, Integrationen, Healthcare-Analysen und mehr, oder [beauftragen Sie unser Team](https://www.health-samurai.io/services) zur Unterstützung Ihrer Softwareentwicklung. ### Zusammenfassung Wie Sie sehen können, bietet Aidbox einen leistungsstarken [FHIR-Server](https://www.health-samurai.io/fhir-server), eine cloudbasierte Infrastruktur und eine sichere FHIR-konforme API. Es kann als End-to-End-Backend für ein modernes Gesundheitsinformationssystem dienen. In diesem Projekt standen wir jedoch vor zusätzlichen Herausforderungen, die uns dazu veranlassten, Aidbox um ein zusätzliches Integrationsmodul zu erweitern. Im nächsten Abschnitt gehen wir auf diese Herausforderungen ein und erläutern, wie genau unsere benutzerdefinierte Integrationslösung diese gelöst hat. [![Aidbox FHIR Platform](image-2.avif)](https://www.health-samurai.io/aidbox) # FHIR-Integrationsadapter ### Integrationsschicht Wie bereits erwähnt, entsprachen die medizinischen Daten des Kunden keinem Industriestandard. Aidbox verfügt über einen integrierten EDI-Adapter für die gängigsten Standards von Gesundheitsdaten wie HL7 v.2 und X12, aber in unserem Fall mussten wir eine individuelle Integrationslösung entwickeln. Zunächst erstellte mein Team eine Liste der wichtigsten Funktionalitäten für den zukünftigen Adapter: - Verbindung zur Datenquelle des Legacy-Systems - Konvertierung medizinischer Daten in FHIR-Ressourcen - Verbindung zu [Aidbox](https://www.health-samurai.io/aidbox) - Übertragung von FHIR-Ressourcen an Aidbox ### Allgemeine Struktur Im Standardfall sah die Architektur des Adapters folgendermaßen aus: ![FHIR adapter - first version](image-3.avif) Der Adapter empfing medizinische Daten aus dem Legacy-System, transformierte sie in FHIR-Ressourcen und übermittelte sie an Aidbox. Im Laufe der Entwicklung stießen wir auf zusätzliche Herausforderungen: - Das Legacy-System enthielt eine erhebliche Datenmenge. - Vorhandene medizinische Daten konnten sich im Laufe der Zeit ändern. - In den medizinischen Datensätzen gab es keine Primärschlüssel. - Das Legacy-System stellte keine Felder wie „lastModifyDate" oder andere Änderungsmarkierungen bereit. Daher mussten wir unseren Adapter verbessern, um diese Herausforderungen zu bewältigen. ### Datenkonsistenz Die Integrationsprozesse sollten regelmäßig ausgeführt werden. Wie können wir sicherstellen, dass die Daten in Aidbox konsistent sind? Die einfachste Option besteht darin, vor jeder Integration alle entsprechenden Daten aus Aidbox zu entfernen und die Daten von Grund auf neu hochzuladen. Der wesentliche Nachteil dieses Ansatzes ist die extrem lange Integrationszeit. In der Regel ändern sich Daten nicht stark, und wenn wir einen Weg finden könnten, Änderungen zu verfolgen und Daten zu überspringen, die sich im vorangegangenen Zeitraum nicht geändert haben, würde dies die Integrationszeit erheblich verbessern. Zunächst müssen wir die eingehenden Daten in neue und geänderte Daten aufteilen. Das Adapter-Schema sollte folgendermaßen aussehen: ![FHIR Adapter with versioning](image-4.avif) Aber wie können wir wissen, welche Datensätze neu sind und welche aktualisiert werden sollten? Denken Sie daran, dass in diesen Daten keine Primärschlüssel vorhanden waren. Um diese Herausforderung zu bewältigen, müssen wir ein neues History-Modul hinzufügen, das Hashes von Datensätzen berechnet und diese zusammen mit den FHIR-IDs speichert. Auf diese Weise können wir einen neuen Datensatz von einem bestehenden unterscheiden. Darüber hinaus können wir sogar feststellen, ob ein bestehender Datensatz geändert wurde, und unnötige Aktualisierungsoperationen überspringen. ### Datenspeicherung und Logging Um die Funktionalität des History-Moduls bereitzustellen, müssen wir die Hashes der Datensätze zusammen mit den FHIR-IDs im Datenspeicher ablegen. Der Adapter verwendet hierfür die PostgreSQL-Datenbank von Aidbox. Wir haben für jedes in den Integrationen verwendete FHIR-Profil eine separate History-Tabelle. Für die Logging-Funktionalität verwenden wir den ELK-Stack von Aidbox. In manchen Fällen muss der Integrationsadapter separat von Aidbox eingesetzt werden, beispielsweise wenn ein Kunde seinen medizinischen Datenspeicher nicht außerhalb seiner internen Umgebung exponieren möchte. In diesem Fall kann der Adapter separat in der sicheren Kundenumgebung installiert werden, während Aidbox cloudbasiert sein kann. Um die Anpassungsmöglichkeiten des Adapters zu erhöhen und das Sicherheitsniveau des Kunden zu wahren, haben wir daher eine Funktionalität hinzugefügt, die es ermöglicht, den Adapter als eigenständige Lösung zu installieren. Er kann eine benutzerdefinierte PostgreSQL-Datenbank zur Speicherung von Verlaufsdaten und eine benutzerdefinierte ELK-Instanz für das Logging verwenden. ### Adapter-Workflow Das endgültige Diagramm unseres Adapters ist nachfolgend dargestellt: ![FHIR Adapter workflow](image-5.avif) Zunächst liest der Adapter die Daten aus dem medizinischen Datenspeicher des Legacy-Systems; die Datenquelle kann dabei in verschiedenen Formen vorliegen. Am häufigsten verwendet wird beispielsweise die SQL-Datenbank. Nach der Datenextraktion konvertiert der Adapter die Daten in die FHIR-spezifizierten Ressourcen gemäß den erforderlichen Implementation Guides. Als Ergebnis erhält man einen Satz konsistenter FHIR-Ressourcen, die in Aidbox hochgeladen werden sollen. Nach dem Konvertierungsprozess berechnet die Lösung verschiedene Hashes für die resultierenden Ressourcen und vergleicht diese mit den Hashes der bereits hochgeladenen Ressourcen. Der Adapter bestimmt dann, welche Ressourcen in der vorherigen Integrationsiteration hochgeladen wurden und aktualisiert werden sollten, welche Ressourcen aus der vorherigen Integrationsoperation nun veraltet sind und welche Ressourcen neu sind. Schließlich lädt der Adapter neue und aktualisierte Ressourcen hoch bzw. aktualisiert diese und löscht veraltete. Gleichzeitig speichert er die Hashes der neuen Ressourcen in der Datenbank. Während des gesamten Prozesses stellt der Adapter Protokolle mit einer Beschreibung des aktuellen Schritts der Integrationsiteration bereit. ### Technische Details Der Adapter verwendet den folgenden Technologie-Stack: - Java 11 - PostgreSQL 11 - Spring 5, Spring Boot 2 - Hibernate 5, MyBatis 3 - Maven - Amazon S3, Google Cloud Storage - Kubernetes, Docker Das High-Level-Architekturdiagramm ist nachfolgend dargestellt: ![Technical details - diagram](image-6.avif) Der Integrationsadapter wird verwendet, um Daten aus der Datenquelle des Kunden zu extrahieren, diese Daten in den FHIR-Standard zu konvertieren und an Aidbox zu senden. Er kann die PG-Datenbank von Aidbox als Verlaufsspeicher sowie den ELK-Stack von Aidbox für das Logging verwenden. Alternativ kann diese Lösung separat von Aidbox eingesetzt werden. In diesem Fall kann der Adapter seine eigene PG-Datenbank und seinen eigenen ELK-Stack verwenden. Er verfügt außerdem über eine REST API zur manuellen Initialisierung der Integrationsprozesse. ### Technische Zusammenfassung Wir haben unseren FHIR-Integrationsadapter als Integrationserweiterung für Aidbox entwickelt. Es handelt sich um eine anpassbare Lösung mit einem Satz entwickelter Bibliotheken für die effiziente, schnelle und flexible Ausführung von Operationen zum Lesen von Daten aus verschiedenen Quellen, zur Konvertierung in FHIR-Ressourcen und zum Hochladen in Aidbox. Abschließend möchte ich die Vorteile des FHIR-Integrationsadapters aufführen: - Der Adapter nutzt und passt zuverlässige und sich weiterentwickelnde Bibliotheken an. Diese bieten eine große Anzahl von Möglichkeiten für die Interaktion mit Aidbox, die Konvertierung von Ressourcen und andere Features, die die Entwicklungszeit erheblich reduzieren können. - Der Adapter bietet sofort einsatzbereite Möglichkeiten zur Integration mit den gängigsten Datenquellentypen wie SQL-Datenbanken, S3-Speicher und anderen. - Der Adapter bietet verschiedene Möglichkeiten zur Interaktion mit Aidbox, sei es ein einzelner Ressourcen-Download, ein Batch-Download, ein Archiv-Download usw. - Der Adapter bietet eine inkrementelle Aktualisierungsfunktion, die es ermöglicht, bei jeder neuen Aktualisierungsiteration effizient nur die geänderten Ressourcen zu berechnen und zu laden. - Der Adapter bietet transaktionale Operationen und kontrolliert die Datenintegrität, sodass Aidbox keine inkonsistenten Ressourcen enthält. # Fazit In diesem Artikel haben wir unsere Erfahrungen bei der Unterstützung eines US-amerikanischen Krankenversicherungskunden bei der Einhaltung der CMS-Regeln geteilt. **Wir haben mit Health Samurai zusammengearbeitet** und [Aidbox](https://www.health-samurai.io/aidbox) mithilfe des FHIR-Integrationsadapters, den unser Team entwickelt hat, in das digitale Ökosystem des Kunden integriert. Als Ergebnis haben wir eine vollständig anpassbare FHIR-Integrationslösung entwickelt, die jeder Organisation, die mit Gesundheitsdaten arbeitet, helfen kann, diese in das FHIR-Format zu überführen und sie zeitnah und ohne großen Aufwand konsistent zu halten. Wenn Sie vor der Notwendigkeit stehen, CMS-konform zu werden, die FHIR-Integration umzusetzen oder einfach Fragen haben, kontaktieren Sie uns. Wir und das Health Samurai-Team helfen Ihnen gerne weiter. Um zu erkunden, wie CMS-Compliance in Ihre Systeme integriert werden kann, testen Sie die [kostenlose Version von Aidbox](https://www.health-samurai.io/aidbox#run). Sie bietet eine umfassende Umgebung zum Testen und Implementieren von Compliance-Maßnahmen und stellt alle erforderlichen Werkzeuge ohne Funktionseinschränkungen bereit. *Autor*: **Paul Chayka**, Healthcare-Lösungsexperte | Projektmanager und Teamleiter bei [WaveAccess](https://www.wave-access.com/) [![WaveAccess Logo](image-7.avif)](https://www.wave-access.com/) [![Aidbox FHIR Platform for CMS](image-8.avif)](https://www.health-samurai.io/contacts) Siehe auch: [21st Century Cures Act Compliance](/blog/21st-century-cures-act).