Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Hinsichtlich der Funktionalitäten eines EHR-Systems – in diesem Kontext der klinische Teil eines KIS, also das klinische Kernsystem – gibt HL7 über 230 verschiedene Funktionalitäten bzw. Leitungsmerkmale in 4 Kategorien an, die für verschiedene Zwecke profiliert werden können344. Solche Profile können bei modularer Implementierung der Funktionalitäten dann „Modul- Bundles“ in der Softwareumgebung angesehen werden. Im HL7-Functional Model wird eine hierarchische Funktions-Gliederung mit bis zu vier Ebenen angegeben. Aggregiert werden diese jeweils auf oberster Ebene in sechs generelle Funktionsklassen. Nachfolgende Abbildung zeigt einen kleinen Ausschnitt aus der Hierarchie des HL7-EHR-Functional Models. EHR-System Funcionality Care Provision (CP)              Care Provision      Administrative         Population Health                Record               Trust Support (CPS)        Support (AS)            Support (POP)            Infrastructure (RI) Infrastructure (TI) …                                         …                       …                   … CP1 Manage Clinical History                            AS2 Mgm Pat.Demographics, CP1.1 Manage Patient History                           Location & Synchronisation CP1.2 Manage Allergy, AS2.1 Synch. Pat.Demographic Intolerance and Adverse Reaction List                   Data CP1.3 Manage Medication List AS2.2 Mgm Pat.Location ….                                                            Within Facility CP2 Render externally-sourced Clinical Docs AS2.3 Mgm Pat.Residence … for the Provision & CP3 Manage Clinical Documentation                                  Administration of Services CP3.1 Conduct Assessments AS2.4 Mgm Pat. Bed Assignment CP3.2 Manage Patient Clinical Measurements              AS2.5 Mgm Pat. In Healthcare Programs CP3.3 Manage Clinical Documents & Notes …                                                                   … CP4 Manage Orders                                      AS3 Manage Personal Health Record Interaction … CP5 Manage Results … … CP6 Manage Medication, Immunization AS4 Manage Communiation and Treatment Administration … CP7 Manage Future Care …                                                 … CP8 Manage Patient Education & Communication …          AS5 Manage Clinical Workflow CP9 Manage Care Coordination & Reporting …                  Tasking … Abbildung 4-6: Gliederungsauszug HL7 EHR Functional Model Ausführlich werden die wesentlichen Module und inhärenten Funktionalitäten eines Medizini- sches Informationssystems in Form eines Schichtenmodelles detailliert bei Haas345 beschrieben. Dabei werden die Module Stammdatenverwaltung, Patientenverwaltung, Fallverwaltung, Me- dizinische Dokumentation mit zahlreichen Submodulen, Organisation, Kommunikation und Materialverwaltung, Entscheidungsunterstützung sowie Statistik und Datenschutzmechanis- men unterschieden. 344 HL7 International, HL7 EHR-System Functional Model Release 2. 2014. 345 Haas, Medizinische Informationssysteme und Elektronische Krankenakten. 2005. S. 278, 510. - 198 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Datenschutzmodul Statistikmodul Module übergeordneter Schichten Abrechnungs-                                                Entschei-                                                        Behandlungs-                           brauchen Module der modul                                                  dungsunter-                                                        management-                            darunterliegenden Schicht stützungsmodul                                                          modul Kommunikationsmodul Med.      Material Archiv-      - Dokumentationsmodul                                                                                              Organi-    verwal-   verwal- sations-   tung       tung Ergebnis-                                                                                                                             modul Problem-/Ziel-/Plan dokumentation Diagnosen-                                         Laborwert-      Medikations-    Assessment- (Kap. 5.7) Klinische                                                    Pflegedoku- etc. dokumentation ) dokumentation   dokumentation mentation dokumentation                                     dokumentation Behandlungs-                                         Notizen prozess- dokumentation (Kap. 5.6) = Teil „Elektronische Patientenakte“ unterstützt die medizinische Dokumentation ! Falldatenverwaltung Patientendatenverwaltung Stammdaten- und Parameterverwaltung Abbildung 4-7: Schichtenmodell eines Medizinischen Informationssystems Auch für die Reifegradbestimmung des KIS-Einsatzes bedarf es einer Angabe von Systemen, Modulen und Funktionalitäten, was die beiden führenden Modelle wie HIMSS-MRAM und der CHIME-Foundation in unterschiedlicher Weise berücksichtigen und bei den Einstufungen ent- sprechende Begrifflichkeiten auftauchen, die Systemen oder Modulen oder Anwendungsfunk- tionen entsprechen: ▪      Die HIMSS EMRAM-Kriterien mit 7 Stufen, es werden verschiedene Subsysteme und Funktionalitäten benannt (siehe auch Kapitel 2, Tabelle 2-2) ▪      Das Reifegradmodell der CHIME Foundation, in welchem 10 Stufen definiert sind, de- nen jeweils ebenfalls bestimmte Module und Funktionalitäten zugeordnet sind. Die seit über 15 Jahren regelmäßigen Erhebungen zum IT-Einsatz in Krankenhäusern – zum Teil mit Fokussierung auf bestimmte Schwerpunkte wie Pflege, klinische Prozesse, Technologie usw. – durch die Forschungsgruppe Informatik im Gesundheitswesen der Fachhochschule Os- nabrück346 gibt ebenfalls ausführliche Informationen zu Modulen und Funktionalitäten von KIS. So wurde in 2018 ebenfalls der IT-Reifegrad erhoben347. Die nachfolgende Tabelle zeigt ausschnittsweise einige der wesentlichen (logischen) Systeme bzw. Module des klinischen Teiles des KIS, ggf. Submodule und einige beispielhaften Funktio- nalitäten. Bewusst wird an einigen Stellen beispielhaft auf Funktionalitätsebene detailliert, um im Folgenden darauf Bezug nehmen zu können. Tabelle 4-1: Liste von KIS-Modulen und -Funktionen (Auszug) Patientendatenverwaltungs- und Abrechnungssystem Patientenverwaltung Patientenstammdaten Bezugspersonen behandelnde Ärzte Fallverwaltung 346               siehe https://www.hs-osnabrueck.de/forschungsgruppe-informatik-im-gesundheitswesen/. 347               Hübner et al, IT-Report Gesundheitswesen - Schwerpunkt Wie reif ist die IT in deutschen Krankenhäusern? 2018. - 199 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Stationäre Fallverwaltung Fallanlage stationärer Fall Einweiserangaben Versicherungsangaben Wahlleistungserfassung …. DRG-Dokumentation Ambulante Fallverwaltung Ambulante Fallanlage Versicherungsangaben … Notfallaufnahme Stationäre Abrechnung Ambulante Abrechnung Kassenabrechnung Privatabrechnung Sonderabrechnungen Klinische Dokumentationsmodule/-funktionen Klinische Eingangsuntersuchung Anamnese Zwischenanamnese Diagnosedokumentation Symptomdokumentation Verordnungsdokumentation/Medikationsmanagement Medikationsübersicht Medikation/Medikament anordnen und Anordnung prüfen Medikament für Patienten bestellen Medikamentenausgabe dokumentieren Medikamenteneinnahme/-verabreichung dokumentieren Unverträglichkeit dokumentieren Medikationsabsetzung dokumentieren Medikationswiederaufnahme dokumentieren Visitendokumentation Aufklärungsdokumentation OP-Dokumentation Anästhesiedokumentation Wunddokumentation Schmerzdokumentation Anforderungs- und Befundrückmeldungsmanagement Leistungsanforderung Terminierung Leistungsdokumentation Befund-/Ergebnisdokumentation (siehe auch nachfolgender Punkt) Spezielle Therapiedokumentation Physiotherapiedokumentation Logopädiedokumentation Chemotherpiedokumentation Strahlentherpiedokumentation … Psychotherapiedokumentation … Pflegedokumentation Pflegeanamnese Pflegezielplanung Pflegeplanung Pflegemaßnahmendokumentation - 200 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Vitalwertdokumentation Medikamentenverabreichungsdokumentation Wunddokumentation Schmerzdokumentation Medikamentenverabreichungsdokumentation … Dabei kann vor allem die Dokumentation der Ergebnisse von diagnostischen und therapeuti- schen Maßnahmen - die ja sehr vielfältig sein können – hinsichtlich der Menge der einzelnen isolierten Dokumentationsfunktionen sehr umfangreich werden und in die Tausende gehen. Eine Detaillierung einzelner Bereiche wurde z.B. in den Förderkriterien zum Krankenhauszu- kunftsgesetz vorgenommen, z.B. für Funktionalitäten eines Medikationsmanagements, der Pflegedokumentation oder eines Aufnahme- und Entlassmanagements. Mit Blick auf großen Umfang an Funktionalitäten in einem KIS und der weitreichenden Gra- nularität von oft unabhängig voneinander verwendeten Funktionalitäten stellt sich prinzipiell die Frage, wie eine Migration bzw. die Granularität eines SaaS-Cloud-KIS sein kann. Einem mo- dularen Cloud-Ansatz kommt dabei zugute, dass die Nutzung der meisten Funktionalitäten sehr speziell in einem bestimmten Behandlungskontext erfolgen und gut abgrenzbar sind. 4.4.3 Cloud-Migration von KIS Die Software für die Kernsysteme und Subsysteme in Krankenhäusern ist über viele Jahre bis Jahrzehnte entstanden und basiert auch heute zum Teil noch auf Software-Technologien aus diesen Jahren. Solche Systeme werden auch als „Legacy-System“ bezeichnet, dementspre- chend wir im Folgenden vom „Legacy-KIS“ gesprochen. Diese Systeme lassen eine echte Mig- ration hin zu Cloud-fähigen webbasierten Systemen zumeist nicht ohne Neuimplementierung zu, da ihr Code für diese Zwecke nicht wiederverwendbar ist. Damit wird deutlich, dass es für Legacy-KIS einer schrittweisen Migration oder einer Neuimple- mentierung bedarf. Für ein migratives Vorgehen stellen sich einige der vorangehend aufge- führten Fragen: •   Welche fachlogischen Module mit definiertem „Bounded Context“ können für ein KIS angegeben werden? •   Wie maximal feingranular kann/sollte ein Cloud-KIS sein? •   Welche gekapselten Subsysteme können insgesamt als Cloud-Lösung ausgelagert wer- den? •   Welche Systeme/Module sind aufgrund loser Kopplung primäre Migrationskandida- ten? •   Welche Systeme/Module sind aufgrund vielfacher Verwendbarkeit/Notwendigkeit pri- märe Migrationskandidaten? Grobgranulares Cloud-KIS Mit Blick auf die heute in den Krankenhäusern vorherrschenden heterogenen KIS erscheint es in einem ersten Schritt auf den ersten Blick als einfachster Lösungsansatz, dass einzelne lose gekoppelte Subsysteme – die ja heute auch schon nur über Nachrichtenaustausch z.B. via Kom- - 201 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme munikationsserver und HL7-Nachrichten an das Kernsystem angebunden sind – als Cloudlö- sung migriert werden. Diese sind gegebenenfalls dann als granulare Monolithen („Modulti- hen“348) in der Cloud. Mit Blick auf Abbildung 2-1 und Abbildung 4-4 sind hierfür ideale Kandidaten die Subsysteme mit vertikalem Charakter wie z.B. RIS, PACS, LIS, Pflegeinformationssystem, Materialwirtschafts- system, Apothekensystem u.v.a.m. Die geschäftspolitische Entscheidung zur Migration für ein gesamtes Produkt muss aber jeder Subsysteme Hersteller für sich selbst treffen, also inwieweit er sein Produkt zu einer cloudfähigen Webanwendung umbaut bzw. migriert. Prinzipiell kön- nen so dann schon bestimmte Systemlandschaften als SaaS angeboten werden oder Kranken- häuser z.B. in einer Region sich in einer Community-Cloud entsprechender Lösungen und Leis- tungen – gegebenenfalls gemeinsam – bedienen. Denkbar heute schon z.B. für PACS. Im Sinne von Zukunftsfähigkeit, Nachhaltigkeit und Weiterentwicklung sollten Krankenhäuser bei der Auswahl zu Neubeschaffungen von IT-Systemen bei den entsprechenden Kosten Nut- zen Betrachtung zukünftig auch Kriterien für die teilweise oder gesamtheitliche Web-/Cloud- Fähigkeit dieser Systeme mit einbeziehen. Bei einem solchen grobgranularen Ansatz würden so über eine sehr lange Übergangszeit von ca. 10-15 Jahren „Hybridlandschaften“ aus Cloud-Lösungen und klassischen Client-Server-Le- gacy-Lösungen am Ende zu grobgranularen Cloud-KIS führen, bei denen zwar alle Kern- und Subsysteme Cloud-Software sind, die aber dennoch nicht die Anforderungen und Erwartungen an ein skalierbares Cloud-KIS erfüllen, da es sich immer noch um ein loses Ensemble von „Cloud-Monolithen“ oder „Cloud-Modolithen“ handelt. Cloud-KIS Subsysteme                                               Legacy-KIS                              Admin. Kernsystem PACS Materialwirt-                    Patientenverwaltung                     Finanzbuch- Radiologie-              schaftssystem                        & Abrechnung                           haltung informationssystem                                                                     Kostenrechnung KomServer Ambulanz-       Order-/Result-Mgm             Pflege- Labor-                                                     modul                                  informations- informationssystem     Küchen-                                                     PDMS                      system system                               Allg. Leistungs-     Intensiv   Anästhesie- stellenmodul                      modul         OP-Doku Med.Kernsystem Abbildung 4-8: Beispiel grobgranulares Cloud-KIS als Hybrid aus Cloud-Mono-/Modulithen und Legacy-Kernsystem in der Übergangsphase Eine Integration an der Oberfläche der einzelnen Systeme ist nur selten notwendig – wie auch heute schon bei heterogenen KIS, bei denen sich ein Benutzer selten in mehreren Subsystemen bewegen muss – und wenn, dann ist dies bezüglich der Cloud-Mono- oder Modulithen über geeignete Webaufrufe aus der proprietären Anwendung heraus leicht zu bewerkstelligen. 348 Der Begriff Modulith bezeichnet ein modulares aber immer noch nur insgesamt deploybares System. Siehe u. A: https://www.informatik-aktuell.de/entwicklung/methoden/modulith-first-der-angemessene-weg-zu-microser- vices.html. Diese können zwar Cloud-fähig sein, sind aber nur modular für den Hersteller und trotzdem von außen nur wenig offen, also monolithisch. Als Geschäftspolitik schützen Sie vor Mitbewerbern und modularen Mitanbie- tern. - 202 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Cloud-Mono-/Modulithen können über die bereits vorhandenen Integrationstechnologien – in der Regel Kommunikationsserver zum Management des Messagings – ebenso uni- oder bidi- rektional in die Systemlandschaft eingebunden werden, zumal die gängigen Kommunikations- server alle dazu notwendigen technischen Protokolle bereits beherrschen. Das grobgranular Cloud-KIS selbst kann jedem der in Kapitel 2 genannten Modelle folgen, vermutlich wird man aber für solche Systeme, die Patientendaten enthalten, eher eine Com- munity oder Privat Cloud wählen, ggf. auch On-Premises. Feingranulares Cloud-KIS Im Gegensatz zum grobgranularen Cloud-KIS besteht ein feingranulares modulares Cloud- Softwaresystem aus Web- und Cloud-fähigen Modulen, die im Sinne des Domain Driven De- sign je eine (Geschäfts)Funktionalität für jeden bestimmten administrativen und/oder klini- schen Anwendungskontext zur Verfügung stellen (siehe auch Abbildung 4-1). Diese Module sind nicht mehr nach einzelnen Systemen bzw. Systemgrenzen im klassischen Sinne ausgerich- tet, sondern nach der für einen Benutzer in einer bestimmten Situation notwendigen Funktio- nalität („funktionaler Schnitt“) mit abgrenzbarem Kontext („Bounded Context“). Dabei kann sich dieser „Bounded Context“ einerseits um die sich in einer bestimmten Situation notwendige Funktionalität und zugehörigen Informationsobjekttypen beziehen (Design-Aspekt), anderer- seits dann aber auch bezogen auf die Datenausprägungen, die dieser Funktionalität zur Lauf- zeit zugrunde liegt. In diesem Sinne kann es dann mehrere Instanzen von Modulen geben, die sich nur im „Bounded Data Context“ (Laufzeitaspekt) unterscheiden. Solche modularen Cloud-Lösungen werden auch als Native Cloud Applications (NCAV) oder Cloud Native Anwendungen bezeichnet, da sie die Möglichkeiten und Vorteile der technischen Cloud-Infrastrukturen und softwaretechnischen Architektur konsequent nutzen bzw. zur Lauf- zeit alle Vorteiler skalierbarer Infrastrukturen ausschöpfen können. Die Anwendungssystem- module können maximal flexibel und ortsunabhängig auf beliebigen Servern, gegebenenfalls auch redundant bzw. gespiegelt, eingesetzt werden und benötigen weder eine bestimmte Hardware noch spezifische Betriebssysteme. NCA-Entwicklungs- und Bereitstellungsumgebun- gen werden zunehmend als Produkte am Markt angeboten. An einem kleinen Beispiel sei diese Auflösung des systembezogenen Denkens und Entwickelns verdeutlicht: In vielen Abteilung oder Arbeitsbereichen wird heute die Führung eines zumeist ressourcen-orientierten Terminkalenders notwendig349. Eine solche Funktionalität unterschei- det sich im Grunde zwischen der Radiologie, einer Spezialambulanz, der OP-Raumbelegungs- planung, der Terminplanung für kleinere Leistungsstellen wie EKG, EEG etc. nicht wesentlich. Denn es gibt Ressourcen und Slots und konkret zu planenden Events mit einer bestimmten Plandauer. Bei einem heterogenen KIS ist aber in jedem Subsystem und in der Regel auch im Kernsystem Terminplanungssoftware enthalten, die mit dem Erwerb des entsprechenden Kern- /Subsystems natürlich auch bezogen und bezahlt werden muss. Im Grunde wird also eine für das gesamte Krankenhaus bzw. viele einzelne Organisationseinheiten notwendige Kernfunkti- onalität mehrfach betrieben und bezahlt. 349 Zu allgemeinen Betrachtungen siehe Haas, Medizinische Informationssysteme und Elektronische Krankenakten. 2005. S. 530 ff. - 203 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Dieses Beispiel lässt sich auf sehr viele andere Funktionalitäten im KIS übertragen – so zum Beispiel die Workflowsteuerung, die klinische Diagnosedokumentation, die Medikationsdoku- mentation, eine wenn überhaupt vorhandene explizite Symptomdokumentation, die Personal- einsatzplanung, verschiedene Assessments, Anamnesedokumentation, die Verwaltung von Systemstammdaten wie z.B. der Krankenhausstruktur und des zugeordnetes Personals sowie der Benutzer, der Verwaltung von Semantik, die Benutzerverwaltung und das Rechtemanage- ment u.v.a.m.. Auch eine Patientenstammdaten – und Falldatenverwaltung gibt es im Grunde funktional in ähnlicher Ausprägung im Kernsystem und in jedem patientenbezogenen Subsys- tem gesondert. Zusätzlich werden so im heterogenen System viele Daten redundant gehalten und der Aufwand der integren Synchronisation ist beträchtlich bzw. für die manuelle Doppel- pflege wie das bei den Systemstammdaten üblich ist. Alle diese vorgenannten Funktionalitäten – bzw. sogar noch granularere daraus – können im Prinzip als gekapselte Module mit loser Kopplung realisiert und in unabhängigen wie auch immer kommunizierenden Containern in einer Cloud betrieben und konsumiert werden. Ein modulares multivendorfähiges Cloud-KIS (mCloud-KIS) ist also die Summe aller cloudbasierten MicroServices (im Folgenden mit Cloud-Micro Service-Modul350 bezeich- net, CMSM abgekürzt), die für den operativen Betrieb und die Steuerung sowie für das taktische und strategische Krankenhausmanagement notwendig sind. Im Gegensatz zum grobgranularen (Hybrid)Ansatz stellt sich ein feingranulares Cloud-KIS wie folgt beispielhaft gezeigt dar, hier mit Blick auf die ISO-CCRA beschränkt auf den User-Layer. Krankenhaus A Ärztl. Anamnese            Parameterverlauf Terminvergabe                         Arbeitsliste       Rollenhierarchie Stationäre Auftrags- Patientenaufnahe      Terminliste                                OP-Aufklärung          Benutzer anlegen vergabe ambulante          Bettenbelegung      Barthelindex                Laborwert- Patientenaufnahme                                                        übersicht       Knochendichte Stations-        Pflegeanamnese Notfallaufnahme           übersicht                                                      Rechtprofil              Krankenhaus B EKG-Doku             ändern Rö-Doku Triage               eMail-Erstellung Messagehandler Contexthandler Eventhandler                                                 Krankenhaus C Abbildung 4-9: Beispiel für feingranulares Cloud-KIS (nur User Layer und Auszug) Zur Identifikation geeigneter Modul-Kandidaten für einen Migrationsprozess im Rahmen des strategischen Designs können folgende Fragen herangezogen werden: ▪      Handelt es sich um Funktionalitäten in und mit einem beschränkten Kontext für eine dedizierte betriebliche Aktivität – also im Sinne des DDD um eine Subdomäne? ▪      Wird die Funktionalität von vielen Akteuren in unterschiedlichen Organisationseinhei- ten des Krankenhauses benötigt? 350 Der hier gewählt Begriff soll verdeutlichen, dass im Folgenden ein Microservice jeweils ein feinstmöglichstes fachlogisches Modul realisiert. - 204 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme ▪   Ist die Kontextüberschneidung mit anderen Kontexten und vor allem auch mit dem ad- ministrativen bzw. medizinischen Kernsystem klein und damit eine lose Kopplung mit wenig Interaktion möglich? Das heißt: Kann ein isoliertes dediziertes Informationsmo- dell dafür angegeben werden? ▪   Wird die Funktionalität flexibel und unabhängig von Raum und Zeit – also ubiquitär – notwendig? Darüber hinaus kann noch untersucht werden, ob innerhalb des beschränkten Kontextes bzw. der Subdomäne weitere abgrenzbare Aktivitäten existieren und somit eventuell eine weitere Zerlegung sinnvoll sein kann. Eine solche Betrachtung ist wichtig, um nicht direkt wieder zu große abhängige Einheiten entstehen zu lassen. Daraus ergibt sich eine allgemeine Kriterienliste für Design-/Migrationsentscheidungen: Tabelle 4-2: Kriterienmatrix zur Identifikation von CMSM-Kandidaten Kriterium                            Ja    Nein     Anmerkung Betriebliche Subdomäne? Vielfache betriebliche Nutzung? Kontextüberschneidung klein? Ubiquitäre? Weiter Untergliederung? Bezüglich einer Migration von Legacy-Systemen zeigt sich, dass vor allen Dingen bei der Neu- entwicklung von Funktionalitäten architektonisch die ersten Schritte in Richtung eines mCloud- KIS vollzogen werden können, indem solche Funktionalitäten in der vorangehend beschriebe- nen Weise als Cloud-MS-Module (CMSM) realisiert und mittels loser Kopplung und Kon- textaustausch in das bestehende Altsystem integriert werden. 4.4.4 Fallbeispiele für CMSMs Vorbemerkungen Ein wesentlicher Aspekt ist die Kopplung von CMSM mit Legacy-Systemen bzw. mit anderen CMSM. Gerade für einen Migrationsprozess und die Förderung von Anwendungsinnovationen ist auch eine Zusammenarbeit von CMS_M und Legacy-Systemen von großer Bedeutung. Da- bei sind drei Aspekte von grundlegender Bedeutung, die einer Entscheidung und Implemen- tierung bedürfen: 1   Wie erhält das CMSM den mit dem KIS bzw. anderen Modulen überlappenden Kontext? 2   Wie kann der Aufruf des CMSM aus dem Legacy-System (oder anderen CMSM) heraus erfolgen? 3   Welches eigene „Gedächtnis“ hat das CMSM, also welche Daten werden dort primär für die Aufgabe gekapselt gespeichert? - 205 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Legacy-KIS (GUI-)          Admin. Kernsystem 2       Aufrufpunkt CMS-Modul 3                               (Clinical) Context 1                               Med.Kernsystem Abbildung 4-10: Legacy-System und Cloud-Modul Für die Implementierung der Aufrufbarkeit ist von Vorteil, dass aufgrund der den CMSM zu- grundeliegenden Internettechnologie ein solcher Aufruf aus Legacy-Systemen einfach zu be- werkstelligen ist, da nur eine http-Adresse bzw. Ressource-Adresse und die Übergabeparame- ter angegeben werden müssen, was einer sehr losen Kopplung entspräche. Andere Formen der Parameterübergabe via Persistenzschicht sind aber auch denkbar. Für eine isolierte Kon- textübermittlung – was eine losere Kopplung darstellt und keine direkten Schnittstellenabhän- gigkeiten schafft – können diverse Ansätze verfolgt werden, die jeweils ihre Vor- und Nachteile haben vor allem mit Blick auf die Kopplungsenge. ▪   Mittels RPC bzw. mittels Services ▪   Mittels Event-Bus, ggf. zerteilt in Segmente ▪   Mittels Messaging-Infrastruktur z.B. Kommunikationsserver ▪   Mittels Kombination der Ansätze Weitere Überlegung hierzu finden sich in Kapitel 4.9.3. CMS-Module können bei entsprechender cloud-konformer Realisierung und als Webanwen- dung bei Nutzung von Instrumenten des aktuellen Standes der Software-Technik auch respon- sive sein, und somit auf beliebigen auch mobilen Geräten genutzt werden. Dies ist für viele Funktionalitäten eines KIS bedeutsam, da Versorgung oft in mobilen Kontexten erfolgt und eine zeitnahe Dokumentation am Point-of-Care im Grunde nur mit Mobilgeräten möglich ist. Auch die Einbindung von nativen Apps wird dadurch einfach. CMS-Module sollten containeri- siert werden. Fallbeispiel Medikationsmanagement Ein Medikationsmanagement ist zentraler Teil jedes medizinischen Informationssystems und der Medikationsplan als persistierter Ausdruck der patientenspezifischen Ist-Situation im Sinne einer Aggregation der aktuellen Medikationen ist nicht nur im lokalen System von Relevanz, sondern als Bundesmedikationsplan auch übergreifend. Die Funktionalität zur Dokumentation von Medikationen kann in verschiedensten Subsystemen eines KIS heute vorkommen bzw. notwendig werden. Je nach klinischem Setting ist dabei die alleinige Dokumentation der Verordnung ausreichend (so zum Beispiel im ambulanten Bereich), oder aber es muss sowohl die Ausgabe/Stellung von Medikamenten oder sogar die Verabreichung/Einnahme dokumentiert werden. Darüber hin- aus gibt es gegebenenfalls die Anforderung, bei allen Verordnungen eine AMTS- Prüfung durchzuführen. Auch ist denkbar, dass die Verblisterung von Medikamentensets auf Basis einer - 206 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Aggregation von Anordnungen erfolgen soll. Damit können im Grunde die folgenden Anwen- dungsfälle mit einem definierten gemeinsamen oder eigenen „Bounded Context“ angeben werden: ▪   Medikationsplan einsehen ▪   Medikation/Medikament anordnen ▪   Medikationsanordnung prüfen (AMTS-Prüfung) ▪   Medikament(e) für Patienten bestellen ▪   Medikamente zusammenstellen und ggf. Verblisterung durchführen ▪   Medikament(e) ausgeben ▪   Medikament(e) einnehmen ▪   Unverträglichkeit dokumentieren ▪   Medikationsabsetzung dokumentieren ▪   Medikationswiederaufnahme dokumentieren Diese Anwendungsfälle spiegeln auch in gewisser Weise den Objektlebenszyklus einer einzel- nen Medikation wider, denn im Verlauf des Behandlungsprozesses ist die Abwicklung einzelner Medikationen ein eigenständiger paralleler Subprozess. Bezüglich der vorangehenden Fragen ergibt sich für die Medikationsdokumentation folgendes Bild: Tabelle 4-3: Eignungsbewertung Medikationsmanagement für CMSM (Kriterienmatrix) Kriterium                             Ja    Nein     Anmerkung Betriebliche Subdomäne?                X             Medikationsverordnungen und alle damit zusammenhängenden Arbeiten sind gut abgrenzbar und im Sinne des Vielfache betriebliche Nutzung?        X             Im Krankenhaus werden in vielen Abteilun- gen Medikationen verordnet und Medika- mente verabreicht. Natürlich erfolgt die hauptsächlich im Rahmen der fachärztli- chen Behandlung auf Station, aber bei vie- len diagnostischen oder therapeutischen Maßnahmen wird auch eine (punktuelle) Begleitmedikation notwendig. Kontextüberschneidung klein?           X             Mit Blick auf den gesamten klinischen Kontext eines Patienten und alle Daten im KIS kann die Kontextüberschneidung als relativ gering angesehen werden. Ubiquitär?                             X             Medikation sollte immer und überall mög- lich sein. Weiter Untergliederung?                X             Wie vorangehend beschrieben besteht der ganze Vorgang aus vielen z.T. auch optio- nalen Schritten/Aktivitäten die zum Teil auch vom Patienten durchgeführt werden können (z.B. Einnahme und Dokumenta- tion dieser). - 207 -