Prozesskopplung zwischen Laboren
Eine Referenzarchitektur aus unserem Forschungs- und Entwicklungsvorhaben zur Frage, wie Arbeitsprozesse über Organisationsgrenzen hinweg zusammenlaufen können, ohne dass ein Beteiligter sein System ändern muss.
Internes Forschungs- und Entwicklungsvorhaben
MedTech & HealthTech, Software & Architektur
Ausgangslage
Medizinische Labore arbeiten überwiegend in in sich geschlossenen, herstellergebundenen Systemen. Solange ein Labor für sich arbeitet, ist das unproblematisch. Sobald ein Prozess über die Grenze der eigenen Organisation hinausreicht, ändert sich das: Sobald ein zweites Labor, ein Einsender, ein Zulieferer oder eine Patientenschnittstelle beteiligt ist, wird die Verbindung in der Praxis von Menschen hergestellt. Listen werden übertragen, Rückfragen telefoniert, Zwischenstände in Tabellen geführt.
Das skaliert nicht, und es ist die Stelle, an der Fehler entstehen können.
Warum Standardformate das nicht lösen
Die naheliegende Annahme ist, dass es dafür längst Standards gibt. Das ist auch richtig: Die etablierten Formate für Auftrags- und Befunddaten sind flächendeckend im Einsatz, und sie ermöglichen den Austausch von Daten zwischen Organisationen zuverlässig.
Sie beschreiben aber nur Daten, nicht Prozesse. Ein Standardformat transportiert einen Auftrag und ein Ergebnis. Es sagt nichts darüber, in welcher Reihenfolge Schritte stattfinden müssen, welche Bedingung erfüllt sein muss, damit der nächste Schritt zulässig ist, was passiert, wenn ein Schritt ausfällt oder zu spät kommt, und wer an welcher Stelle die Verantwortung trägt.
Kausalität, Logik und zeitliche Abfolge sind in keinem dieser Formate enthalten. Genau diese drei Dinge sind aber das, was ein Arbeitsprozess ausmacht. Deshalb entsteht bei der Kopplung zweier Labore trotz vollständig standardkonformer Schnittstellen weiterhin Handarbeit.
Ein zweites Problem kommt hinzu. Die am Markt verfügbaren Lösungen sind auf das einzelne Labor als eigenständige Einheit hin entworfen. Sie gehen von einer Organisation aus, in der Zuständigkeiten, Berechtigungen und Datenhoheit einheitlich geregelt sind. In einer Kette aus mehreren Beteiligten trifft diese Annahme nicht mehr zu.
Der Ansatz
Wir haben in einem eigenen Forschungs- und Entwicklungsvorhaben untersucht, wie sich Arbeitsprozesse zwischen mehreren Beteiligten koppeln lassen, ohne dass einer von ihnen seine bestehende Systemlandschaft wesentlich ändern muss. Diese Bedingung war nicht verhandelbar: Ein Ansatz, der von den Beteiligten Umbauten an ihrem zentralen System verlangt, ist in der Praxis nicht umsetzbar.
Beteiligt waren bewusst zwei strukturell sehr unterschiedliche Labore: ein regional tätiges Labor mit angeschlossenen Praxisstandorten und ein Standort eines international tätigen Laborverbunds. Diese Heterogenität war nicht Zufall, sondern Bedingung. Eine Architektur, die nur für eine Organisationsform funktioniert, ist keine Referenzarchitektur.
Grundlage war eine systematische Aufnahme: welche Datenausprägungen und welche Arbeitsabläufe bei beiden Beteiligten tatsächlich existieren, nicht welche laut Dokumentation existieren sollten.
Architekturprinzipien
Der Prozess ist ein eigenes Artefakt
Das Prozessmodell wird getrennt vom Datenformat beschrieben und ist explizit versioniert. Es enthält Reihenfolgen, Vorbedingungen, Zustände, Zeitfenster, Auslöser und Zuständigkeiten. Erst dadurch wird ein Ablauf zwischen Organisationen überhaupt überprüfbar und nicht nur beschreibbar.
Bestandssysteme bleiben unangetastet
Die Anbindung erfolgt ausschließlich am Rand, über Adapter, die die vorhandenen Schnittstellen und Formate der jeweiligen Organisation bedienen. Kein Beteiligter muss sein zentrales System umbauen, und keiner verliert die Kontrolle darüber.
Vertraulichkeitsgrenzen sind Teil des Modells
Zwischen Beteiligten bestehen Schweigepflichten, Wettbewerbsverhältnisse und interne Geheimhaltungsvorgaben. Ein Prozess muss also über eine Stelle hinweg laufen können, an der bewusst keine Information fließt. Diese Unterbrechung ist kein Fehlerfall, sondern ein modellierter Zustand: Der nächste Beteiligte erfährt, dass er handeln kann, ohne zu erfahren, warum.
Datensparsamkeit wird definiert, nicht nachträglich gefiltert
Vor jeder Kopplung wird festgelegt, welche Daten in welcher Granularität die Organisationsgrenze überhaupt überschreiten. Der Rest verlässt das System nicht. Das ist keine Datenschutzmaßnahme im Nachhinein, sondern eine Entscheidung in der Architektur.
Rechtsraum ist ein Architekturparameter
Wo Daten liegen und verarbeitet werden, ist keine Betriebsentscheidung, die man später trifft. Sobald ein Beteiligter außerhalb des europäischen Rechtsraums verarbeitet, verändert das die zulässige Prozessführung. Das Hosting-Szenario wird deshalb gemeinsam mit dem Prozessmodell entworfen, nicht danach.
Nachweisbarkeit von Anfang an
Integritätsprüfung, Protokollierung, Wiederherstellbarkeit und regelmäßige Sicherheitsprüfungen einschließlich Penetrationstests gehören in den Entwurf, nicht in eine Härtungsphase am Ende. In einem System, das Befunddaten zwischen Organisationen bewegt, ist der Nachweis, was wann mit welchen Daten geschehen ist, Teil der Funktion.
Die vier Schichten
-
Anbindung. Adapter je Gegenstelle. Bedient die vorhandenen Formate, Protokolle und Übergabewege der jeweiligen Organisation, einschließlich der Geräteprotokolle, und kapselt deren Eigenheiten vollständig.
-
Übersetzung und Filter. Abbildung auf ein gemeinsames internes Modell, Vereinheitlichung von Bezeichnern und Einheiten, Anwendung der definierten Datenfilter. Was hier nicht durchgelassen wird, existiert für die weiteren Schichten nicht.
-
Prozess. Zustände, Auslöser, Bedingungen, Fristen, Eskalationen. Diese Schicht kennt keine Formate, sondern nur Abläufe, und ist deshalb unabhängig von den angebundenen Systemen austauschbar.
-
Betrieb und Nachweis. Protokollierung, Integritätsprüfung, Berechtigungen entlang der rechtlichen Struktur der Beteiligten, Sicherung und Wiederherstellung.
Der Sinn der Trennung liegt in der dritten Schicht. Solange Formatwissen und Prozesslogik in einem Modul liegen, muss jede neue Gegenstelle den Prozess mit anpassen. Getrennt bleibt der Prozess bestehen, und es kommt ein Adapter hinzu.
Was daran schwierig war
-
Die Balance zwischen konkret und allgemein. Eine Architektur, die exakt die Abläufe der beteiligten Labore abbildet, ist für alle anderen unbrauchbar. Eine, die nur den gemeinsamen Nenner abbildet, ist für niemanden brauchbar, weil Abläufe in der Diagnostik in ihren Abweichungen bestehen. Diese Spannung war die eigentliche Entwurfsaufgabe und ist nicht auflösbar, sondern nur austarierbar.
-
Konformität über den ganzen Ablauf, nicht pro Komponente. Die Anforderungen aus DSGVO und aus dem Schutz von Daten nach § 203 StGB gelten nicht für einzelne Bausteine, sondern für den vollständigen Prozess über alle Beteiligten. Ein Ablauf kann aus lauter zulässigen Einzelschritten bestehen und in der Summe unzulässig sein.
-
Bewusste Informationsbrüche. Dass ein Prozess an einer Stelle absichtlich keine Information weitergibt und trotzdem weiterläuft, war die technisch anspruchsvollste Anforderung. Sie widerspricht der Grundannahme praktisch jeder Prozessmodellierung, nämlich dass der nächste Schritt weiß, was vorher geschehen ist.
-
Vielfalt der Geräte- und Schnittstellenprotokolle. Die Streuung ist größer als es die Existenz von Standards vermuten lässt, und sie ist nicht durch eine einmalige Integration zu erledigen, sondern nur durch eine Architektur, die neue Abweichungen billig aufnimmt.
Belastbarkeit
Der Entwurf wurde nicht nur an konstruierten Beispielen geprüft, sondern an zeitkritischen Abläufen mit engen Fristen, wie sie bei der kurzfristigen Bearbeitung von PCR- oder genetischen Analysen auftreten. Solche Szenarien sind für einen Architekturentwurf besonders geeignet, weil unter Zeitdruck jede unnötige Abstimmungsschleife unmittelbar sichtbar wird.
Die Absicherung umfasste Penetrations- und White-Hat-Tests, ein Sicherungs- und Wiederherstellungskonzept sowie ein Konzept zur Integritätsprüfung.
Wofür wir das nutzen
Die Referenzarchitektur ist Eigenentwicklung und kein Kundenprojekt. Das war beabsichtigt: Sie soll gerade nicht auf einen Auftraggeber zugeschnitten sein, sondern als Ausgangspunkt für unterschiedliche Konstellationen dienen.
Anwendbar ist das Muster überall dort, wo mehrere Beteiligte an einem diagnostischen Ablauf mitwirken: Labore, die Analytik untereinander weitergeben. Verbünde, die Standorte mit unterschiedlicher Systemhistorie zusammenführen. Hersteller, die ihre Verfahren an die Abläufe vieler Labore anschließen wollen, ohne für jedes Labor eine Einzelintegration zu bauen. Einsender- und Patientenschnittstellen an einen Prozess, der über mehrere Organisationen läuft.
Wenn Sie an einer solchen Konstellation arbeiten, sprechen wir gern darüber, welche Teile davon auf Ihren Fall passen und welche nicht.
