Wir entwickelten für ein Unternehmen eine webbasierte Medizinische Bildplattform für den Operationssaal. Über die Plattform werden medizinische Apps für Bild, Video und Streaming bereitgestellt. Unser Beitrag umfasste die Architekturkonzepte für agile Teams, die Entwicklung hochverfügbarer Microservices sowie die Arbeit an einem Event-Bus für den Austausch von Ereignissen zwischen Systemteilen.
Ausgangslage
Ein Unternehmen benötigte eine webbasierte Plattform für den Operationssaal, über die medizinische Apps für Bild, Video und Streaming bereitgestellt werden.
Dafür war eine technische Grundlage nötig, die zu einer verteilten Anwendungslandschaft mit mehreren Teams passt. Zu unserer Aufgabe gehörten Architekturkonzepte auf Basis von Domain-Driven Design und einer ereignisgesteuerten Architektur für agile Teams.
Lösung
Wir erarbeiteten Architekturkonzepte für agile Teams und setzten sie in der Entwicklung zentraler Plattformbausteine um. Ein Schwerpunkt lag auf hochverfügbaren Microservices in C# und .NET Core, darunter ein medizinisches Bildarchiv. Microservices sind kleine, fachlich abgegrenzte Dienste, die zusammen eine größere Anwendung bilden.
Außerdem entwickelten wir einen Event-Bus mit RabbitMQ und Apache Kafka. Ein Event-Bus verteilt fachliche Ereignisse zwischen Systemteilen, damit diese lose gekoppelt zusammenarbeiten können. Ergänzend übernahmen wir die Leitung von Architektur-Boards und Mentoring. Die Umsetzung lief von Juni 2016 bis März 2019 mit einer Teamgröße von 7.
Ergebnis
Geliefert wurde eine webbasierte Plattform für den Operationssaal, über die medizinische Apps für Bild, Video und Streaming bereitgestellt werden.
Zu unserem Projektbeitrag gehörten Architekturkonzepte für agile Teams, hochverfügbare Microservices, ein medizinisches Bildarchiv, ein Event-Bus mit RabbitMQ und Apache Kafka sowie die Leitung von Architektur-Boards und Mentoring. Das Projekt lief über 34 Monate und wurde im März 2019 abgeschlossen.
Technik
Zum Einsatz kamen C# und .NET Core für die Entwicklung hochverfügbarer Microservices.
- Microservices als Architekturansatz für fachlich getrennte Dienste innerhalb der Plattform
- DDD für die fachliche Strukturierung der Domäne; Domain-Driven Design ordnet Software entlang der Fachlogik
- CQRS für die Trennung von Lese- und Schreibvorgängen; das kann komplexe Fachprozesse klarer strukturieren
- RabbitMQ und Apache Kafka für den Event-Bus
- Angular für die Weboberfläche der Plattform und ihrer Anwendungen im Rahmen der Webentwicklung
- Service Fabric für den Betrieb verteilter Dienste
- Azure DevOps zur Unterstützung der Entwicklung
- T-SQL für datenbanknahe Arbeiten
- OIDC, MFA und PKI für Anmeldung, zusätzliche Absicherung und Zertifikatskonzepte
- SpecFlow für verhaltensorientierte Tests; damit werden Anforderungen in einer für Fachseite und Team lesbaren Form beschrieben
Warum eine Medizinische Bildplattform so aufgebaut wird
Eine Medizinische Bildplattform für klinische oder operationsnahe Abläufe muss meist sehr unterschiedliche Anforderungen zusammenbringen. Einerseits erwarten Fachbereiche eine einheitliche Oberfläche, über die Bilder, Videos, Streams und weitere Funktionen erreichbar sind. Andererseits entstehen solche Systeme oft nicht als einzelner Monolith, sondern als Verbund mehrerer fachlicher Bausteine. Ein Monolith ist eine Anwendung, in der viele Funktionen eng in einem großen Systemblock zusammengefasst sind. Gerade wenn mehrere Teams an einer Plattform arbeiten, ist eine saubere fachliche und technische Trennung meist hilfreich.
Für solche Vorhaben eignet sich häufig eine Architektur mit fachlich abgegrenzten Diensten und klar beschriebenen Ereignissen. Das Ziel ist nicht technische Komplexität um ihrer selbst willen, sondern beherrschbare Veränderung. Wenn ein Teilsystem Bilder verwaltet, ein anderes Medienströme bereitstellt und ein weiteres Berechtigungen prüft, sollten diese Teile möglichst lose gekoppelt sein. Lose Kopplung bedeutet, dass Änderungen in einem Teil nicht unnötig viele andere Teile nach sich ziehen. Das erleichtert Abstimmung, Weiterentwicklung und Betrieb.
Auch die Fachmodellierung ist bei einer medizinischen Bildplattform wichtig. Domain-Driven Design strukturiert Software nach fachlichen Begriffen und Verantwortlichkeiten, statt nur nach technischen Schichten. So lassen sich Regeln, Zustände und Ereignisse näher an den tatsächlichen Abläufen abbilden. Das ist vor allem dann nützlich, wenn verschiedene Beteiligte aus Fachseite, Produktverantwortung und Entwicklung dieselben Begriffe verwenden sollen.
Ebenso wichtig ist die Frage nach Verfügbarkeit und Sicherheit. In solchen Projekten müssen Anmeldung, Rollen, geschützte Kommunikation und belastbare Betriebsabläufe von Anfang an mitgedacht werden. OIDC ist ein Standard für die Anmeldung über einen zentralen Identitätsdienst. MFA ergänzt die Anmeldung um einen weiteren Nachweis. PKI organisiert digitale Zertifikate für vertrauenswürdige Kommunikation. Welche Anforderungen im Einzelfall gelten, sollte bei sensiblen Daten zusätzlich mit den zuständigen Stellen für Informationssicherheit, Datenschutz und Recht geprüft werden.
Bei der technischen Umsetzung kommen oft Datenbankentwicklung, Schnittstellen und ereignisgesteuerte Kommunikation zusammen. Ein Event-Bus überträgt fachliche Ereignisse zwischen Diensten. Das ist besonders dann sinnvoll, wenn Informationen nicht nur in einer Maske erscheinen, sondern von mehreren Systemteilen verarbeitet werden. Für Entscheider ist dabei weniger die einzelne Technologie entscheidend als die Frage, ob Architektur, Datenmodell und Betrieb später Erweiterungen tragen, ohne dass die Plattform bei jeder Änderung grundlegend umgebaut werden muss.
So entsteht eine Plattform für Bild, Video und Streaming
Ein Projekt dieser Art beginnt typischerweise nicht mit der Auswahl einzelner Werkzeuge, sondern mit einem gemeinsamen Verständnis der Aufgaben. Zunächst wird geklärt, welche fachlichen Abläufe unterstützt werden sollen, welche Nutzergruppen mit der Plattform arbeiten und welche Systemgrenzen gelten. Bei einer Plattform für Bild, Video und Streaming ist außerdem wichtig, wo Daten entstehen, wie sie bereitgestellt werden und welche anderen Systeme beteiligt sind. Erst auf dieser Grundlage lässt sich eine belastbare Zielarchitektur beschreiben.
Danach folgt meist die Konzeption der Fachbereiche und ihrer Verantwortlichkeiten. Dabei werden Begriffe vereinheitlicht, Zuständigkeiten festgelegt und Schnittstellen beschrieben. Schnittstellen sind definierte Übergänge, über die Systeme Daten oder Funktionen austauschen. In verteilten Systemen sollten diese Übergänge früh präzise formuliert werden, damit Teams unabhängig arbeiten können, ohne aneinander vorbeizuentwickeln. Gerade bei mehreren Beteiligten hilft es, Architekturentscheidungen nachvollziehbar zu dokumentieren und regelmäßig gemeinsam zu prüfen.
In der Umsetzung werden die Plattformbausteine schrittweise entwickelt und laufend abgestimmt. Häufig entstehen zunächst zentrale Dienste, etwa für Anmeldung, fachliche Kernfunktionen, Datenhaltung und den Austausch von Ereignissen. Darauf bauen Oberflächen und weitere Funktionen auf. Für browserbasierte Fachanwendungen ist Webentwicklung oft der passende Weg, weil sich Funktionen zentral bereitstellen und aktualisieren lassen. Parallel dazu wird der spätere Betrieb vorbereitet. Betrieb meint nicht nur Hosting, sondern auch Überwachung, Fehlersuche, Freigaben und kontrollierte Änderungen im laufenden System.
Typisch ist außerdem eine Qualitätssicherung, die Fachlogik und Zusammenspiel prüft. Neben klassischen Tests gewinnen dabei fachnah formulierte Prüfszenarien an Bedeutung. Sie helfen, Missverständnisse früh zu erkennen. In komplexen Plattformen ist das besonders relevant, weil Fehler oft nicht nur einen einzelnen Bildschirm betreffen, sondern ganze Abläufe zwischen Diensten.
Wer ein ähnliches Vorhaben plant, sollte Anforderungen strukturiert aufnehmen und früh auf Umsetzbarkeit prüfen lassen. Für eine erste Einordnung eignen sich der Projekt-Check oder ein unverbindliches Erstgespräch. So lässt sich vor einer Beauftragung klären, welche Teile der Plattform zuerst sinnvoll sind, wie sich Risiken begrenzen lassen und welche Architektur zum geplanten organisatorischen Setup passt.
Typische Fallstricke bei Betrieb, Sicherheit und Schnittstellen
Die größten Risiken in solchen Projekten liegen oft nicht in einzelnen Funktionen, sondern im Zusammenspiel vieler Teile. Wenn eine Plattform Bilder, Videos oder Streams bereitstellt, treffen Benutzeroberfläche, Fachlogik, Datenhaltung, Identitätsmanagement und Betrieb aufeinander. Schon kleine Unklarheiten an einer Schnittstelle können sich dann in mehreren Bereichen auswirken. Deshalb ist es wichtig, fachliche Zuständigkeiten und technische Verantwortungen klar zu trennen.
Ein häufiger Fallstrick ist eine zu frühe Detailentscheidung ohne belastbares Gesamtbild. Wird etwa direkt auf einzelne Komponenten optimiert, bevor Fachgrenzen und Datenflüsse sauber beschrieben sind, entsteht später leicht Reibung zwischen Teams. Ebenso problematisch ist eine Plattform, in der Abhängigkeiten unkontrolliert wachsen. Dann werden Änderungen langsam, Tests aufwendig und Störungen schwerer einzugrenzen. Eine klare Architektur mit begründeten Leitplanken hilft, solche Effekte zu begrenzen.
Auch das Thema Sicherheit sollte von Beginn an Teil der Architektur sein. Dazu gehören Anmeldung, Rollenmodell, geschützte Kommunikation, Zertifikate und nachvollziehbare Zugriffe. In sensiblen Umgebungen reicht es nicht, Sicherheit erst kurz vor dem Livegang zu ergänzen. Gleichzeitig ist wichtig, technische Maßnahmen nicht mit rechtlicher Bewertung zu verwechseln. Ob Datenschutz, Aufbewahrung, Zugriffsrechte oder weitere regulatorische Fragen passend gelöst sind, sollten Unternehmen mit ihren zuständigen Fachstellen, einem Datenschutzbeauftragten oder juristischen Beratern prüfen.
Im Betrieb zeigt sich oft, ob eine Plattform wirklich tragfähig entworfen wurde. Überwachung ist dabei mehr als die Frage, ob ein Server erreichbar ist. Es geht auch darum, ob Ereignisse verarbeitet werden, ob einzelne Dienste korrekt zusammenspielen und ob Probleme schnell eingegrenzt werden können. Ein verteilter Dienst besteht aus mehreren getrennten, zusammenarbeitenden Anwendungsteilen. Für solche Systeme braucht es klare Protokollierung, nachvollziehbare Freigaben und einen Betrieb, der Änderungen kontrolliert einführt. Je nach Vorhaben kann dafür ein Ansatz aus Hosting und Betrieb in der Microsoft Cloud sinnvoll sein.
Wer eine ähnliche Plattform plant, sollte außerdem beachten, dass externe und interne Systeme selten von Anfang an gleich stabil oder gleich gut dokumentiert sind. Schnittstellen ändern sich, Daten sind uneinheitlich und Verantwortlichkeiten liegen bei verschiedenen Beteiligten. Genau deshalb lohnt sich ein Vorgehen, das Architektur, Entwicklung, Qualitätssicherung und Betrieb eng verzahnt. Wenn Sie ein solches Vorhaben vorbereiten, unterstützen wir bei ballmüller solutions auf Wunsch von der Einordnung bis zur Umsetzung und beim strukturierten Start über ein unverbindliches Gespräch.
Häufige Fragen
Wovon hängen Aufwand und Kosten einer solchen Plattform ab?
Ausschlaggebend sind in solchen Vorhaben vor allem fachliche Breite, Anzahl und Qualität der Schnittstellen, Anforderungen an Verfügbarkeit, Sicherheitskonzept, Datenhaltung, Benutzerrollen und der gewünschte Betriebsrahmen. Auch die Frage, ob eine Plattform als zentraler Einstieg für mehrere Anwendungen dienen soll, beeinflusst den Aufwand deutlich. Für eine erste Einordnung empfiehlt sich der Kostenrechner oder ein Projekt-Check auf Basis einer vorhandenen Beschreibung.
Wie geht man ein Projekt für eine medizinische Bildplattform sinnvoll an?
Sinnvoll ist ein Vorgehen, das zunächst Ziele, Nutzergruppen, Datenflüsse und Systemgrenzen klärt. Darauf aufbauend werden Fachbereiche, Schnittstellen und Architekturprinzipien beschrieben, bevor die Umsetzung startet. In solchen Projekten ist eine enge Abstimmung zwischen Fachseite, Produktverantwortung, Architektur und Entwicklung besonders wichtig. So lassen sich Entscheidungen nachvollziehbar treffen und spätere Konflikte zwischen Oberfläche, Datenmodell, Sicherheit und Betrieb reduzieren.
Welche Risiken sollte man bei Bild-, Video- und Streaming-Funktionen früh beachten?
Typische Risiken liegen in uneinheitlichen Datenquellen, unklaren Verantwortlichkeiten, hoher Abhängigkeit zwischen Systemteilen und einem zu spät berücksichtigten Sicherheitskonzept. Hinzu kommen Anforderungen an Anmeldung, Berechtigungen, geschützte Kommunikation und den zuverlässigen Austausch zwischen Diensten. Auch fachliche Missverständnisse können teuer werden, wenn Begriffe und Abläufe nicht sauber definiert sind. Deshalb sollten Architektur, Fachmodell und Qualitätssicherung von Beginn an zusammen gedacht werden.
Was muss der spätere Betrieb einer solchen Lösung leisten?
Der Betrieb muss nicht nur die technische Verfügbarkeit unterstützen, sondern auch Überwachung, Protokollierung, sichere Bereitstellung von Änderungen und eine nachvollziehbare Fehleranalyse ermöglichen. In verteilten Plattformen ist wichtig, dass Ereignisse, Schnittstellen und Dienste als Gesamtsystem beobachtet werden können. Wer den Betrieb plant, sollte außerdem Identitätsmanagement, Zertifikate, Freigabeprozesse und Verantwortlichkeiten früh festlegen. Die konkrete Ausgestaltung hängt stark von Umfeld und Schutzbedarf ab.
Welche Rolle spielen Architektur-Boards und Mentoring in solchen Projekten?
In Plattformprojekten mit mehreren Beteiligten helfen Architektur-Boards dabei, technische Leitplanken festzulegen und Entscheidungen konsistent zu halten. Das verhindert, dass Teams ähnliche Probleme unterschiedlich lösen und die Plattform unnötig auseinanderläuft. Mentoring unterstützt zusätzlich dabei, Architekturprinzipien im Alltag verständlich umzusetzen. Für Entscheider ist das wichtig, weil gute Abstimmung nicht nur die technische Qualität betrifft, sondern auch die Zusammenarbeit, die Änderbarkeit und die Handhabbarkeit des Systems im laufenden Projekt.
