Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Normative Ansatzpunkte zur Vorgabe dieser Standards finden sich für Leistungserbringer in der GKV und damit auch alle Krankenhäuser außer reine Privatkliniken bereits im SGB V, so z.B. zum bundeseinheitlichen elektronischen Medikationsplan nach § 31a, § 334 Abs. 1 Nr. 4, § 355 Abs. 3, § 358 SGB V. Dieser Ansatz könnte über die Bundeskompetenz für die Sozialversiche- rung weiter ausgebaut werden. Neben solchen zwingenden Regularien ist auch an eine an In- teroperabilitätskriterien geknüpfte Förderung wie nach dem KHZG zu denken, die mit der Zeit auch in eine entsprechende Forderung übergeht, die erfüllt werden muss, wenn Vergütungs- abschläge vermieden werden sollen. 6.1.5 Stimulierung der Cloudifizierung von KIS Als “Cloudifizierung” wird hier die Migration oder schrittweise Umstellung bestehender Le- gacy-Systeme auf Cloud Native Anwendungen verstanden. Wie in Kapitel 4.4.3 dargestellt, han- delt es sich bei feingranularen mCloud-KIS um die Summe aller cloudbasierten MicroService- Module, die für den operativen Betrieb und die Steuerung sowie für das taktische und strate- gische Krankenhausmanagement notwendig sind. Aufgrund des modularen Charakters können diese Module auch von verschiedenen Herstellern stammen, sodass auch von einem modula- ren multivendorfähigem Cloud-KIS gesprochen werden kann. Trotzdem benötigt ein solcher Lösungsansatz wie in Abbildung 4-4 gezeigt ein gewisses minimales Kernsystem, in das dann Zusatzmodule in Form von "KIS-PlugIns" einbezogen/eingeklinkt werden können. Und eben für dieses “Einklinken” sind verbindliche standardisierte offengelegte Service- und Aufruf- schnittstellen zur Einbindung an der Benutzeroberfläche notwendig. Der Einsatz von Cloud-KIS hat für Krankenhäuser eine Reihe von Vorteilen, die allgemein für Cloud-Einsatz angegeben werden. Hierzu zählen u.a. die Hochverfügbarkeit, das hohe Sicher- heitsniveau, die passgenau Orchestrierung der Anwendungsumgebung, ressourcennutzungs- oder wertschöpfungsorientierte Kostenmodelle, die sukzessive Hinzunahme von Funktionali- täten, die Möglichkeit aus verschiedenen alternativen Modulen zu wählen, die Schaffung von Freiräumen für das Vor-Ort-IT-Personal für die Konzentration auf fachliche und strategische Belange der IT im Krankenhaus, Abbau von Herstellerabhängigkeit, keine Notwendigkeit mehr von Client-Installationen und Client-Management, Integration von "Fremdsoftware" und Ei- genentwicklungen. Die Verfügbarkeit von mCLoud-KIS muss daher auch ein großes Anliegen der Krankenhäuser sein. Selbst der Betrieb entsprechender Lösungen On-Premises hat viele Vorteile. Legacy-Hersteller haben stabile langjährig entwickelte Software und in der Regel wenig Moti- vation, ökonomischen Erfolg durch Neuentwicklungen zu reduzieren, denn: Je länger die Be- triebslaufzeit, desto größer der unternehmerische Wertebeitrag. Auch wenn technologische Modernität, Flexibilität und Plug-In-Fähigkeit eines KIS Wettbewerbsfaktoren sind, schlägt sich dies im Wettbewerb nur nieder, wenn in einer Branche auch eine Nachfrage nach solchen in- novativen Lösungen besteht. Wenn Anbieter und Kunden gemeinsam in der Nische der tech- nologischen Vergangenheit verharren, entstehen auch keine innovativen neuen Lösungen. Es sind daher nationale Strategien und Anstrengungen zu entwickeln, die die Weiterentwick- lung für den Krankenhausbereich in Richtung Cloud Native Anwendungen stimulieren. Erster Anreiz und Stimulierung könnte hier der §19 Abs 1 Nr 7 des KHZG sein, in dem explizit Cloud- Computing als förderfähige Vorhaben für die Abstimmung des Leistungsangebotes mehrerer - 285 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Krankenhäuser oder die Bereitstellung sicherer Systeme ohne lokale Server benennt. Auch heißt es in den Richtlinien unter Zielsetzung dazu: "Eine einrichtungsübergreifende Koopera- tion zur Abstimmung des Leistungsangebots ist insbesondere bei Digitalisierungsvorhaben der Fördertatbestände 2-6 sowie 8-10 möglich". Krankenhäuser sollten also bei Beantragungen prüfen, ob sie mit ihren Partnern und ggf. auch im Verbund mit anderen Krankenhäusern Lö- sungserweiterungen als Cloud-Lösungen umsetzen lassen. Daneben können auch die Krankenhäuser die Entwicklung stimulieren, indem sie bei anderen Ausschreibungen und Neubeschaffungen neben der Offenheit auf Basis von HL7-Nachrichten wie das heute üblich ist auch eine Offenheit in Bezug auf servicebasierte Interoperabilität - wo möglich auf Basis von FHIR – und Cloud-Perspektiven einfordern. Ebenso sollten Aufrufpunkte im Legacy-System – ggf. parametrierbar durch das Krankenhaus – zum Aufruf von Cloud-Mo- dulen eingefordert werden; auch von Drittanbietern. Dies würde zunehmend eine Vielfalt von "KIS-Plugins" ermöglichen und Spezialfunktionalitäten, die so von den Legacy-Herstellern nicht geliefert oder nicht wirtschaftlich akzeptabel geliefert werden können, verfügbar machen. 6.2 Vorschläge zur Ausrichtung der technischen KIS-Architekturen auf die Cloud Viele der heute kommerziell verfügbaren KIS-Lösungen bzw. der Subsysteme sind noch keine Cloud-Lösungen. Zumeist handelt es sich bei Legacy-KIS um klassische Client-Server-Anwen- dungen. Bei RZ-Betrieb erfolgt die Verarbeitung der „fetten Clients“ auch im Rechenzentrum und die Benutzung wird mittels Terminalserver bzw. virtualisiertem Desktop auf die Arbeits- rechner gebracht. Im weitesten Sinne ist der Betrieb von Legacy-KIS des alten Stils auf skalier- baren Infrastrukturen oder Plattformen auch schon Cloud-Computing, aber diese Systeme kön- nen die skalierenden Infrastruktur- und Plattform-Potenziale des Cloud-Computing nur in ge- wissem Maße ausschöpfen. Angebote in Form von Software-as-a-Service sind ebenfalls damit nicht am Markt platzierbar. Aber auch softwaretechnisch wird es immer schwieriger, diese zum Teil vor 25 Jahren entstandenen Software-Systeme an neue Anforderungen und Herausforde- rungen anzupassen. Aufgrund des technologischen Wandels und der Nichtmehrverfügbarkeit alter zugrunde liegender Basis-Technologien sind Legacy-KIS dabei, zunehmend zu verrotten. In vielen anderen Branchen haben bereits vor Jahren Hersteller damit begonnen, ihre Legacy- Systeme auf Cloud-fähig umzustellen bzw. neu zu entwickeln. Eine reine Code-Migration scheint wenig praktikabel und sinnvoll, da heutige Tools und Technologien sowie der für Cloud Native Anwendungen notwendige Architekturzuschnitt anderen Paradigma gehorchen als vor 20-30 Jahren. Auch lassen die heutigen Technologien und Werkzeuge eine weitaus effektivere Softwareentwicklung zu, sodass eine Code-Migration aufwändiger ist, als ein Neudesign und eine Re-Implementierung. Ebenso können viele generelle Funktionalitäten die in den Altsyste- men aufwändig individuell implementiert wurden, heute von den fachlichen Microservcie-Mo- dulen als Services der Plattform konsumiert werden, so z.B. Services für das Caching , Workflow Engines, Berechtigungsmanagement-Services, Archivierungs- und Speicherservices, Identifika- tions- und Authentifikationsservices, Integrationskonnektoren, API-Repository- und Manage- mentfunktionen, Datenvirtualisierungs-Services, Messaging Broker oder serverlose Frame- works oder Event-Bus, sodass Plattformen heute auch als Entwicklungsumgebungen angese- - 286 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme hen werden können. Neuentwicklungen können sich so vollständig auf die fachlogischen Prob- lemstellungen konzentrieren – und das vor dem Hintergrund der inzwischen verfügbaren Struktur- und Inhaltsstandards wie z.B. FHIR in Verbindung mit SNOMED. Die Evolution hin zu Cloud Native Anwendungen muss als multidimensionaler Ansatz gesehen werden, der nicht nur die technischen Aspekte betrifft, sondern auch Kultur, Organisation und Denken in den Entwicklungsabteilungen der Softwareindustrie. "This cloud-native thing is NOT a big-bang approach and doing so will backfire incredibly hard. ... Cloud native is an adjective that describes the applications, architectures, platforms/infrastructure, and processes, that to- gether make it *economical* to work in a way that allows us to improve our ability to quickly respond to change and reduce unpredictability. This includes things like services architectures, self-service infrastructure, automation, continuous integration/delivery pipelines, observability tools, freedom/responsibility to experiment, teams held to outcomes not output, etc.“442 Mit Blick auf die gute Differenziertheit und Modularisierung des medizinischen Vorgehens sind viele korrespondierende IT-Funktionalitäten ebenso gut abgrenzbar und damit modular reali- sierbar. Eine Wunddokumentation muss nicht mit dem Rest der KIS-Welt eng verbacken sein und ist selbst sogar noch weiter zerlegbar, eine Diagnosedokumentation im Grunde bestehend aus einer Diagnoseliste und einer Diagnoseerfassung ist ebenfalls gut isolierbar und so lassen sich viele weitere Beispiel anbringen. Was für den klinischen Teil des KIS gilt, gilt auch in vielen Teilen für den administrativen Teil. Dort haben bereits große Hersteller begonnen, Cloud-Pro- dukte auszurollen. Im Klinischen Teil ist es evident, im Zentrum ein interoperables offenes Pa- tientenakten-Dossier zu konzipieren, das ebenfalls als Microservice dann mit den vielen not- wendigen Plug-Ins interagieren bzw. diese aufrufen kann. Dabei kann als Alternative zu einer völligen Neuentwicklung ("Big Bang"), die ein Legacy-Her- steller in der Regel organisatorisch und finanziell überfordert, auch ein schrittweises migratives Vorgehen angegeben werden, bei dem unter Aspekten des Domain-Driven Design Fachfunk- tionalitäten isoliert und als Microservice-Module neu entwickelt und kontextuell in das Altsys- tem integriert werden. Eine Liste möglicher Kandidaten findet sich in Kapitel 4.4.5. Dabei kann eine kontextsensitive Aufrufintegration von Microservices aus dem Legacy-System heraus ebenfalls gut realisiert werden, sodass für einen Übergangszeitraum die Koexistenz beider An- sätze möglich ist. Ergänzend muss ggf. ein Zugriff auf die gekapselten Daten des CMSM aus Funktionalitäten des Legacy-Systems heraus zusätzlich implementiert werden, umgekehrt kann es auch hilfreich sein, stufenweise Zugriffs-Services von CMSM auf Legacy-Daten für wichtige Shared Context zu implementieren. Zukünftige Architekturen für eine vollumfängliche Cloud-Fähigkeit sind Cloud Native KIS, die auf Basis von erprobten Cloud-Plattformen und Nutzung der vorhandenen standardisierten Dienste verschiedener Schichten dieser auf der Ebene des User Layers aus fachlogischen Micro- service-Modulen bestehen, die nach dem Prinzip maximale Kohäsion und lose Kopplung im- plementiert sind (siehe Beispiel Abb. 4-9). Dabei bieten die vielfältigen und differenzierten Standards der Health IT - so vor allem FHIR von HL7, IHE IT-Infrastructure und Profile, DICOM und die vielfältigen Semantikkataloge von ICD, ICPM über LOINC bis SNOMED, aber auch de- finierte medizinische Stadien und Einteilungen, eine sehr gute Basis für das Design und die 442 Quelle: https://www.infoq.com/articles/cloud-native-panel/. - 287 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme interoperable standardkonforme Implementierung von medizinischen, aber auch administrati- ven Microservices. Zusammenfassend ergeben sich folgende Lösungsvorschläge für die Legacy-Systeme/Her- steller: •    Öffnung der Systeme durch Ergänzung um FHIR-Services zum Abruf und ggf. der Rück- übergabe wesentlicher (Kontext)Daten an/von Cloud-Subsysteme und -Anwendungs- module, damit Ermöglichung der Integration innovativer Funktionsmodule von Drittan- bietern. •    Implementierung von GUI-Elementen zum Aufruf von Cloud-Anwendungsmodulen an geeigneten Stellen bzw. eine generische parametrierbare Aufruf-Bildschirmseite/ Me- nüleiste •    Zurverfügungstellung oder Ankopplung eines (Clinical) Contextmanagers und eines Event-Bus für System-Offenheit und moderne Interoperabilität •    Konkrete Kontextlieferungen bzw. FHIR-Services für von vielen Cloud-Modulen benö- tigten Kontextdaten wie Patient, Fall, Auftrag, Diagnosen usw. •    Öffnung und Interoperabilität in dem Sinne, dass Repository-Inhalte und Semantik auch aus DaaS-Instanzen bezogen/genutzt werden können. •    Anbindung von in der Cloud verfügbaren Basisdiensten wie z.B. Single Sign On, Policy- und Rechtemanagement, Kryptographiedienste, Pseudonymisierungsdienste, Zeitsyn- chronisationsdienste •    Sukzessive Umstellung von Anwendungsfunktionalitäten auf CMSM Anforderungen an die CMSM und CMSM-Hersteller: •    Berücksichtigung der internationalen Standards für Domänenmodell, Semantik und Interoperabilitäts-API, vor allem von HL7, IHE und SNOMED, aber auch andere Se- mantikstandards •    Offengelegtes Interoperabilitäts-API •    Hohe Aufgabenangemessenheit der GUI •    Durchgehend Web-basiert und Web-nutzbar •    Responsives Verhalten •    Bezug von standardisierter Semantik und Bezugsobjekten wo möglich aus verfügba- ren Cloud-Repositories (DaaS-Instanzen) •    Nutzung von Open Source Werkzeugen, Bibliotheken und Komponenten für die Im- plementierung Abschließend sei hinsichtlich der Migration auf einen praxisorientierten 8-Schritte Vorschlag verwiesen :  443 •    Entwicklung einer DevOps-Kultur nebst Praktiken •    Beschleunigung bestehender Anwendungen mithilfe “schneller Monolithen”, d.h. Mig- ration der aktuellen monolithischen Architektur zu einer modulareren, service-basier- ten Architektur mit API-basierten Kommunikation wo möglich 443 Quelle: https://www.redhat.com/cms/managed-files/mi-path-to-cloud-native-apps-ebook-f12255cs-201805- a4-de.pdf. - 288 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme •     Nutzung von Anwendungs-Services für eine schnellere Entwicklung •     Auswahl der richtigen Tools für die richtigen Aufgaben •     Bereitstellung einer bedarfsabhängigen Self-Service-Infrastruktur •     IT-Automatisierung zwecks Beschleunigung der Anwendungsbereitstellung •     Nutzung von CD (Continuous Delivery)-Prozessen und fortschrittlichen Bereitstel- lungstechniken •     Entwicklung einer modulareren Architektur 6.3 Vorschläge für mehr Cloud-Souveränität in Deutschland und Europa Aus Sicht des europäischen Datenschutzes und der deutschen Schweigepflicht samt Beschlag- nahmeschutz ist es problematisch, dass die wohl leistungsstärksten Cloud-Angebote derzeit von US-Unternehmen ausgehen. Dieser Herausforderung kann man insbesondere mit den bei- den im Folgenden beschriebenen Maßnahmen begegnen. 6.3.1 Entwicklung und Stärkung originär europäischer Cloud-Angebote Im Sinne des europäischen Technologie- und Wirtschaftsstandortes könnte staatlicherseits die Entwicklung originär europäischer Cloud-Technologien und deren Vermarktung gefördert wer- den. Dies muss nicht zwingend durch direkte Subventionierung bzw. Anschubfinanzierung ge- schehen, sondern kann auch durch eine Koordination im europäischen Staatenverbund wie bei GAIA-X geschehen. Hierdurch wurde letztlich eine private Kooperation von Unternehmen an- gestoßen, die auch US-Anbieter nicht ausschließt,444 aber vor allem auch der Entwicklung sowie in Zukunft dem strukturierten, transparenten und vertrauenswürdigen Angebot von Cloud- Leistungen in Europa dienen soll. Dies ist aus Sicht der Verfasser dieses Gutachtens ein Schritt in die richtige Richtung, auch wenn es zweifelsohne eine große Herausforderung sein wird, in Europa technologisch wirklich Anschluss zu finden. 6.3.2 Cloud nach dem Treuhandmodell Eine mögliche Lösung, durch welche die technischen Vorteile der Cloud-Angebote von US- Konzernen mit den strengen europäischen Datenschutz-Anforderungen445 vereinbart werden können, stellt das sogenannte Treuhandmodell dar. Dieses soll im Folgenden anhand eines Beispiels erläutert werden, das tatsächlich praktiziert wird und möglicherweise ausgebaut wer- den kann, ohne dass damit eine Einschränkung des Modells auf die hier genannten Unterneh- men verbunden wäre: Um hohen (datenschutz-)rechtlichen Anforderungen Rechnung zu tragen, ohne dass Kunden dabei auf die Angebote großer US-amerikanischer Anbieter verzichten müssen, betreibt Micro- soft in Kooperation mit der Deutschen Telekom (bzw. T-Systems) seit 2015 die sogenannte Microsoft Cloud Deutschland nach dem Treuhandmodell. Dabei handelt es sich um eine iso- lierte, aus zwei deutschen Rechenzentren betriebene Instanz der Microsoft Azure Cloud, deren physischen und logischen Zugriff die Deutsche Telekom als Treuhänder verwaltet, steuert, 444 Letztlich sollen über GAIA-X die Lokalisierung von Daten und die Zugriffe auf diese für den Cloud-Nutzer vorab und laufend transparent gemacht werden, so dass dieser entscheiden kann, welche Cloud-Angebote er für welche Daten nutzen möchte. Die Angebote von US-Anbietern, auch wenn sie auf US-Server zurückgreifen, sind damit nicht ausgeschlossen, der Umfang ihrer Nutzung ist durch die datenschutzrechtliche Lage jedoch eingeschränkt. 445 Siehe dazu oben Kapitel 3, S. 49 ff., sowie zusammenfassend auch Kapitel 5.2, S. 267 ff. - 289 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme überwacht und protokolliert. Ein Transfer zu Microsoft in die USA als unsicheren Drittstaat ist somit für die eigentlichen Geschäftszwecke nicht notwendig, was aber grundsätzlich auch bei jeder anderen, von Microsoft selbst in der EU gehosteten Cloud der Fall wäre. Den Unterschied macht hier der Einsatz der Deutschen Telekom als Datentreuhänder. Durch diesen Schritt wird der physische und logische Zugriff auf in der Cloud gespeicherte Daten für Microsoft ohne die Zustimmung der Deutschen Telekom praktisch nicht möglich. In der Folge kann auch kein Durchgriff auf diese Daten durch US-Behörden nach dem U.S. CLOUD Act unter Rückgriff auf Microsoft erfolgen. Ein direkter Anspruch von US-Behörden gegenüber der Deutschen Telekom scheidet zwar auf Grundlage der einschlägigen US-amerikanischen Rechtsvorschriften nicht generell aus, da die Deutsche Telekom mit der T-Mobile US, Inc. zumindest auch über eine Tochtergesellschaft mit nicht unerheblichem Geschäft in den USA verfügt. Dies ändert jedoch nichts daran, dass die deutsche Muttergesellschaft und ihre deutschen Töchter nach deutschem Recht ausschließlich deutschem und europäischem öffentlichen Recht unterliegen.446 Und aufgrund des Umstandes, dass Hauptgeschäft und Konzernzentrale der Deutschen Telekom nach wie vor in Deutschland liegen, besteht hier die begründete Erwartung, dass sich die Muttergesellschaft und die deut- schen Töchterunternehmen vorrangig an deutsches Recht halten werden.447 Während ein solches Treuhandmodell also aus rechtlicher Sicht einen datenschutzkonformen Cloud-Betrieb ermöglichen kann, stehen ihm auf der anderen Seite wirtschaftliche und techni- sche Herausforderungen entgegen. So erhöht das Telekom-Treuhandmodell z. B. im Fall der SAP-Cloud-Services, also des Betriebs eines SAP ERP-Systems in der von der Telekom admi- nistrierten Microsoft Cloud Deutschland, die Kosten gegenüber dem Betrieb in einer Cloud ohne Treuhandmodell um ca. 10-20%. Neben diesem wirtschaftlichen Nachteil machen aus technischer Sicht höhere Latenzen (Zeitverzögerungen) bei weltweiter Nutzung das Treuhand- Angebot weniger attraktiv. Diese Latenzen entstehen dadurch, dass Rechenzentren in Deutsch- land die weltweiten Standorte der nutzenden Großunternehmen bedienen müssen und Re- chenzentren mit gespiegelten Datenbeständen in unsicheren Drittstaaten im Treuhandmodell nicht möglich sind. Für Krankenhäuser innerhalb von Deutschland dürften jedoch keine nennenswerten Latenzen auftreten. Auch ist die hohe Skalierbarkeit einer weltweiten Cloud für Krankenhäuser mit ihren eher deterministischen Lasten nicht unbedingt erforderlich. 446 Eine extraterritoriale Geltung ausländischen öffentlichen Rechts, einschließlich des Strafverfahrensrechts, wird insoweit nicht anerkannt, wenn dies auch eine Kooperation und mittelbare Wirkung im Rahmen von Rechtshilfeer- suchen nicht ausschließt. Im Gegensatz zum Zivilrecht ist hier auch keine Rechtswahl per Vertrag zulässig. 447 Der französische Conseil d’État hat im einstweiligen Rechtsschutz selbst zu Microsoft Ireland ausgeführt, dass kein Anlass bestehe, bloße Vermutungen im Hinblick auf einen Zugriff aus unsicheren Drittstaaten als Anlass für eine Untersagung der Datenverarbeitung heranzuziehen; s.o. S. 61 f. Ob man im Hinblick auf US-Konzerne wie Microsoft hier generell von bloßen Vermutungen sprechen muss, kann man anzweifeln; vgl. den öffentlich gewor- denen Fall einer Herausgabeanordnung des U.S. Departments of Justice gegenüber Microsoft im Hinblick auf in Irland belegene Daten, der bis vor den obersten Gerichtshof der USA gelangte: 584 U.S. ___, 138 S. Ct. 1186 (2018). Im Fall eines Unternehmens mit Konzernzentrale und Tätigkeitsschwerpunkt in Deutschland besteht aber grund- sätzlich ein berechtigtes Vertrauen dahingehend, dass deutsches und europäischen Recht eingehalten wird, s. oben S. 62, Fn. 109. - 290 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme Im Fall der Microsoft Cloud Deutschland haben sich die genannten Nachteile in der Vergan- genheit zwar in mangelndem Interesse der Kunden niedergeschlagen, weshalb Microsoft das Angebot für Neukunden nicht mehr anbietet. Es könnte allerdings sein, dass solche Treuhand- modelle nach der Schrems II-Entscheidung des EuGH wieder mehr in den Fokus sowohl poten- zieller Anbieter als auch Nutzer gelangen, was grundsätzlich auch für Krankenhäuser zu befür- worten wäre.448 448 Skeptisch mit Blick auf die Kosten einer Treuhandlösung für Microsoft 365 an Schulen (Stand: 18.09.2020): https://datenschutz-schule.info/2020/09/18/microsoft-365-zukunft-fuer-schulen-ungewiss/. Je mehr Kunden eine solche Treuhandlösung im Sinne einer Community-Cloud für Anwender mit höherem Schutzbedarf hätte, desto geringer dürften allerdings die Kosten für den einzelnen Kunden ausfallen. - 291 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme 7 Abkürzungsverzeichnis Abkürzung            Langtext ABAC                 Attribute Based Access Control Abs.                 Absatz AEUV                 Vertrag über die Arbeitsweise der Europäischen Union AfG                  Ausschuss für Gesundheit AHA                  American Hospital Association AISEC                Fraunhofer-Institut für Angewandte und Integrierte Sicherheit AMC                  Advanced Medical Communication Holding GmbH AMTS                 Arzneimitteltherapiesicherheit API                  Application Programming Interface (Anwendungsprogrammierschnittstelle) APIS                 Arztpraxisinformationssystem BAS                  Bundesamt für soziale Sicherung BB                   Brandenburg (ISO 3166) BCM                  Business Continuity Management BDSG                 Bundesdatenschutzgesetz BE                   Berlin (ISO 3166) BeckOK               Beck’scher Online-Kommentar BGB                  Bürgerliches Gesetzbuch BGH                  Bundesgerichtshof BITKOM               Bundesverband Informationswirtschaft, Telekommunikation und Neue Medien BMG                  Bundesgesundheitsministerium BMP                  bundeseinheitlicher Medikationsplan BMWi                 Bundesministerium für Wirtschaft und Energie BRAO                 Bundesrechtsanwaltsordnung - 292 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme BSI                  Bundesamt für die Sicherheit in der Informationstechnik BW                   Baden-Württemberg (ISO 3166) BY                   Bayern (ISO 3166) BYOD                 Bring Your Own Device CCOW                 Clinical Context Object Workgroup CCRA                 Cloud Computing Reference Architecture CDA                  Clinical Document Architecture CEN                  Comité Européen de Normalisation CHIME                College of Healthcare Information Management Executives cloudKIS             Cloud-basiertes Krankenhausinformationssystem CMSM                 Cloud MicroService Modul CMSMS                Content-Management-System Made Simple COPS                 Common Open Policy Service CSV                  Comma-separated values DaaS                 Data as a Service DAC                  Discrenary Access Control D-A-CH               Deutschland Österreich Schweiz DDD                  Domain Driven Design DICOM                Digital Imaging and Communication in Medicine DIGA                 Digitale Gesundheitsanwendung DKBFVO               Datenschutzkirchenbezirksfestlegungsverordnung DKG                  Deutsche Krankenhausgesellschaft DRG                  Diagnosis Related Group DSDEVO               Datenschutzdurchführungs- und -ergänzungsverordnung DSG-EKD              Datenschutzgesetz der evangelischen Kirche in Deutschland DSGVO                Datenschutzgrundverordnung DuD                  Datenschutz und Datensicherheit (Zeitschrift) - 293 -

Rahmenbedingungen Cloud-basierter Krankenhausinformationssysteme EAV                  Entity Attribute Value ECCF                 Enterprise Consistency and Conformity Framework EDSA                 Europäischer Datenschutzausschuss EEG                  Elektroencephalogramm EGMR                 Europäischen Gerichtshofes für Menschenrechte EHR                  Electronic Health Record EIS                  Enterprise Information System EKG                  Elektrokardiogramm EMR                  Electronic Medical Record EMRAM                Electronic Medical Records Adoption Model ENV                  Europäischer Normvorschlag EPA                  Elektronische Patientenakte ERP                  Enterprise-Resource-Planning EU                   Europäische Union EuGH                 Europäischer Gerichtshof EUV                  Vertrag über die Europäische Union EWR                  Europäischer Wirtschaftsraum FaaS                 Function as a Service FHIR                 Fast Healthcare Interoperability Resources FINK                 Finanzbuchhaltung im Krankenhaus GDSG                 Gesundheitsdatenschutzgesetz gem.                 gemäß GG                   Grundgesetz ggf.                 gegebenenfalls GKV                  Gesetzliche Krankenversicherung GKV                  Gesetzliche Krankenversicherung GMDS                 Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie - 294 -