gms | German Medical Science

Nach der Etablierung von technischen Möglichkeiten, Daten aus verschiedenen Systemen in die elektronische Gesundheitsakte (EGA) „akteonline.de“, inzwischen ein Gemeinschaftsprojekt verschiedener deutscher und internationaler Universitäten sowie teilweise der Industrie, zu übernehmen, stieß die Entwicklung einer EGA an weitere Grenzen, die sich aus den zunehmenden unterschiedlichen Einsatzszenarien und verteilten Entwicklern ergaben. Die EGA akteonline.de kommt in verschiedenen klinischen Umgebungen zum Einsatz, bspw. in der Geburtshilfe, Kinderheilkunde, Augenheilkunde oder Pharmakologie. In allen diesen Implementierungen gibt es unterschiedliche Funktionalitäten und Designs, aber dieselben zugrunde liegenden Basisfunktionen wie bspw. Nutzerauthentifizierung, Session-Verwaltung und Verschlüsselung. Die Erweiterung der EGA um spezialisierte Module, entwickelt in externer Kompetenz durch andere Institute oder Arbeitsgruppen, ist eine neue Anforderung an das System. Gleichzeitig sollen diese Komponenten in einer EGA zusammengefasst bleiben, um dort von der bestehenden stabilen Basisfunktionalität zu profitieren.

Die Entwicklung neuer Module soll parallel und räumlich entfernt möglich sein. Neue Module oder Erweiterungen bestehender Funktionalitäten sollen möglichst einfach in ein Gesamtsystem integrierbar sein. Weiterhin müssen das Webdesign und damit die Sprache unabhängig von einzelnen Modulen oder Erweiterungen sein. Die neuen zusätzlichen Systemanforderungen, für die Problemlösungen gesucht werden müssen, sind: 1. Möglichkeit für einen externen Nutzer, neue Module zu implementieren, ohne Kenntnisse über das Gesamtsystem haben zu müssen; 2. Möglichkeit zur zentralen Anpassung von Layout und Design; 3. Funktionalität zur Erkennung und Verwaltung von Erweiterungen und neuen Modulen; 4. Bereitstellung von Dokumentation für Entwickler („Cookbook“); 5. Anbieten einer Möglichkeit zur zentralen Veröffentlichung und Verwaltung von neuen Erweiterungen und Modulen.

Durch die Kapselung von Funktionen und Daten in Objekte ist es einerseits möglich, unabhängige Einheiten zu schaffen, die vielfältig eingesetzt werden können, andererseits lassen sich Funktionsbereiche besser voneinander abgrenzen, so dass auch eine Wartung zielgenauer und schneller stattfinden kann. Die Mittel, die die Objektorientierung hier zur Verfügung stellt, sind jedoch häufig nicht ausreichend und es bedarf der zusätzlichen Leistung des Softwareentwicklers um die Integration dezentral entwickelter Komponenten zu unterstützen. In der Softwaretechnik wurden dafür in den letzten Jahren unterschiedliche Konzepte entwickelt, die so genannten „Plug-In-Architekturen“ [Ref. 1], [Ref. 2]. Im „Plug-In-Vertrag“ werden verbindliche Richtlinien festgelegt, wie die Kommunikation zwischen einem Plug-In und der Applikation abläuft. Es ist immanent wichtig, die Applikationsdienste so generisch wie möglich zu halten um möglichst viel Platz für Innovationen bereitzuhalten und die System-Spezialisierung den Plug-Ins zu überlassen.

Die erneuerte Implementierung der akteonline.de basiert auf der objektorientierten Programmiersprache JAVA. Es kommen verschiedene Frameworks zum Einsatz, um eine Entkopplung der Systemkomponenten zu erreichen und den Einsatz von „Best Practices“ [Ref. 3] zu fördern.

