Der Weg von der Vision zum konkreten Plan für die Systemeinführung

Der Kunde ist ein internationales Forschungsinstitut, das sich der Entwicklung der computergestützten Medizin widmet. Die Mitarbeiter des Instituts entwickeln fortschrittliche computergestützte Methoden zur Vorbeugung, Diagnose und Behandlung von Krankheiten, um dem dringenden Bedarf an einer effizienten, effektiven und rationalisierten Gesundheitsversorgung gerecht zu werden. Die Hauptpriorität der Aktivitäten besteht darin, Klinisch tätigen Personen Werkzeuge für eine bessere Patientenversorgung an die Hand zu geben und das größte Zentrum für Computermedizin in Europa zu werden.

Es handelt sich um ein sehr umfangreiches Projekt mit Entwicklungsperspektiven, bei denen Jahre in die Zukunft gedacht werden mussten. Als wir mit der Arbeit an dem Konzept begannen, konzentrierten wir uns darauf, die allgemeinen Systemanforderungen kennenzulernen und sie bis ins Detail zu beschreiben, so dass wir ein PoC (Proof of Concept) erstellen konnten.

Die Wahl der Methodik für die Durchführung des Projekts war ebenfalls eine Herausforderung, da Papierkram und strenge Budgetierung eine detaillierte Aufschlüsselung der Anforderungen in der Analysephase und die Anwendung eines Waterfall Concept erforderten. Aufgrund des explorativen Prozesses der Anforderungsklärung und des anschließenden Systemaufbaus wäre dagegen ein flexiblerer, agilerer Ansatz angebracht, bei dem der Definitionsprozess für  Herausforderungen und Begrenzungen während des Projekts erfolgt. Letztendlich einigten wir uns mit dem Kunden auf eine hybride Arbeitsweise, die beide Modelle kombiniert.

Entwicklung des Funktionskonzepts

Wir begannen unsere Arbeit an dem Projekt mit der Durchführung von Product Discovery-Workshops, bei welchen wir Design Thinking– und Event Storming-Methoden verwendeten, um die besten Benutzeranforderungen und Geschäftsprozessabläufe zu verstehen. Mit diesen Techniken wird die geschäftliche und technische Analyse vollständiger, was zur Entwicklung von Lösungen führt, die auf die tatsächlichen Bedürfnisse der Zielgruppe zugeschnitten sind.

• Während des Design Thinking-Workshops diskutierten wir die gesammelten Informationen mit den Stakeholdern des Kunden und konzentrierten uns dabei auf die Perspektive des Kunden. Die Fähigkeit, eine innovative Lösung zu entwickeln, die die Herausforderungen der Nutzer angeht, hängt von einem gründlichen Verständnis ihrer Bedürfnisse ab.  In dieser Phase überprüften wir die aus der früheren Bedarfsanalyse abgeleiteten Annahmen, um die wichtigsten Design-Annahmen und Ausschlüsse zu identifizieren.
• Auch hier konzentrierten wir uns auf die effektive Untersuchung und Modellierung komplexer Geschäftsprozesse. Wir setzten Werkzeuge ein, um Schlüsselereignisse in der Geschäftsdomäne zu identifizieren und um zu verstehen, wie sie sich auf das gesamte System auswirken. Auf diese Weise erstellten wir ein vorläufiges Funktionskonzept für das Produkt.

In den folgenden Phasen haben wir uns vorbereitet:

• Drei primäre Übersichts-Benutzeroberflächen (sogenannte Screen Mockups). Der Ausgangspunkt war die Erstellung eines Assistenten mit verschiedenen Registervorlagen. Der Kunde legte großen Wert auf das Front-End der Anwendung, um die Lösung benutzerfreundlich, intuitiv und flexibel zu gestalten. Ziel ist es, ein System zu schaffen, das auch von Personen konfiguriert werden kann, die nicht in der Softwareentwicklung tätig sind.
• SWOT-Analyse ausgewählter Technologien, um das für die Bedürfnisse des Kunden am besten geeignete Technologiepaket empfehlen zu können. Wir waren insbesondere der Ansicht, dass es sich bei den ausgewählten Technologien um marktführende Lösungen handeln sollte, die einfach zu warten und zu

skalieren sind.

• Analyse der Cloud-Problematik, da es sich um einen großen Satz von Daten handelt, die von verschiedenen medizinischen Einrichtungen und darüber hinaus gesammelt werden. Andererseits ist es aus Gründen der Datensicherheit erforderlich, dass die Daten auf den internen Servern der Organisation auf Krankenhausebene verbleiben, während die Daten auf einer höheren Ebene, entweder auf nationaler oder europäischer Ebene, anonymisiert werden.
• Ein Projektfahrplan enthielt unter anderem eine Beschreibung des Projektumfangs in Form eines Projektstrukturplans; wir gaben die ersten Schritte an, die in der Programmierungsphase in Angriff genommen werden sollten, und stellten den Projektzeitplan mit Meilensteinen in Gantt-Diagrammen dar.

Das Ergebnis einer Reihe solcher Workshops war die Entwicklung und Konsistenz eines Glossars von Begriffen, die Beschreibung der verschiedenen Module des Systems zusammen mit den Abhängigkeiten zwischen ihnen, die Identifizierung von Rollen und Nutzern, die Isolierung von funktionalen und nicht-funktionalen Anforderungen (unter Berücksichtigung von u.a. Aspekten der Leistung, Sicherheit, Benutzerfreundlichkeit oder Zugänglichkeit) und die Entwicklung einer vorläufigen Skizze der Systemarchitektur.

Wir erstellten eine vollständige Dokumentation des Projekts, einschließlich einer Kostenschätzung der einzelnen Systemannahmen, einer Beschreibung der funktionalen und nichtfunktionalen Anforderungen sowie eines Risikoregisters und eines Projektfahrplans. Das Ergebnis war ein mehrseitiges, umfassendes Dokument, das eine fertige Grundlage für den Beginn der Entwicklungsarbeit bot.

Das Hauptziel des Projekts war die Entwicklung von Instrumenten zur Verbesserung der Behandlungsqualität der Patienten, die auf so genannten QR-Qualitätsregistern basieren.  Der Ausgangspunkt für die Sammlung solcher Daten ist die Entwicklung eines Assistenz-Tools, das die Erstellung von medizinischen Registern auf Abruf ermöglicht, um alle Informationen über verschiedene Patientenbedingungen zu speichern. Dies wäre z. B. anwendbar, wenn ein medizinisches Konsortium zusammengestellt wird, das spezifische Informationen über eine Krankheit, eine Behandlungsart usw. überprüfen muss. Die Schaffung eines solchen Instruments mit Hilfe modernster Technologie würde eine  schnellere Diagnose und Behandlung von Patienten ermöglichen.