Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme bilen Geräten und Mehrfachnutzbarkeit von modularen Komponenten, aber auch in kür- zeren Entwicklungszyklen für die (Cloud-)Software, einfacherer Erweiterbarkeit, erhöhter Stabilität der Software und Vereinfachung des Software Development Lifecycle. (10) Eine weitere Motivation besteht darin, dass sich durch Cloud-KIS das lokal hinsichtlich Anzahl und Know-How-Breite begrenzte IT-Personal wieder stärker auf gestaltende und Governance-Aufgaben konzentrieren kann, um den digitalen Wandel im Krankenhaus optimal orientiert an den lokalen Bedürfnissen planen, umzusetzen und begleiten zu können. (11) Die Zielprojektion für ein Cloud-KIS muss es sein, dass für Krankenhäuser bzw. stationäre Einrichtungen jeglicher Art ein skalierbares Set an domänenspezifischen Software-Funk- tionalitäten zur Verfügung steht und die Funktionalitäten je nach Einrichtung und Bedarf bezogen und genutzt werden können. (12) Ein modulares Cloud-KIS (mCloud-KIS) ist eine nutzer- und nutzenzentrierte webbasierte Softwarelandschaft bestehend aus domänenspezifischen voneinander unabhängigen fachlichen und systemtechnischen Microservice-Modulen, die von verschiedensten Soft- wareherstellern stammen können und mittels semantischer Interoperabilität auf Basis geeigneter Mechanismen zusammenarbeiten. („modular multivendor meaningful Cloud- 3 HIS“ = m cloud-HIS). (13) Cloud-KIS bedeutet eine radikale Abkehr von heterogenen aus abgeschlossenen mini- mal-interoperablen proprietären Informationssystemen nicht skalier- und orchestrierba- ren KIS, wie sie heute allerorten betrieben werden. (14) Mit Legacy-KIS werden keine regionale digitalen Ökosysteme ähnlich wie in anderen Branchen entstehen können, auch wird zunehmend die Innovation stocken, mobile Nut- zung ist nur eingeschränkt möglich oder es müssen aufwändig Zusatz-Apps entwickelt und von den Krankenhäusern bezahlt werden. (15) Die softwaretechnische „Cloudifizierung“ von Legacy-Systemen kommt einer Neuent- wicklung gleich, da Code nicht übernommen werden kann und auch eine Überführung in eine moderne funktionsorientierte Modularisierung im Sinne eines „Domain Driven Design“ nicht ohne Refactoring und Neuimplementierung möglich ist. (16) Modulare Cloudifizierung von Legacy-KIS ist gut möglich, da alle medizinischen Hand- lungen und die zugehörigen IT-Funktionalitäten modular sind. (17) Eine schrittweise Migration von Legacy-KIS hin zu Cloud Native Anwendungen ist gut möglich. So können neue Funktionalitäten als Cloud Native Anwendungen entwickelt werden und interoperabel mit dem Legacy-KIS betrieben werden. Der Einbau entspre- chender Aufrufschnittstellen in die Legacy-Systeme ist einfach zu bewerkstelligen. (18) Das KHZG bietet eine große Chance, dass für die in §19 benannten Fördergegenstände die Legacy-KIS um Cloud Native Module dafür erweitert werden. (19) Legacy-KIS-Anbieter werden auf absehbare Zeit eher nicht aus eigenem Antrieb zu Cloud-Nativ Anwendungen migrieren, hierzu bedarf es eines externen Bedarfes und Drucks durch Kunden und Politik. (20) Bei Förderprogrammen zur Digitalisierung im Krankenhaus sollten zukünftig Förderkri- terien die Pflicht zur Implementierung als Cloud-fähige Lösung beinhalten, Krankenhäu- ser sollten bei Ausschreibungen auf die Perspektiven des Herstellers bezüglich der Clou- difizierung des Legacy-Systems achten. - 181 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme (21) Ein großes Potenzial für eine „Cloudifizierung“ von digitalen Lösungen bzw. der Realisie- rung von Cloud Native Anwendungen liegt im Krankenhaus- bzw. Gesundheitswesen in den über viele Jahrzehnte entwickelten Interoperabilitäts- und Semantikstandards – hier vor allem den Standards von HL7 und IHE und SNOMED. So Kann FHIR direkt auch für die Interoperabilität von Microservices eingesetzt werden, CDA-Dokumente als justiti- able Persistenzobjekte können als strukturierte und formalisierte Dokumente für die jus- titiable Dokumentenspeicherung und den Austausch genutzt werden. (22) Alle Systeme/Module eines Cloud-KIS müssen in der Lage sein, auf Basis einer kranken- hausindividuellen Policy Daten bzw. Dokumente in einem offenen Format in ein Lang- zeitarchiv zu speichern. (23) Cloud-KIS können in optimaler Weise Cloud-Repositories nutzen. Der Betrieb und die Inhaltspflege von Cloud-Repositories für verschiedenste Objekttypen wie Organisatio- nen, Medikamente, Semantikkataloge, Materialien, Bettenangebote u.v.a.m. auf regiona- ler oder nationaler Ebene hat sowohl bezogen auf die Integrität von Daten in einem ver- teilten System also auch ökonomisch durch Einmalpflege erhebliche positive Effekte auf die zukünftige Entwicklung eines digitalen Gesundheitswesens. (24) Für Cloud-KIS wird mehr als bisher ein Compliance-Management System notwendig und der konsequente Einsatz vorhandener Compliance-Mechanismen. Hierzu zählt auch eine konsequente Nutzeridentifikation und -authentifikation jedes Benutzers unabhängig von der beruflichen Rolle im Krankenhaus. Cloud-KIS bieten die Chance, heute allen Bürgern vertraute Authentifikationsmechanismen auch für den KIS-Zugang zu nutzen. (25) Ein Single Point of Failure ist die Infrastrukturanbindung zwischen Krankenhaus und Cloud-Provider. Daher ist hierfür eine Mehrfachauslegung über getrennte Zugangskno- ten vorzusehen. (26) Die Kenntnisnahme der hoch schutzwürdigen medizinischen Daten durch den Provider ist soweit wie möglich zu verhindern bzw. zu erschweren und gleichzeitig hierzu auch vertragliche Regelungen zu schaffen und deren Umsetzung regelmäßig zu überprüfen. Kryptographische Verfahren, verteilte Geheimnisse und Trennung der Verwaltung von identifizierenden und medizinischen Daten in verschiedene Anbieter-Plattformen sind mögliche Ansätze. Hier besteht weiterer Forschungsbedarf. (27) Cloud-Provider können heute ein für die Krankenhäuser wichtiges und notwendiges ho- hes Maß an Verfügbarkeit und Performance bieten, oft weit über das hinaus, was beim Vor-Ort-Betrieb möglich ist. (28) Cloud-KIS können in optimaler Weise mit anderen Cloud-Lösungen und gesundheits- telematischen Anwendungen der TI interoperieren, da sie selbst konsequent serviceori- entiert sind. (29) Für viele Problem- und Fragestellungen z.B. von der Authentifikation über kryptographi- sche Verfahren, der Datenhaltung bis hin zu generischen Lösungen für Interoperabilität und Oberflächengenerierung gibt es heute frei verfügbar Programm-Bibliotheken bzw. Frameworks, die eine Entwicklung von Cloud-KIS effektiv bewerkstelligen lassen. (30) Die Zukunft wird geprägt sein von lokalen digitalen Gesundheits-Ökosystemen, in denen viele Gesundheitseinrichtungen aber auch Patienten und ihre Angehörige kooperativ di- gital zusammenarbeiten und sich einerseits digitale Ressourcen teilen, aber auch durch - 182 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme digitale Verfahren direkt gemeinsam Patientenbehandlungen planen, durchführen, do- kumentieren und überwachen. Hierzu werden gemeinsame Repositories für vielfältige Aspekte eingesetzt werden, so auch für medizinisches Wissen und klinische Pfade. (31) Wissensgewinnung und Wissensentwicklung können in der Medizin nur noch gemein- sam und multizentrisch erfolgen. Cloud-KIS bieten die Chance, Community-Plattformen aufzubauen, die verzahnt mit KIS einen solchen gemeinsamen Wissensprozess und ein gemeinsames Wissensmanagement ermöglichen bei gleichzeitiger direkter kontextsen- sitiver Aufrufbarkeit und Integration des Wissens in die KIS-Funktionalitäten. 4.2 Einführung und Überblick „Cloud Computing refers to both the applications delivered as services over the Internet and the hardware and systems software in the datacenters that provide those services. The services themselves have long been referred to as Software as a Service (SaaS). The datacenter hardware and software is what we will call a Cloud.“317 “Cloud computing is a paradigm for enabling network access to a scalable and elastic pool of shareable physical or virtual resources with self-service provisioning and administration on de- mand. Note: Examples of resources include servers, operating systems, networks, software, ap- plications, and storage equipment.”318 Ergänzt man die Definition zu einem KIS aus Kapitel 2.1, kann ein Cloud-basiertes Kranken- hausinformationssystem (Cloud-KIS) definiert werden als: „Ein Cloud-KIS ist die Summe aller über eine Cloud beziehbaren Plattform- und Software-Ressourcen zur Verarbeitung aller notwendigen Daten zur Unterstützung aller administrativen, logistischen und medizini- schen Vorgänge bis hin zum Controlling und dem Qualitätsmanagement und für das strategische Management von Krankenhäusern.“ Aber: Die Verschiebung von Legacy-Systemen in die Cloud führt nicht zu wirklichen Cloud- Systemen. „But for now, know that a system that was architected and optimized to run in a traditional data center cannot take advantage of all the benefits of the cloud, such as elasticity. Thus we need a modern architecture to reap the benefits of the cloud.”319 Cloud Lösungen meist in Form von Webanwendungen werden heute von großen Technolo- gieunternehmen für ihre Plattformen, für elektronische Markplätze und als Branchenlösungen (vertikale SaaS) für vielfältige Branchensegmente oder in Form von für viele Unternehmen all- gemeinverwendbaren Lösungen (horizontale SaaS) eingesetzt. Letztgenannte reichen z.B. von Office-Lösungen, über Kollaborations-Werkzeuge und WIKIs, Organisations- und Workflow- Lösungen bis hin zu Autorensystemen und eLearning-Plattformen oder Softwareentwicklungs- Repositories. Damit einher geht eine Entwicklung, bei der Softwarelösungen sowohl als lokal installierbare Lizenzlösungen als auch als im Jahresabonnement hybrid angeboten werden 317 Armbrust et al, Above the Clouds: A Berkeley View of Cloud Computing. 2009. S. 1. 318 International Standards Organisation: ISO/IEC 1778: Information technology - Cloud computing — Overview and vocabulary. 2014. S. 2. 319 Gilbert, Cloud Native Development Patterns and Best Practices : Practical Architectural Patterns for Building Mod- ern, Distributed Cloud-native Systems. 2018. S. 9. - 183 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme bzw. wurden, da einige Hersteller beginnen, ihre Lösungen nur noch als cloud-basierte Jahres- abonnements anzubieten – sei es in ihrer Public Cloud oder aber in einer ebenfalls von ihnen gehosteten Privat Cloud. Problematisch ist bei letztgenanntem Trend, dass ein On-Premises- Betrieb damit faktisch ausgeschlossen wird, also Kunden ihre technisch-/softwaretechnische Souveränität verlieren. Daneben gibt es inzwischen auch vielfältige Open Source Cloud-Lösun- gen ebenfalls für viele Branchenbereiche und Anwendungszwecke. Für Cloud-Lösungen können als Basis heute vielfältige Technologien und Plattformen einge- setzt werden und es existieren eine Reihe von Anforderungen und Zertifikaten, in Deutschland insbesondere der vom BSI entwickelte B5-Kriterienkatalog (C5 = Cloud Computing Compliance Controls Catalogue), der u.a. auf diversen anderen Zertifikatskatalogen basiert.320 Die Hauptmotivation von Cloud-Software und SaaS besteht im flexiblen, also skalierbaren An- gebot, Bezug und der Abrechnung von Software und deren Nutzung – auch unabhängig von Raum und Zeit – für die Kunden des Zielmarktes via Internet-Technologie. Eine weitere Moti- vation ist aber auch die modulare und eventuell verteilte Weiterentwicklung und der Ausbau um neue Funktionalitäten, also die Agilität der Entwicklung und der Software. Dies sind alles Aspekte, die schon immer im Kern der Bemühungen um gute betriebliche Informationssysteme standen: Gut modularisiert und verstehbar, wiederverwendbar und erweiterbar.                         321 Während in einem Sercive-RZ betriebene Monolithen alter Prägung („Legacy-Systeme“), die im Prinzip als Client-Server-Systeme in einem Backend-System – oftmals betrieben durch Nut- zung der Client Software ebenfalls auf dem Server mittels Thin Clients vor Ort– eigentlich nur einen Shift vom lokalem Betrieb auf entfernten Betrieb darstellen, hat in den vergangenen 20 Jahren auch vor dem Hintergrund zunehmender Realisierung und Betrieb „großer“ Weblösun- gen ein Entwicklungs- und Erkenntnisprozess stattgefunden zum Thema, wie „große“ Software- systeme sinnvoll zu zerlegen und zu entwickeln sind. Weitere Motivationen waren und sind die Problematik der immer schlechteren Wart- und Weiterentwicklungsmöglichkeiten der mono- lithischen Großsysteme322 sowie das komplexe langdauernde Deployment. Das Paradigma der Zukunft heißt nun: Modulare Microservice- und API-basierte Anwendungslösungen, wobei sich der Zuschnitt solcher Microservices an den fachlichen Notwendigkeiten entlang der Bear- beitungsvorgänge orientiert und die Prinzipien Kohäsion und lose Kopplung im Mittelpunkt stehen. Cloud-nativ-Anwendungen bzw. Anwendungssysteme stellen zwar softwaretechnisch mit Blick auf die Zerlegung großer Systeme in kleinere Einheiten kein neues Paradigma dar, Art und Weise des Zuschnitts und konsequente Servicebasierung und die Organisation der Soft- wareentwicklung aber schon. Dementsprechend existierten für Cloud-Softwaresysteme verschiedene aber sich ähnelnde Ar- chitekturansätze, wie z.B. publiziert im ISO-Standard323, vom National Institute of Standards and 320 Bundesamt für die Sicherheit in der Informationstechnik, Kriterienkatalog Cloud Computing C5:2020. 321 Parnas, On the criteria to be used in decomposing systems into modules. Commun. ACM, Band 15, Nr. 12, S. 1053–1058, 1972. 322 Vernon spricht in diesem Zusammenhang von einem „Big Ball of Mud“ (Vernon, Domain-Driven Design kompakt. 2017. S 57. Teilweise wird von Softwareverrottung gesprochen, also dem langsamen Zerfall. 323 International Standards Organisation, ISO/IEC 17789: Information technology -Cloud computing - Reference architecture. 2014. - 184 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Technology US Department of Commerce (NIST)324 und von kommerziellen Unternehmen, die Frameworks ermöglichen und fördern für die Implementierung von Cloud-Softwaresystemen oder anderen Unternehmen die Integration eigener Erweiterungen in ihre Cloud-Lösung. Cloud-Native Architekturen sollen auch Elastizität und Resilienz fördern. Die Erwartungen der Unternehmen an Cloud-Nativ-Systeme sind im Wesentlichen325 •    Kürzere Entwicklungszyklen für die (Cloud-)Software •    Erhöhte Stabilität der Software •    Vereinfachung des Software Development Lifecycle Dieser mehr entwicklungstechnisch orientierten Liste können aber einige weitere auch ökono- misch relevante positive Aspekte hinzugefügt werden, so z.B. der passgenaue und im Zeitver- lauf leicht änderbare Zuschnitt der Softwarelandschaft für ein diese nutzendes Unternehmen, die Beförderung von Innovation und Wettbewerb bei der Entwicklung von in bestehende Lö- sungen integrierbaren Cloud-Modulen, die leichte Austauschbarkeit von Modulen und die Er- möglichung auch von branchenbezogenen Ökosystemen z.B. im Rahmen von Community Clouds oder Mischformen aus Privat- und Community Clouds. Letztendlich kann auch ein ein- facher „Roll-out“ von Lösungen in der Fläche angeführt werden, da für eine Nutzung keine aufwändigen lokalen Installationen mehr notwendig sind, lediglich in der Regel eine initiale Orchestrierung und Parametrierung auf die spezifischen Bedürfnisse hin. Das macht Cloud- Lösungen nicht nur für die Kunden werthaltig, sondern auch für Hersteller von Standard-Soft- ware interessant. Herausforderungen für das Cloud-Computing sind neben der paradigma-gerechten Soft- warearchitektur und Implementierung u.a. in den folgend genannten Bereichen angesiedelt:                            326 ▪    Cloud Computing Architectural Framework ▪    Governance and Enterprise Risk Management ▪    Legal Issues: Contracts and Electronic Discovery ▪    Compliance and Audit ▪    Information Management and Data Security ▪    Portability and Operability ▪    Traditional Security, Business Continuity and Disaster Recovery ▪    Data Center Operatns ▪    Incident Response, Notification and Remediation ▪    Application Security ▪    Encryption and Key Management ▪    Identity, entitlement and Access Management ▪    Virtualization ▪    Security as a Service 324 Liu et al, NIST Cloud Computing Reference Architecture. Recommendations of the National Institute of Standards dann Technology. 2011. 325 IDG Research Services, Studie Cloud Native 2020. S. 7. 326 Kalloniatis et al, Towards the design of secure and privacy-oriented Information Systems in the Cloud: Identifying the major concepts. Research Paper 2014. - 185 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Im ISO-Standard 17789327 werden als (Querschnitts)Aspekte aufgeführt: ▪    auditability ▪    availability ▪    governance ▪    interoperability ▪    maintenance and versioning ▪    performance ▪    portability ▪    protection of personally identifiable information ▪    regulatory ▪    resiliency ▪    reversibility ▪    security ▪    service levels and service level agreement. Eine Taxonomie der Sicherheitsaspekte von Cloud-Computing Systemen findet sich in der Stu- die des Fraunhofer AISEC328, die deutlich macht, dass auf allen Ebenen – Infrastruktur, Anwen- dung und Plattform, Verwaltung und Compliance – vielfältige Aspekte zu berücksichtigen sind. Die Chancen von Cloud-Systemen und deren Nutzung für den Aufbau branchenspezifischer digitaler Ökosysteme haben zu der europäischen Großinitiative GAIA-X geführt mit dem Ziel, für Europa, seine Staaten, seine Unternehmen und seine Bürgerinnen und Bürger die nächste Generation einer Dateninfrastruktur zu schaffen, die höchsten Ansprüchen an digitale Souve- ränität genügt und Innovationen fördert. Diese Infrastruktur wird als Wiege eines Ökosystems verstanden, in dem Daten und Dienste verfügbar gemacht, zusammengeführt und vertrauens- voll geteilt werden können.329 Ein Ansatz, der auch für das Ökosystem „Gesundheitsversorgung“ gelten kann, so z.B. für regionale sektorübergreifende Versorgungsverbünde. Cloud-KIS sind daher nicht nur eine andere Form von KIS, sondern ein völlig neuer Lösungsansatz und können eingepasst in regionale digitale Ökosysteme z.B. auf Basis einer Community Cloud Teil einer neuen innovativen digitalen Infrastruktur für die koordinierte transparente und den Patienten einbeziehende Gesundheitsversorgung sein. Cloud-KIS und das Verständnis um Cloud-native Anwendungen werden wesentliche Treiber für die Digitalisierung im Gesundheitswesen wer- den. Die Zielprojektion für ein Cloud-KIS muss es daher sein, dass für Krankenhäuser bzw. stationäre Einrichtungen jeglicher Art ein skalierbares Set an domänenspezifischen Software-Funktionali- täten – genauer gesagt containerbasierte interoperable Anwendungssystembausteine (im Folgenden auch als Cloud-Microservice-Module (CMSM) bezeichnet) – zur Verfügung steht, die je nach Einrichtung und Bedarf bezogen und genutzt werden können. Dies bedeutet eine radikale Abkehr von heterogenen aus abgeschlossenen minimal-interoperablen proprietären 327 International Standards Organisation, ISO/IEC 17789 Information technology – Cloud computing – Reference architecture. 2014. S. 8 f. 328 Streitberger, Ruppel: Cloud Computing. Schutzziele. Taxonomie. Markübersicht. 2009. S. 42. 329 Siehe unter https://www.bmwi.de/Redaktion/DE/FAQ/Dateninfrastruktur/faq-projekt-gaia-x.html. - 186 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Informationssystemen nicht skalier- und orchestrierbaren KIS, wie sie heute allerorten betrie- ben werden. 4.3 Architektonische Aspekte Mit Blick auf die Definition von Armbrust et. al. stellt sich die Frage, ob für Software-as-a-service (SaaS) andere Softwarearchitekturen notwendig werden bzw. sinnvoll sind, als für proprietäre Legacy-Systeme, die auch noch heute dem „Vor-Ort Client-Server-Paradigma“ folgen. Der hierzu geführte Diskussions- und Erkenntnisprozess kann in drei Phasen eingeteilt werden: 1. Schon 1996 wurde erstmalig der Begriff „Serviceorientierte Architektur“ (SOA) ge- prägt, die Idee wurde dann ab dem Jahr 2004 vermehrt aufgegriffen, was sich durch die Vielzahl von Lehrbüchern zum Thema ab diesem Jahr verdeutlichte. Es zeigte sich aber in der Folge, dass der Service-Bus einen Single Point of Failure darstellt und weitere Nachteile mit der SOA einhergehen. 1999 wurde die OSGi Allianz330 gegründet, die zum Ziel hatte, einen offenen Standard für offene modulare Serviceplattformen auf Basis von JAVA zu spezifizieren. Zentrale Komponente ist hier das Modul und die OSGi-μSer- vices. 2. Im Jahr 2012 wurde motiviert durch die UNIX-Konzepte der weitegehenden Isolation von sinnvoll kapselbaren Funktionalitäten („Do One Thing and Do It Well“) das Konzept der Micro-Services geprägt, vom Chefentwickler von Netflix als „Fine grained SOA“ bezeichnet. 3. Ab dem Jahr 2017 setzt sich zunehmend die Auffassung durch, dass eine extensive Zer- legung und Granularisierung von großen Softwaresystemen in kleinste „MicroServices“ ebenso vielfältige erhebliche Probleme mit sich bringt und daher Microservices eher als an der fachlichen Sicht orientierte isolierte Fach-Module gesehen werden sollten, die vor dem Hintergrund eines „Bounded Context“ eine fachlich sinnvoll geclusterte Funk- tionalität inklusive der dazu notwendigen Daten kapseln und über APIs zur Verfügung stellen. In manchen Ansätzen haben diese Microservice-Module auch eigene Oberflä- chen. In diesem Zusammenhang spricht man heute bezüglich solcher modularisierter Gesamtsys- teme auch vom „modularen Monolithen“, was aber Vision und Ziel auch nicht trifft, denn es sollen ja genau keine Monolithen mehr hergestellt werden, sondern offene ergänzbare modu- lare Web- bzw. -Cloud-Lösungen. Architekturunabhängig, aber methodisch begleitend, beeinflusste die Erstpublikation der Idee eines Domain Driven Designs (DDD) im Jahr 2004 zunehmend auch die Art und Weise der 331 Betrachtung und der Methoden, wie große Softwaresysteme entworfen und zerlegt werden sollten. Vor diesem Hintergrund ist und bleibt die Diskussion um Granularität von Software und der damit einhergehende Zuschnitt auf allgemeine systemtechnische und spezifische fachlogische 330 Siehe https://www.osgi.org/. 331 Evans, Domain-driven design – Tackling complexity in the heart of software. 2004. - 187 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Services/Module ein wichtiges informatisches Thema, das auch mit Blick auf die damit verfolg- ten fachlichen Ziele und den Projekt-/Softwarekontext gesehen werden muss. Haesen et. al.332 unterteilen bezüglich der Service-Granularität zwischen der Daten-, Geschäftsmehrwert- und Funktionsgranularität. In diesem Sinne führt eine thematische Verschneidung von DDD und Microservices zu den Kriterien maximaler Kohäsion und maximal loser Kopplung der ein- zelnen Softwarebausteine. Bei Microservices geht es nicht nur darum, große Softwaresysteme in unabhängig deploy- und betreibbare kleinere Einheiten aufzuteilen, sondern auch darum, die Entwicklung auf voneinan- der unabhängige und eigenständig arbeitende Entwicklungsteams aufzuteilen. Dies kann auch den Vorteil haben, dass diese Teams nicht einmal aus einem Unternehmen stammen müssen und daher große Systeme durch das Zusammenwirken von Softwaremodulen entstehen, die von kleinen innovativen Firmen entwickelt wurden und die Experten in einer kleinen abge- schlossenen Domäne sind. Es geht also nicht (nur) um Technik, sondern um Menschen, Orga- nisationen und offene Geschäftsmodelle für die Softwarebranche und um Innovation und Agi- lität. Und so ist in den großen Anwendungssoftware-Unternehmen nicht nur bezogen auf die Software ein „Big Ball of Mud“ entstanden, sondern oft auch hinsichtlich des Personals und dessen fachlichen Zuordnungen und Kompetenzen. Wie bereits vorangehend eingeführt, geht es um modulare Architekturen, deren Module nach dem Prinzip der funktionalen Kohäsion so klein wie möglich sein sollen und deren Zusammen- arbeit nach dem Prinzip der losen Kopplung funktioniert. „Our objective is to use asynchronous, message-driven, inter-component communication to build resilient components that are re- sponsive and elastic.”333 Für die Umsetzung und den Betrieb können sieben Prinzipien angegeben werden bzw. müssen in geeigneter Wiese implementiert werden (konsequente Nutzung von Cloud Services für die Infrastrukturbereitstellung, konsequente Microservice-Modularisierung, Containerisierung der Microservices für den Betrieb, Scheduling und Orchestrierung der Container, Clustering, Ser- vice-Mesh als Infrastrukturschicht und kontinuierliche Integration und Deployment der Micro- services)334. Dabei können bezüglich der Modularisierung sowohl fachlogische als auch allgemeine zumeist systemlogische Funktionalitäten unterschieden werden, für Letztgenannte spricht der ISO- Standard von „Multi-layer-functions“. Auch horizontale Funktionalitäten z.B. für das Berechti- gungsmanagement, die Modulkommunikation, die Administration usw. sind im Prinzip gegen- über monolithischer Legacy-Systemen nicht neu, aber dort sind diese horizontalen Funktiona- litäten zumeist mit den Fachanwendungen weitegehend „verbacken“. Viele der „Multi-layer- functions” sind heute bereits in den kommerziellen Cloud-Anwendungsplattformen enthalten, sodass für eine Implementierung nur eine Konzentration auf die fachlogischen Microservices erfolgen muss bei Berücksichtigung derer Interoperabilität mit den vorhandenen systemtech- nischen Plattformfunktionalitäten. 332 Haesen et al, On the Definition of Service Granularity and its Architectural Impact. Research Gate 2008. S. 6. 333 Gilbert, Cloud Native Development Patterns and Best Practices : Practical Architectural Patterns for Building Mod- ern, Distributed Cloud-native Systems. 2018. S. 28. 334 Schäfer, Der Weg zu einer Cloud-nativen Architektur. 2017. - 188 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme In der ISO-CCRA werden drei Hauptklassen von Funktionalitäten („cloud capability types“) un- terschieden: “Cloud capabilities type: Classification of the functionality provided by a cloud service (3.2.8) to the cloud service customer (3.2.11), based on resources used. NOTE – The cloud capabilities types are application capabilities type (3.2.1), infrastructure capabilities type (3.2.25) and platform capabilities type (3.2.31).“         335 Im ISO-Standard wird die Grundidee der allgemeinen Architektur (Cloud Computing Reference Architecture CCRA)336 entlang der Betrachtung von betrieblichen Rollen, ihren Aufgaben und den damit verbundenen unterstützenden Anwendungssystemfunktionen hergeleitet. Konse- quenterweise werden vier „viewpoints“ angegeben: User view, Functional view, Implementation view und Deployment view, wobei implementierungstechnische Aspekte sukzessive in der an- gegebenen Reihenfolge abgeleitet werden. Der Standard selbst behandelt aber nur die zwei erstgenannten Viewpoints, macht also keine Vorgaben oder Annahmen zu Implementierungen und Deployment. Es handelt sich also um eine logische Architektur. Dabei werden in der ISO-CCRA – aber auch in anderen Architekturen – als kleinste Einheit An- wendungsfunktionen angegeben (functional components337), die in ihrer Gesamtsumme den Leistungsumfang einer Cloud-Anwendung ausmachen. Diese werden verschiedenen Schichten (Layer) zugeordnet. Layer klassifizieren die Funktionalitäten und es werden einerseits Layer un- terschieden, deren Funktionen spezialisierter vertikale Art sind (graphisch sind die Layer aber horizontal dargestellt) und Layer, deren Funktionen systemweit verfügbar sind und von vielen anderen Funktionen konsumiert werden oder für die Gesamtkoordination und das Funktionie- ren des Cloud-Systems evident sind (graphisch sind die Layer aber vertikal dargestellt). Die Benutzerschicht („User Layer“) umfasst die zur Unterstützung der betrieblichen Aktivitä- ten notwendigen Funktionalitäten und wird weiter unterteilt in Funktionen für die Benutzer, die Administratoren der Anwendung und generelle Geschäftsfunktionen. Die Zugriffsschicht („Access Layer“) enthält Komponenten für die Kooperation und Zugriffs- kontrolle von Komponenten untereinander bzw. der verschiedenen Schichten. Die Funktionen der Service Schicht („Service Layer“) dienen der Verwaltung und Orchestrie- rung der Cloud-Services selbst. In der Ressourcen-Schicht („Resource Layer“) sind dann Funktionen für die Abbildung der physischen Umgebung bzw. der Nutzung physischer Ressourcen enthalten. Bezogen auf einen stationären Versorgungsprozess stellt sich die Grundidee vereinfacht wie folgt gezeigt dar. 335 International Standards Organisation, ISO/IEC 17788 Information technology - Cloud Computing - Overview and vocabulary. 2014. S. 2. 336 International Standards Organisation, ISO/IEC 17789 Information technology -Cloud computing - Reference ar- chitecture. S. 5. 337 „A functional component is a functional building block needed to engage in an activity, backed by an implemen- tation. The capabilities of a cloud computing system are fully defined by the set of implemented functional compo- nents.“ Fn 20 , S. 7. - 189 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme …..                     …..                        ….. Multi Layer Functions Oprational Support User Layer Business Support Integration                                                                 Development Access Layer Security Service Layer Resource Layer Abbildung 4-1: Behandlungsprozess, Userfunktionen und ISO-CCRA Während viele der allgemein notwendigen Funktionalitäten in kommerziellen Frameworks und Plattformen schon vorhanden sind, bleibt es für jede spezielle branchenspezifische Cloud-An- wendungssoftware spezifische Aufgabe, die Benutzerfunktionalitäten also die Funktionen im User-Layer festzulegen und die Microservices dazu sinnvoll zu schneiden, zu kapseln und zu realisieren. Bei bestimmten betrieblichen Aufgaben kann es auch vorkommen, dass Benutzer direkt Funktionalitäten z.B. aus den Multi-Layer Funktionen benutzen, so wird z.B. ein Anwen- dungsadministrator Produktkataloge und Semantikeinträge oder Berechtigungen mit Funktio- nen mit Funktionen in den entsprechenden Schichten pflegen. Ein Framework für die die Architekturentwicklung und Implementierung von Gesundheitsinfor- mationssystemen wie z.B. KIS hat 2019 in einer ersten Version HL7 International vorgelegt, das im Kern auf die fachlogische Architektur und Interoperabilität der in vorangehender Abbildung gezeigten Module im User-Layer abzielt, aber nicht nur darauf limitiert ist. „The Service-Aware Interoperability Framework (SAIF) provides consistency between all artifacts, enables a stand- ardized approach to Enterprise Architecture development and implementation, and a way to measure the consistency. SAIF is the framework that is required to rationalize interoperability of standards. SAIF is an architecture for achieving interoperability, but it is not a whole-solution design for Enterprise architecture management. This document describes a canonical form of Service-Aware Interoperability Framework (SAIF) which can be adapted to an organization's implementation requirements through the production of a SAIF implementation Guide.“338 Die Grundidee: Mit einer Services-Aware Interoperability Framework Canonical Definition (SAIF- CD) können sogenannte Interoperabilitätsspezifiaktions-Matrizen (ISM) definiert werden, die als Grundlage für Compliance-Kriterien für spezielle Profile, die „Interoperability Specification 338HL7 International, Enterprise Consistency and Conformity Framework (ECCF). 2019. Siehe http://www.hl7.org/im- plement/standards/product_brief.cfm?product_id=3. - 190 -