Aus Architektursicht stellt sich die akteonline.de als eine typische mehrschichtige Webanwendung dar: In der Präsentationsschicht kommen JavaServer Faces [Ref. 4] zum Einsatz. Sie definieren eine Website als ein Puzzle verschiedener wieder verwendbarer Bausteine. Diese so genannten „UIComponents“ konnten für die EGA soweit spezialisiert werden um Entwicklern den Entwurf ihres Plug-Ins zu erleichtern. Dadurch wird das „Look and Feel“ der Gesamtanwendung weniger beeinträchtigt und die von den Kernentwicklern geforderte Nutzbarkeit und Barrierefreiheit kann konsequent durchgesetzt werden. Des Weiteren kann so auch durch Eingreifen in den Rendering-Prozess das gesamte Design umgestellt werden ohne ein einziges Plug-In bearbeiten zu müssen. In der Businessschicht ist die Logik von akteonline.de angesiedelt. Hier finden sich sowohl Komponenten für Datenbankoperationen, Sicherheitsfunktionen und die Nutzeranmeldung bzw. Verwaltung, als auch modulspezifische Komponenten, wie sie z.B. für die Verwaltung von Medikamenteninformationen eines Nutzers benötigt werden. Die in der Backend-Schicht anfallenden Aufgaben des Ladens und der Speicherung von Daten werden in der akteonline.de mit Hilfe eines objektrelationalen Mapping-Werkzeugs (ORM-Tool) namens Hibernate [Ref. 5] bewältigt, welches den Einsatz der entwickelten objektorientierten Modelle unabhängig von der zugrunde liegenden Datenbank erlaubt.

Die „akteonline extendable“ (AOX) ist eine Sammlung dokumentierter Extension Points. Ein Extension Point definiert eine erweiterbare Schnittstelle im System. Das kann ein Modul der akteonline.de sein, wie das Medikamenten-Modul, ein Teil eines Moduls, wie die Medikamenten-Informationsdatenbank oder auch eine Basisfunktion selbst, wie die Erweiterung der Nutzerauthentifizierung um neue Login-Prozeduren. Ein Entwickler implementiert die Schnittstellen für den gewählten Extension Point und stellt geforderte Rahmenbedingungen für die neue Funktionalität her. Basisfunktionalitäten, die Entwickler benutzen können, werden vom AOX-Microkernel zur Verfügung gestellt. Um die Lernkurve flach zu halten, versteckt der AOX-Microkernel die Komplexität der verwendeten Frameworks. Zugriffe auf persistente Daten, Sicherheitsfunktionen und die Kommunikation mit der Präsentationsschicht werden vollständig gekapselt und stehen in Form gut dokumentierter APIs zur Verfügung. Es ist trotzdem möglich, Funktionen des AOX-Microkernel zu erweitern, denn auch dieser bietet Extension Points an.

Die AOX-Manager-Komponente erkennt neue Erweiterungen und bindet sie in das System ein. Die für diesen Schritt notwendigen Informationen stellt der Entwickler in einer XML-Datei zur Verfügung. In dieser ist auch Raum für optionale Metainformationen und benötigte Abhängigkeiten.

Für die aktuelle Entwicklung der akteonline.de – gerade im Hinblick auf das vorgestellte AOX Extension Model – stellt Open Source ein gutes Konzept dar. Eine große Community mit zentralen Tools wie einem Plug-In-Repository stellen die Basis für weitere internationale Beteiligung dar. Neue Kooperationen auf der inzwischen bewährten Basis der akteonline.de (z.B. Peter L. Reichertz Memorial Award der EFMI und der GMDS-Förderpreis 2003 der GMDS) mit individuellem Stil, Design und Inhalten sind explizit erwünscht und gesucht. Für den Bereich des Gesundheitswesens lässt sich feststellen, dass diese verteilte Form der Softwareentwicklung am ehesten der dezentralen und heterogenen Organisationsstruktur Rechnung trägt und die hohe Fachkompetenz einzelner Institutionen nutzen kann. Die neue akteonline.de antwortet durch ihren modularen Aufbau auf die zu Anfang gestellten Herausforderungen und Ziele:

1.

Durch die Bereitstellung einer Kernanwendung und einer darauf aufbauenden Plug-In-Architektur ist es möglich, dass externe Entwickler schnell und einfach am Entwicklungsprozess teilnehmen können.

2.

Die Anwendung spezifiziert einen eigenen Satz von UIComponents auf deren Grundlage die Anwendung selbst sowie die integrierten Plug-Ins dargestellt werden.

3.

Der AOX-Manager stellt einen Mechanismus zur Erkennung und Verwaltung von Plug-Ins dar.

4.

Innerhalb der Dokumentation der akteonline.de ist eine Spezifikation des Plug-In-Vertrags abrufbar.

5.

Zur Kontrolle der verfügbaren Plug-Ins und als Instanz der Qualitätssicherung ist die Bereitstellung eines Zertifizierungsdienstes angedacht.

Die Autoren möchten allen beteiligten Unternehmen, Universitäten und Kliniken, den Personen, die an dem Projekt arbeiten, und natürlich dem Gesundheitsministerium von Nordrhein-Westfalen, das das Projekt akteonline.de auf verschiedene Weise unterstützt, ihren Dank aussprechen.