DiGA Software-Entwicklung

Du planst die Entwicklung einer digitalen Gesundheitsanwendung? Eine Software für Präventionsangebote, eine App auf Rezept, eine DiGA oder DiPA? Die Entwicklung eines Medizinproduktes als Software ist allein aufgrund der Regulatorik, den Gesetzen und Verordnungen in Deutschland ein großes und potenziell kostspieliges Vorhaben. Ein DiGA- oder DiPA-Projekt muss gut durchdacht und geplant sein. In unserer Serie möchten wir dir die wesentlichen Themen und Schritte aufzeigen, die bei der Planung, Konzeption und Umsetzung von eHealth-Lösung zu beachten sind.

Es ist wichtig, dass die Produktvision definiert ist und die Anforderungen an die Software steht. Wie ein solches Software Requirement Specification Dokument, kurz SRS, erstellt wird, haben wir in einer vorherigen Folge erklärt.

Es ist mindestens genauso wichtig, zu definieren, wie die Umsetzung ablaufen soll. Welche Anforderungen gibt es an dem Prozess der Umsetzung selbst? Was ist zu beachten?

Insbesondere aus regulatorischer Sicht sind bei der Umsetzung einer DiGA oder einer DiPA nicht nur für das fertig gestellte Produkt regulatorische Anforderungen zu erfüllen, auch schon der Umsetzungsprozess unterliegt der Regulatorik.

Optimalerweise, auch im Einklang mit den Anforderungen der ISO 13485, die für die Umsetzung von DiGAs und DiPAs zu erfüllen sind, wird ein Softwareentwicklungsplan bzw. auf englisch Software Development Plan, kurz SDP, erstellt.

In diesem Dokument wird u.a. spezifiziert, wie das Projekt – die Umsetzung der Software – ablaufen sollte: Wie ist das Projekt organisiert? Wie sieht das Projektteam aus? Welche Rollen gibt es? Welche Verantwortlichkeiten und Aufgaben liegen bei welcher Rolle? Wie wird die Kommunikation im Team geplant? Welche Regeltermine gibt es?

Zusammenfassend werden zu Beginn eines Projektes mindestens die Anforderungen an Time und Budget, an die Qualitätssicherung, Wartung und Support, IT-Sicherheit, Datenschutz und Dokumentationsformen festgehalten. Und wichtig: Für jede dieser Anforderungen wird im Laufe des Projektes erwartet, dass weiterführende detaillierte Spezifikationen erstellt werden, die vor Veröffentlichung des Produktes finalisiert sein sollten.

Wichtigster Bestandteil des SDP ist die Beschreibung des Entwicklungsprozesses. Wie genau wird entwickelt? Wird eine agile Methodik, wie Scrum oder Kanban, verwendet oder wird eher Wasserfall-artig umgesetzt? Wie sehen die einzelnen Schritte von der Spezifikation, der Erstellung von Epics und Userstories, die Freigabe von Aufgaben und das Testing bis zur Abnahme und Freigabe zur Veröffentlichung aus? Welche Tools werden verwendet? Wie sind diese zu konfigurieren?

Es ist immer schön und gut, sich ein Best-Case-Szenario zu überlegen und zu spezifizieren. Wichtiger ist: Man sollte sich anschauen, wie das eigene Umfeld aussieht und womit ein möglicherweise bestehendes Team am besten arbeiten kann. Ja, die Anforderungen an die Regulatorik müsse erfüllt werden, aber ein zu enges Korsett zu ziehen, in dem das Team eventuell nicht performt, nützt auch nichts. Gemäß der Grundprinzipien agiler Softwareentwicklung, was nebenbei erwähnt, meine klare Empfehlung ist, für die Methodik, wie man vorgeht, sollte man schauen, dass man Absprachen und im Zweifel auch abgestimmte Prozess hat, aber diese nicht in Stein gemeißelt sind und sich agil verändern! Nicht vergessen, dann aber auch im SDP Dokument die Prozessänderungen nach zu dokumentieren!

Ist das SDP Dokument erstellt und parallel auch das SRS Dokument, dann steht der Umsetzung fast nichts mehr im Wege. Nur noch die Qualitätssicherung sollte geplant werden. Wie und was genau erklären wir in einer der nächsten Folgen.