Die meisten mittleren und großen Organisationen betreiben mehrere Kernsysteme, die zu verschiedenen Zeitpunkten bei unterschiedlichen Herstellern gekauft wurden. Ein ERP hält Finanz- und Lieferdaten, ein CRM die Kundeninteraktionen, und im Gesundheitswesen enthält ein Krankenhausinformationssystem, meist HIS genannt, Patientenakten, Aufträge und Abrechnung. Die Verbindung dieser Systeme ist selten der sichtbarste Teil eines Projekts, entscheidet aber oft darüber, ob das Projekt termingerecht abgeschlossen wird. Dieser Artikel behandelt die häufigsten Probleme und die Vorgehensweisen, mit denen sie sich verringern lassen.

Warum Integrationsprojekte sich verzögern

Aufwandsschätzungen für Integrationen fallen tendenziell zu optimistisch aus, weil die Arbeit erst sichtbar wird, wenn sie beginnt. Vier Ursachen treten immer wieder auf.

  • Undokumentierte Felder. Eine Tabelle enthält eine Spalte für einen Zweck, an den sich niemand mehr erinnert, und ihre Bedeutung lässt sich nur klären, indem man die Person fragt, die sie vor Jahren konfiguriert hat.
  • Zwei führende Datenquellen. Kunden- oder Produktdaten liegen in beiden Systemen vor, und die beiden Bestände weichen voneinander ab. Jemand muss entscheiden, welcher gilt und nach welchen Regeln.
  • Batch gegen Echtzeit. Ein Fachanwender wünscht aktuelle Daten, das Quellsystem kann aber nur nachts exportieren, und die Lücke fällt erst spät auf.
  • Vom Hersteller kontrollierte Schnittstellen. Der Hersteller entscheidet, welche Schnittstellen verfügbar sind, was sie kosten und wann sie sich ändern. Das Integrationsteam hängt damit von fremden Terminplänen ab.

Schnittstellenoptionen

Die Wahl der Schnittstelle richtet sich danach, was das Quellsystem unterstützt und wie aktuell die Daten sein müssen. REST- und SOAP-Webservices sind der übliche Weg bei modernen ERP- und CRM-Produkten. Sie unterstützen den Austausch nach dem Anfrage-Antwort-Prinzip und lassen sich gut überwachen, setzen aber voraus, dass das Quellsystem die passenden Operationen anbietet.

Der Dateiaustausch ist weiterhin weit verbreitet. Zeitgesteuerte CSV- oder XML-Exporte sind einfach und robust und eignen sich für Berichte und nächtliche Synchronisation. Message Queues entkoppeln Sender und Empfänger, sodass eine Seite zeitweise nicht verfügbar sein kann, ohne dass Daten verloren gehen. Sie passen zu ereignisgesteuerten Abläufen, bei denen Reihenfolge und Zustellung wichtig sind.

Bei Gesundheitsdaten sind HL7-Nachrichten in Version 2 für Aufnahmen, Aufträge und Befunde nach wie vor üblich, und FHIR wird zunehmend für den API-basierten Austausch eingesetzt. Der Einsatz dieser Standards verringert das individuelle Mapping, auch wenn lokale Profile und Erweiterungen weiterhin mit jedem Hersteller abgestimmt werden müssen.

Datenmapping und Datenqualität

Das Mapping bildet den Kern der Arbeit. Für jedes Feld hält das Team Quelle, Ziel, Transformation und Konfliktregel fest. Codelisten, Einheiten, Datumsformate, Zeichenkodierungen und Kennungen verdienen besondere Aufmerksamkeit, da ein Patient, ein Kunde oder ein Produkt in jedem System eine andere Kennung tragen kann.

Datenqualitätsprobleme treten meist in dieser Phase zutage, etwa doppelte Datensätze, fehlende Pflichtwerte und Freitextfelder, die als Codes verwendet werden. Sie lassen sich am besten an der Quelle beheben, mit Bereinigungsregeln, die mit den Dateneigentümern vereinbart sind. Eine Korrektur innerhalb der Schnittstelle macht sie unsichtbar und sollte vermieden werden.

Sicherheit und Nachvollziehbarkeit

Integrationskonten sollten dem Prinzip der minimalen Rechte folgen und nur Zugriff auf die Operationen haben, die die Schnittstelle benötigt. Jeder Aufruf, der personenbezogene Daten liest oder ändert, sollte mit Benutzer, Vorgang und Zeitpunkt protokolliert werden. Die Protokolle sind zu schützen und gemäß der Richtlinie aufzubewahren.

Personenbezogene Daten unterliegen in der Türkei dem KVKK und in der EU der DSGVO. Für Gesundheitsdaten gelten strengere Anforderungen. Das Integrationsdesign sollte festlegen, welche Daten zu welchem Zweck übertragen werden, wie sie bei der Übertragung und im Ruhezustand geschützt sind und wie lange Kopien aufbewahrt werden.

Tests und Rollback

Schnittstellen sollten mit realistischen Daten getestet werden, einschließlich Grenzfällen wie langen Namen, Sonderzeichen, stornierten Aufträgen und korrigierten Befunden. Testumgebungen, die die Produktivversionen beider Systeme abbilden, sind wertvoll, weil sich das Verhalten zwischen Versionen oft unterscheidet. Ein Umstellungsplan sollte die Reihenfolge der Schritte, die Prüfungen nach jedem Schritt und die Bedingungen für die Rückkehr zum vorherigen Zustand festlegen.

Betrieb nach der Inbetriebnahme

Eine Schnittstelle ist ein laufender Dienst. Sie braucht Monitoring für Fehler und Verzögerungen, eine Fehlerwarteschlange, in der abgewiesene Nachrichten geprüft und erneut eingespielt werden können, und Alarme, die eine benannte Person erreichen. Jede Schnittstelle sollte auf fachlicher und auf technischer Seite einen Verantwortlichen haben, dazu eine Dokumentation zu Zweck, Zeitplan, Mapping und bekannten Grenzen. Fehlt dies, summieren sich kleine Fehler, bis die Daten in den beiden Systemen nicht mehr übereinstimmen.