3.2.2 Detaillierungsphase
Die Detaillierungsphase ist iterativ-inkrementell gestaltet und teilt sich in wiederkehrende aufeinander folgende Teilphasen (siehe Abb.
2, „Detaillierungsphase“, dunkelgraue Bereiche) auf. Dabei wird die Initialversion des Patientenpfads schrittweise in einzelne abgeschlossene
Pfadausschnitte zerlegt, die für sich genommen einen fachlichen Anwendungsfall ergeben. Die schrittweise Entwicklung jedes Pfadausschnittes verfolgte das Ziel, für einen vertikalen Auszug über alle Umsetzungsebenen hinweg – ausgehend von der groben fachlichen Prozessbeschreibung bis zum prototypisch integrierten Gesamtsystem – zu bilden. Dieses sogenannte Inkrement erzeugt einen anwendbaren Lösungsbestandteil mit tatsächlichem Nutzen aufbauend auf dem Inkrement der letzten Iteration. Diese Herangehensweise hat zum einen den Vorteil, dass sich Aufwand und Umfang im Verlaufe der Projektbearbeitung reduzieren, da insb. auf den technischen Umsetzungsebenen ein Fundament geschaffen und kontinuierlich erweitert wird. Zudem ist eine Parallelisierung der Bearbeitung aufeinander folgender Pfadausschnitte möglich. Zur Strukturierung des weiteren Vorgehens (siehe Abb.
2, „Detaillierungsphase“, schwarze Bereiche) wurden die Gestaltungsdimensionen herangezogen, für die nachfolgend die Umsetzungsmaßnahmen beschrieben werden. Die Ergebnisse, die bei den Arbeiten im Rahmen jeder Gestaltungsdimension entstehen, werden nach Bedarf iterativ mit den betreffenden Stakeholdern bewertet und bei Bedarf erneut überarbeitet.
Zur Beantwortung wurde gemeinsam mit den klinischen Projektpartnern Workshops zur Fachanalyse durchgeführt. Der Fokus der Workshops lag auf der Klärung möglicher inter- und intra-sektoraler Grenzüberschritte, auf den beteiligten Akteuren und deren Rollen sowie auf Informationsflüssen und -objekten. Darüber hinaus wurden mögliche Qualitätsziele, die eine Aussage zur Behandlungsqualität liefern können, für den betrachteten Pfadausschnitt analysiert. Diskussionen wurden stets vor dem Hintergrund geführt, dass die Versorgung gemeinsam mit Patienten zu gestalten ist, um eine Ausrichtung an deren Bedürfnissen zu gewährleisten. Die erzielten Ergebnisse bildeten maßgeblich das Grundgerüst zur Bearbeitung der weiteren Gestaltungsdimensionen. Durch das frühzeitig festgehaltene Grundgerüst des Pfadausschnittes konnten sich alle Beteiligten auf einen fachlichen Standard einigen.
Die Patienteneinbeziehung bei der allgemeinen Projektumsetzung als auch der Bearbeitung eines spezifischen Pfadausschnittes, ist auf zwei Wegen geschehen: (1) Die Teilhabe von Patienten an der eigenen Multiple Sklerose-Versorgung und (2) durch die Integration von Patienten in die Entwicklung über einen nutzerzentrierten Gestaltungsansatz. Für (1) werden die Interaktionspunkte der Patienten im betrachteten Pfadausschnitt mit den klinischen Projektpartnern herausgearbeitet und die Integrationsmöglichkeiten diskutiert. Bspw. wurde festgestellt, dass Patienten während ihres Besuchs im medizinischen Zentrum regelmäßig Standardfragebögen ausfüllen müssen. Eine Verlagerung solch vorbereitender Tätigkeiten in den häuslichen Bereich verkürzt den Aufenthalt und entspannt die Gesamtsituation für Patienten. Über ein Patientenportal sollen derartige Interaktionen digital gestützt und ein Patient aktiv in den Behandlungskontext eingebunden werden. Dazu werden die im Pfadausschnitt relevanten Informationen zur eigenen Behandlung und Funktionen zur Interaktion zielgerichtet und passgenau bereitstellt. Anhand der ermittelten Interaktionspunkte im Pfadausschnitt ließen sich Anforderungen (User Stories) zur Realisierung im Patientenportal ableiten. Zudem ließen sich Austauschszenarien zwischen den beteiligten Systemen identifizieren und mit den jeweiligen technischen Projektpartnern besprechen. Die Umsetzung und Ausgestaltung der erhobenen Anforderungen wurden in Fokusgruppen-Workshops mit Patienten (2) adressiert und prototypisch implementiert. Bspw. sollte Patienten eine Übersicht über zu bearbeitende Fragebögen sowie deren Bearbeitungsfrist geboten werden, die nach vollständiger Beantwortung dem Behandler bereitzustellen sind. Die Gebrauchstauglichkeit und Nutzerfreundlichkeit der umgesetzten Anforderungen wurden durch Usability Tests mittels Aufgabenszenarien (Nielsen
1993) und durch Fragebögen zur Bewertung der Gebrauchstauglichkeit (Brooke
1996) und des Nutzungserlebnisses (Schrepp
2015) evaluiert.
Zuerst wurden die allgemeinen Qualitätsziele des Qualitätsmanagements, um ein Kennzahlensystem erweitert. Die Kennzahlen in Form von Qualitätsindikatoren sollten unmittelbar mit den Informationen im Behandlungskontext in Verbindung stehen und bei der Umsetzung des Pfadausschnittes anfallen. Die Entwicklung der Qualitätsindikatoren orientierte sich an der erprobten Methodik für leitlinienbasierte Qualitätsindikatoren in der Onkologie (Leitlinienprogramm Onkologie
2021). Im ersten Schritt wurden bestehende Leitlinienempfehlungen sowie Fachliteratur hinsichtlich der Existenz eines spezifisch für Multiple Sklerose definierten Kernsatzes von Qualitätsindikatoren geprüft. Im Ergebnis ließ sich kein ausgewiesener Kernsatz identifizieren, jedoch war es möglich anhand von Behandlungsempfehlungen und -aussagen einen initialen Satz an Qualitätsindikatoren abzuleiten. Zur Validierung der Qualitätsindikatoren wurde ein Konsensprozess mit Fachexperten im Versorgungsumfeld der Multiplen Sklerose initiiert. Nach Zuordnung der abgeleiteten Qualitätsindikatoren zum jeweiligen Pfadausschnitt, war zu klären, wie die Qualitätsindikatoren zu formalisieren sind, welches der beteiligten Systeme in der Verantwortung bezüglich der Erhebung stand und welche Funktionen das betroffene System anbieten muss, um die Erfassung der jeweiligen Qualitätsindikatoren zu realisieren. Ebenso wurde zwischen allen Projektpartnern diskutiert, ob und mit welchem Informationsgehalt Patienten über die resultierenden Erkenntnisse eines erhobenen Qualitätsindikators über das Patientenportal informiert werden sollen.
Dabei sollten möglichst offene und etablierte Standards in den verschiedenen Entwicklungsphasen Anwendung finden, um ein möglichst flexibles, erweiterbares und skalierbares Gesamtsystem zu gestalten. Als Werkzeug zur Modellierung des Patientenpfades kam ein an die Bedürfnisse der Pfadmodellierung angepasstes Pfadmodellierungswerkzeug auf Basis der BPMN
2 zum Einsatz. Damit lassen sich prozessbezogene Informationen und Informationsflüsse, die, in reduziertem Umfang, selbst für Novizen nachvollziehbar sind, modellieren. Trotz der Erweiterungsmöglichkeiten der BPMN ist eine Abbildung von domänenspezifischen Konzepten und deren logische Zusammenhänge nicht möglich, wodurch eine Integrationslücke entstand, die es im Weiteren zu adressieren galt.
Technologisch wurde auf den FHIR-Standard gesetzt, der sich in den letzten Jahren bemerkenswert schnell entwickelt hat und selbst bei international führenden Technologieunternehmen etabliert ist (Jindal
2019). Der Standard bietet die Möglichkeit Implementierungsleitfäden (IG) zu erstellen, mit dessen Hilfe sich Regeln zur Beschreibung, Einschränkung und Erweiterung von domänenspezifischen Konzepten auf Ressourcen, sogenannte FHIR-Profile, umsetzen lassen. Das Hinzuziehen von Code-Systemen (CodeSystems) sowie konkreter Ausprägungen in Form von Wertmengen (ValueSets) lassen sich Ressourcen semantisch anreichern. Damit wird auf struktureller, syntaktischer und semantischer Ebene Interoperabilität gewährleistet. Als Datenaustauschformat sieht der FHIR-Standard JSON oder XML vor. Das Pfadmodellierungswerkzeug bietet die Speicherung eines Pfadmodells im FHIR XML-Datenformat an, was über eine Transformation des serialisierten BPMN-Prozessmodells im XML-Datenformat, ermöglicht wird. Das Transformationsergebnis bildete die Grundlage zur Erstellung und Weiterentwicklung eines projektspezifischen FHIR IG
3. Vor allem kommen dort die Ressourcen PlanDefinition, ActivityDefinition, Questionnaire und weitere definierende Ressourcen in Abhängigkeit vom betrachteten Pfadausschnitt zum Tragen. Im Zusammenhang mit der Systemarchitektur existiert ein dediziertes Repository für Patientenpfade, welches auf der Referenzimplementierung HAPI FHIR
4 beruht und dem der projektspezifische FHIR IG zugrunde liegt. Somit wird nicht nur die projektspezifische Domäne durch ein maschinenverarbeitbares und menschenlesbares Artefakt beschrieben, sondern gleichzeitig der Repository-Zugriff mittels einer REST API sowie die Validierung ausgetauschter Inhalte. Darüber hinaus wurde über den FHIR IG Aspekte der gemeinsam mit den technischen Projektpartnern entworfenen nachrichtenorientierten Gesamtsystemarchitektur beschrieben.