Die Software-Architektur einer digitalen Plattform veranschaulicht deren Struktur, liefert aber auch Informationen zu den erwartbaren Kosten oder zur technischen Realisierbarkeit bestimmter Anforderungen. Bei der hier skizzierten nationalen Gesundheitsplattform wird sie dem Grundmuster anderer Vermittlungsplattformen folgen, kann jedoch detailliert erst ausgearbeitet werden, wenn im Fall einer Umsetzung sämtliche Anforderungen definiert und offene Fragen abschließend beantwortet werden. Während der Konzeptentwicklung wurden ganz bewusst Fragen unbeantwortet gelassen, um Gestaltungsspielräume zu schaffen und keine unnötigen Vorfestlegungen zu treffen. Die bereits getroffenen konzeptionellen Festlegungen sowie die Bestimmung von Rollen und Aufgaben im digitalen Ökosystem der Plattform ermöglichen allerdings einen ersten Überblick über die notwendigen Komponenten und deren Zusammenspiel.
Auf Basis der konzeptionellen Vorüberlegungen (vgl. Unser Konzept in der Gesamtschau) lassen sich Systemgrenzen aufzeigen, die verdeutlichen, was Gegenstand der nationalen Gesundheitsplattform ist und welche unmittelbar benachbarten Systeme über Schnittstellen verbunden sind. Die hier beschriebenen Überlegungen bilden jedoch keine umsetzungsreife Software-Architektur ab, die bereits alle relevanten Architekturtreiber und technologischen Aspekte berücksichtigt. Deren Erhebung und Verfeinerung wird Gegenstand weiterer konzeptioneller Arbeit sein.
Teilnehmende Akteure des Ökosystems
Im Zentrum der Betrachtung steht die nationale Gesundheitsplattform als technisches Rückgrat der Vermittlung kontextspezifischer digitaler Gesundheitsinformationen und Services. Die Plattform hat die Aufgabe, wesentliche Funktionen zur Verwaltung von Nutzerinnen und Nutzern sowie von Inhalten zur Verfügung zu stellen. Außerdem bildet sie das technische Bindeglied zwischen den verschiedenen Akteuren im Ökosystem. Abgesehen vom Plattformbetreiber zählen hierzu die
Anbieter von Gesundheitsinformationen – z. B. von Informationen zu Erkrankungen, zur Prävention, zur Versorgungsstruktur etc. in unterschiedlichen Formaten.
Anbieter von gesundheitsrelevanten Services – z. B. Online-Terminvereinbarung, Krankenhaussuche, Schmerztagebuch etc.
Anbieter von Kontextinformationen – personenbezogene Informationen, die Hinweise auf den situativen Informationsbedarf der Patientinnen und Patienten liefern
Entwickler von Pfadmodellen – indikationsspezifische Vorlagen für den erwartbaren Verlauf des Informationsbedarfs, entlang derer Gesundheitsinformationen spezifisch für die jeweiligen Patientinnen und Patienten ausgespielt werden
Patientinnen und Patienten
Die Plattform und ihre Schnittstellen
Die zentrale Aufgabe der nationalen Gesundheitsplattform besteht darin, Gesundheitsinformationen und gesundheitsrelevante Services zur richtigen Zeit an die richtigen Personen weiterzugeben. Diese Weitergabe wird in aller Regel durch Ereignisse gesteuert, beispielsweise einen Arztbesuch oder das Erreichen einer zeitlichen Frist wie »sechs Wochen nach Krankschreibung«. Solche Ereignisse wiederum werden von eingehenden Kontextinformationen abgeleitet, woraufhin die nationale Gesundheitsplattform entlang eines oder mehrerer aktuell relevanter Pfadmodelle die passenden Informationen und Services an die Patientinnen und Patienten ausspielt (vgl. Unser Konzept in der Gesamtschau). Für diese Kernfunktionalität der Vermittlung von Gesundheitsinformationen und Services sind verschiedene Schnittstellen notwendig, die nachfolgend vorgestellt werden:
- Schnittstelle zur Aufnahme von Gesundheitsinformationen: Diese Schnittstelle ermöglicht, Gesundheitsinformationen auf der Plattform zu hinterlegen, damit diese aufgrund bestimmter Merkmale dem situativen Informationsbedarf der Patientinnen und Patienten zugeordnet und in einem personalisierten Feed (vgl. Entdecken statt suchen) bereitgestellt werden können. Darüber hinaus können diese Information über eine semantische Suche abgerufen werden.
- Schnittstelle zur Aufnahme von Services: Die Aufnahme von Services erfolgt analog zur Aufnahme von Gesundheitsinformationen. Services werden den Patientinnen und Patienten ebenfalls situativ bereitgestellt.
- Schnittstelle zur Aufnahme individueller Kontextinformationen: Die Übermittlung individueller Kontextinformationen über Patientinnen und Patienten erfordert Schnittstellen, die eine automatisierte Kommunikation zwischen Systemen erlauben. Der Austausch von Daten über diese Schnittstellen erfolgt ausschließlich auf Basis der differenzierten Einwilligung der Patientinnen und Patienten für den jeweiligen Anbieter der Kontextinformationen, etwa die elektronische Patientenakte (ePA) oder diverse Anbieter von Fitness- und Gesundheitsdaten. An den Schnittstellen zur Übergabe der Kontextinformationen kann die Plattform vor deren Entgegennahme prüfen, ob die Einwilligung der Nutzerin oder des Nutzers vorliegt. Für verschiedene Kontextinformationen unterschiedlicher Anbieter können ggf. jeweils angepasste Schnittstellen notwendig sein, wobei eine Harmonisierung der eingehenden Daten im Anschluss durch die nationale Gesundheitsplattform erfolgt.
- Schnittstelle zur Verwaltung von Pfadmodellen: Die Vorlagen werden über eine grafische Benutzeroberfläche modelliert und auf der Plattform hinterlegt. Über dieselbe Schnittstelle ist es möglich, Pfadmodelle zu verwalten, zu überarbeiten und zu verbessern. Ebenso lässt sich eine kollaborative Modellierung zwischen mehreren Erstellern realisieren.
- Schnittstelle für Patientinnen und Patienten: Patientinnen und Patienten greifen über eine grafische Benutzeroberfläche – etwa als Webseite oder App für mobile Endgeräte – auf die Funktionalitäten der nationalen Gesundheitsplattform zu, insbesondere um Gesundheitsinformationen zu erhalten sowie den Zugang zu gesundheitsrelevanten Services. Neben dieser traditionellen Schnittstelle können weitere Zugriffsmöglichkeiten eingesetzt werden, vor allem sprachbasierte Benutzungsschnittstellen. Die Patientinnen und Patienten werden authentifiziert über die in der Telematikinfrastruktur 2.0 geplante digitale Identität im Gesundheitswesen, die gewährleistet, dass sämtliche Daten zuverlässig den Patientinnen und Patienten zugeordnet und nur von diesen abgerufen werden können.
Gesundheitsinformationen werden von zertifizierten Anbietern mittels eines dialoggestützten Vorgangs bereitgestellt. Dieser unterstützt die jeweiligen Anbieter dabei, ihre Informationen der Plattform so zu übermitteln, dass sie mit Pfadmodellen verknüpft und ausgespielt werden können oder über die Suche für Patientinnen und Patienten auffindbar sind. Bei diesem Vorgang wird der eigentliche Inhalt – etwa ein Informationstext oder ein Video – nicht auf die Plattform übertragen, sondern verbleibt beim jeweiligen Anbieter. Stattdessen wird ein Link hinterlegt und mit Meta-Informationen, etwa zum Erstelldatum oder zu den verwendeten Quellen, angereichert.
Die Gesundheitsinformationen werden über die zuvor genannte Schnittstelle an die nationale Gesundheitsplattform übermittelt. Diese Schnittstelle kann in zwei Ausprägungen realisiert werden. Zum einen kann die Plattform selbst eine grafische Benutzeroberfläche anbieten. Die von Anbietern der Gesundheitsinformationen nutzbare Webseite oder Anwendung unterstützt diese dabei, ihre Informationen zu hinterlegen und alle notwendigen Angaben zu erfassen.
Zum anderen kann diese Schnittstelle so konzipiert werden, dass Daten von anderen Systemen entgegengenommen werden, ohne dass Nutzerinnen und Nutzer aktiv werden müssen. Hierfür notwendig sind ergänzende Schnittstellen auf Seiten der Anbieter der Gesundheitsinformationen, konkret bei den jeweiligen Content-Management-Systemen, über die die Informationen originär erstellt werden. Diese Systeme übertragen freigegebene Informationen an die Plattform. Das hat den Vorteil, dass die Anbieter kein zusätzliches System bedienen müssen und in ihrer gewohnten Arbeitsumgebung bleiben können.
Gesundheitsrelevante Services werden ähnlich wie Gesundheitsinformationen behandelt. Das heißt, zertifizierte Anbieter werden dabei unterstützt, ihre Dienste mit der nationalen Gesundheitsplattform zu verknüpfen. Analog zu den Gesundheitsinformationen erfolgt keine vollständige Übertragung der Services auf die Plattform, sondern es werden Verlinkungen vorgenommen: Die Plattform erhält einen Verweis auf einen Service mit beschreibenden Metadaten, um diesen entlang eines Pfadmodells an Patientinnen und Patienten auszuspielen.
Kontextinformationen, die Auskunft über den situativen Informationsbedarf von Patientinnen und Patienten liefern, fallen bei unterschiedlichen Akteuren im Gesundheitswesen an. Entscheidend für den Erfolg der nationalen Gesundheitsplattform ist, sie in einem einheitlichen Format zu erfassen, das sich an bestehenden Standards orientiert. Auf einen möglichen Standard gehe ich im weiteren Verlauf dieses Beitrags noch ein. Die Grundlage für die Vereinheitlichung bildet die von der Plattform spezifizierte Schnittstelle, über die Systeme von Dritten entsprechende Daten übermitteln. Aktuell wichtigster Datenlieferant ist die Gematik bzw. die staatliche Digitalagentur, die über die elektronische Patientenakte alle Daten bündelt, die Arztpraxen, Apotheken und Kliniken über ihre jeweiligen Verwaltungssysteme weitergeben.
Die Schnittstelle soll erlauben, dass neben der elektronischen Patientenakte weitere Quellen von Kontextinformationen angebunden werden können. Neben Krankenkassen kommen hier auch Plattformen für Gesundheitsdaten wie Google Health oder Fitbit in Frage. Diese Daten würden jeweils mit dem Einverständnis der Patientinnen und Patienten bei den jeweiligen Akteuren an die nationale Gesundheitsplattform übermittelt. Da die exakten Formate der Daten bei den verschiedenen Anbietern noch nicht bekannt sind, ist es wahrscheinlich, dass unterschiedliche Arten von Schnittstellen für verschiedene Gruppen von Anbietern angeboten werden. Dies hat zur Folge, dass die Harmonisierung der Daten möglicherweise im Anschluss auf der nationalen Gesundheitsplattform erfolgt.
Die hier skizzierte Schnittstelle wird von verschiedenen Systemen angesprochen. Sie wird nicht von Patientinnen und Patienten selbst verwendet und bietet keine grafische Benutzeroberfläche, da individuelle Kontextinformationen automatisiert auf Seiten der Anbieter der Informationen erarbeitet und übertragen werden. Ohne Automatisierung erscheint der notwendige Grad an Aktualität der Daten und deren Menge nicht realisierbar. Gleichwohl muss auch diese Schnittstelle über Authentifizierungsmechanismen verfügen, sodass nur autorisierte Systeme ihre Daten an die nationale Gesundheitsplattform übertragen können.
Die Erstellung von Modellen für Patienteninformationspfade erfordert Expertise hinsichtlich des Verlaufs des patientenseitigen Informationsbedarfs und die Kenntnis der typischen Stationen einer Erkrankung. Daher werden die Vorlagen ausschließlich von zertifizierten Akteuren erstellt (vgl. Unser Konzept in der Gesamtschau) . Gleichzeitig ist zu erwarten, dass Pfadmodelle komplex ausfallen, sodass eine Visualisierung sinnvoll ist. Die grafische Benutzungsschnittstelle zur Modellierung von Pfadmodellen wird auf der nationalen Gesundheitsplattform entsprechend zertifizierten Akteuren bzw. deren Einrichtungen zugänglich sein.
Abschließend wird die Perspektive der Patientinnen und Patienten betrachtet, für die anhand der individuellen Kontextinformationen die passenden Gesundheitsinformationen und Services ausgespielt werden. Sie nutzen die Benutzeroberfläche der Plattform als Zugang zum digitalen Ökosystem, um entlang von Pfadmodellen jeweils passende Informationen und Services zu erhalten oder – dem eigenen Bedarf entsprechend – nach qualitätsgesicherten Informationen und Services zu suchen. Darüber hinaus erhalten Patientinnen und Patienten zur Wahrung der Datensouveränität die Möglichkeit, die Verwendung ihrer Daten zu steuern. Dies kann über ein Privacy-Dashboard erfolgen, wie es beispielsweise im Forschungsprojekt »D’accord« entwickelt und erprobt wird (https://daccord-projekt.de).
Die Authentifizierung der Patientinnen und Patienten erfolgt über die digitale Identität, die in der Telematikinfrastruktur 2.0 vorgesehen ist. Diese Authentifizierung erleichtert die Verknüpfung der personenbezogenen Daten der elektronischen Patientenakte, die gerade zu Beginn als primäre Quelle für Kontextinformationen dienen könnte. Neben diesem Zugang können weitere Mechanismen geschaffen werden, um Patientinnen und Patienten in das digitale Ökosystem einzubinden. Dazu gehört etwa ein SMS-Versand über entsprechende Dienstleister, die das direkte Versenden von Links auf die Benutzeroberfläche der nationalen Gesundheitsplattform ermöglichen.
Weiteres Vorgehen zur Konzeption
Die abschließende Auswahl der geeigneten Rahmenwerke und Technologien sollte auf Basis einer Anforderungsanalyse und einer detaillierten Architekturkonzeption erfolgen, die die bisher erfassten, groben Anforderungen ergänzt und verfeinert. Hierbei müssen nicht funktionale Anforderungen besonders berücksichtigt werden. Das Thema der IT-Sicherheit wurde im vorherigen Abschnitt bereits angesprochen. Darüber hinaus sind Performance und Skalierbarkeit äußerst relevant, da mit hohen Nutzerzahlen zu rechnen ist – die Plattform soll allen Patientinnen und Patienten in Deutschland zur Verfügung stehen. Die große Zahl der Nutzerinnen und Nutzer sorgt wiederum für einen sehr großen Zustrom an Daten, die von der Plattform zu verarbeiten sind. Die auszuwählenden Technologien zur Realisierung und die darunterliegende Infrastruktur müssen es erlauben, bei entsprechender Last zu skalieren.
Als weitere essenzielle nicht funktionale Anforderung ist die User Experience (UX) zu berücksichtigen. Da die nationale Gesundheitsplattform allen Patientinnen und Patienten offensteht und für jede und jeden leicht nutzbar sein soll, muss auf die besonderen Bedarfe und Präferenzen unterschiedlicher, teils besonders vulnerabler Nutzergruppen Rücksicht genommen werden. Hierzu zählen beispielsweise alte Menschen oder Patientinnen und Patienten mit einer kognitiven Beeinträchtigung. Auf diese Gruppen ist bei der Gestaltung ein besonderes Augenmerk zu legen.
Die Analyse der Anforderungen bestimmt außerdem die weiteren Funktionalitäten der Plattform, unter anderem zur Verwaltung von Nutzerinnen und Nutzern und deren Berechtigungen, zur Verwaltung der Pfadmodelle und zur Instanziierung der Pfadmodelle für Patientinnen und Patienten. Diese bezeichnet die Zuordnung konkreter Gesundheitsinformationen und Services sowie deren Ausspielen über die Plattform anhand der individuellen Kontextinformationen.
Rahmenbedingungen für Deployment und Hosting
Der Kern der nationalen Gesundheitsplattform ist die Software selbst, die durch Verteilung auf einen oder mehrere Server funktionsfähig gemacht werden muss. Dieser Vorgang wird »Deployment« genannt. Zusätzlich ist ein Betrieb der Ausführungsumgebung für die Software notwendig, was man als »Hosting« bezeichnet. Daneben verfügt die Plattform über eine Vielzahl von Daten – von Nutzerdaten und Kennungen über Links auf Gesundheitsinformationen und Services bis hin zu Kontextinformationen –, die in Teilen auf der Plattform selbst vorliegen müssen, um sie adäquat auswerten zu können. All diese Daten müssen ebenfalls auf einem oder mehreren Servern abgelegt, das heißt, »gehostet« werden.
Das Hosting der Plattform und aller gespeicherten Daten muss selbstverständlich nach dem Stand der Technik erfolgen, wobei die Handhabung von Daten grundsätzlich den Maßgaben der Datenschutzgrundverordnung (DSGVO) – und im Falle gesundheitsbezogener Daten den Maßgaben der dort definierten besonderen Schutzmaßnahmen – gerecht werden muss. Im Zuge weiterer Überlegungen zur IT-Architektur der Plattform müssen Entscheidungen zum Deployment getroffen werden. Es muss also die Frage beantwortet werden, welche Teile des Gesamtsystems wie und wohin verteilt werden und welche organisatorischen Einheiten deren Hosting jeweils verantworten. So kann beispielsweise das Hosting der Software vom Hosting der Daten getrennt werden – mit der Etablierung von Sicherheitsmaßnahmen auf beiden Seiten. Eine Kontrolle der Datenflüsse sowohl auf Seiten der Software als auch auf Seiten der Datenbanken sowie eine physische Trennung der Server erschweren eine Kompromittierung des Gesamtsystems. Mit einer solchen Maßnahme lässt sich ein höheres Maß an Sicherheit und Verlässlichkeit im Umgang mit den Daten erreichen.
Weiterhin notwendig sind spezifische Analysen möglicher Angriffsszenarien, um die nationale Gesundheitsplattform zu schützen. Diese müssen bei der Ausarbeitung einer Software-Architektur vorgenommen werden. Grundsätzlich sollte ein Hosting einschließlich der Speicherung von Backups in Europa angestrebt und von einer im Gesundheitswesen anerkannt vertrauenswürdigen Instanz durchgeführt werden.
Ereignisgesteuerte Architektur
Primär werden Gesundheitsinformationen und Services anhand des Push-Prinzips ausgespielt – das heißt, entlang des Durchlaufs von Pfadmodellen erhalten Patientinnen und Patienten die für sie passenden Informationen, ohne selbst aktiv werden zu müssen. Unabhängig davon können Patientinnen und Patienten auch eine traditionelle Suchfunktion nutzen. Bei der Zuordnung von Suchtreffern zu Anfragen kann die Plattform sämtliche vorliegenden Kontextinformationen nutzen, um passende Ergebnisse anzuzeigen. Diese Informationen können zur Erstellung eines individuellen Rankings der Suchergebnisse genutzt werden, analog zu bekannten Suchmaschinen. Im Unterschied zu diesen kann die nationale Gesundheitsplattform bei Bedarf transparent machen, welche Kontextinformationen in welcher Gewichtung zu einem Ranking von Suchergebnissen geführt haben – damit lässt sich das Vertrauen sowohl auf Seiten der Patientinnen und Patienten als auch der Anbieter von Gesundheitsinformationen und Services gewinnen.
Die technische Abbildung eines Systems wie der hier skizzierten nationalen Gesundheitsplattform kann über eine sogenannte »ereignisgesteuerte Architektur« erfolgen. Eine solche Architektur stellt die Kommunikation verschiedener Komponenten im Gesamtsystem durch Eintreten von Ereignissen in den Vordergrund. Jedes Ereignis wird durch einen Produzenten ausgelöst und anschließend von einem »Event Handler« verarbeitet. Dieses technische Teilsystem bestimmt anhand des Produzenten, des Zeitpunkts und Typs sowie des Inhalts des Ereignisses die nachfolgenden Aktionen – bestimmt also beispielsweise geeignete Gesundheitsinformationen, die einer Patientin oder einem Patienten angezeigt werden.
Ereignisgesteuerte Architekturen sind ein im Software-Engineering etabliertes Konzept, für das es bereits technische Rahmenwerke gibt, die eine Umsetzung erleichtern. Ein solches bildet der Nachrichten-Broker »Apache Kafka« (https://kafka.apache.org), um eine Realisierungsmöglichkeit exemplarisch zu nennen. Apache Kafka ist eine vielseitig einsetzbare Technologie, die keine domänenspezifischen Aspekte berücksichtigt. Demgegenüber existieren auch Rahmenwerke, die spezifische Standards und Funktionalitäten zur Handhabung gesundheitsbezogener Daten berücksichtigen oder definieren. Ein Open-Source-Rahmenwerk zum Aufbau eines Ökosystems im Gesundheitssektor wird von der Standford University bereitgestellt: »Spezi« (https://github.com/StanfordSpezi). Dieses Rahmenwerk definiert eine Architektur, die den Austausch gesundheitsbezogener Daten mit anderen Systemen dadurch erleichtert, dass der von HL7® definierte FHIR®-Standard für den Austausch gesundheitsbezogener Daten implementiert wird (https://www.hl7.org/fhir/). Es ist denkbar – nach tiefgreifender Analyse der Anforderungen und des Rahmenwerks –, ausgewählte Teile der Plattform auf Spezi aufzubauen.
Machbar und offen für neue Ideen
Die hier dargelegten Überlegungen zur technischen Realisierung einer nationalen Gesundheitsplattform skizzieren die grundsätzliche Funktionsweise und belegen die technische Realisierbarkeit des Konzepts. Gleichzeitig zeigen wir damit auf, dass das »Brokering« – also die Vermittlung von Gesundheitsinformationen und Services anhand von individuellen Kontextinformationen der Patientinnen und Patienten – umsetzbar ist. Dies gilt insbesondere dann, wenn die Plattform auf Standards und Open-Source-Rahmenwerke wie Standfords »Spezi« aufbauen kann, denn so lassen sich Aufwände und Kosten mindern und die Abhängigkeit von proprietären Lösungen gleichzeitig verringern.
Zusätzlich gilt gemäß dem Konzept, dass sich die nationale Gesundheitsplattform im Kern auf die Vermittlung von passenden Informationen und digitalen Services beschränkt. Das bedeutet, dass die redaktionelle Erstellung von Gesundheitsinformationen, die Entwicklung von Services sowie die Gewinnung individueller Kontextinformationen nicht von der Plattform selbst geleistet wird. Diese für digitale Ökosysteme typische Konstellation ermöglicht, die Verantwortung zu verteilen und damit die Ressourcen auf die Qualitätssicherung und das automatisierte Ausspielen relevanter Informationen und Angebote für Patientinnen und Patienten zu fokussieren.
Die Ausführungen in diesem Beitrag geben bewusst keine Systemarchitektur vor und treffen keine technischen Vorfestlegungen. Die abschließende Bestimmung der geeigneten Architekturmuster und Technologien zur Realisierung der Plattform und ihrer Schnittstellen wird erfolgen, nachdem funktionale und nicht funktionale Anforderungen im Detail ausgearbeitet und dokumentiert wurden.
Autor
Dr.-Ing. Matthias Koch ist Software Engineer am Fraunhofer IESE und leitet die Abteilung »Digital Innovation Design«. Seit 2012 beschäftigt er sich mit der Gestaltung innovativer Software-Lösungen, mit Kunden aus der Wirtschaft und in Forschungsprojekten. Dies umfasst die Themenfelder Requirements und User Experience Engineering sowie die Durchführung von Innovation Workshops. Besonders im Bereich »Digitale Ökosysteme« arbeitet Matthias Koch an der Gestaltung von Methoden und Werkzeugen für den Aufbau digitaler Plattformen.
