IT-Architektur eines Boundaryless Hospital

IT-Architektur eines Boundaryless Hospital: Herausforderungen und Lösungsansätze

Dr. Jörg Caumanns, Christian Giertz, Anne Grohnert, Ben Kraufmann
Prof. Dr. Dr. Kurt J.G. Schmailzl, Franziska Thomas

Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS
ccc. Center for Connected Health Care UG

Das „Boundaryless Hospital“ ist die Chiffre für eine patienten- statt hospitalzentrierte Versorgungssicherung, umgesetzt durch „digitale“ und „analoge Begleiter“ für eine alternde Bevölkerung. Während die Steuerung der Versorgung nach wie vor top-down aus dem Krankenhaus über angebundene regionale Versorgungsstrukturen zum Patienten hin organisiert ist, werden die medizinischen Prozesse der Versorgung bottom-up neu organisiert; weite Teile von Diagnostik und Therapie finden in der unmittelbaren Umgebung des Patienten statt. Über eine Monitoringstruktur fließen Informationen zum aktuellen Zustand des Patienten über die regionale Versorgungsebene zurück zum Krankenhaus, das entsprechend des Bildes eines Regelkreises anhand dieser Informationen die Verfahren und Ziele der Versorgung kontinuierlich justieren kann.
Das Rückgrat des „Boundaryless Hospital“ ist damit keine konventionelle Architektur aus Beton, Stahl und Glas mehr, sondern eine IT-Architektur, die verschiedenste Kommunikations- und Datenflüsse bidirektional entlang einer Hierarchie von dezentralisierten Versorgungsstufen abbildet. Gegenüber etablierten Ansätzen für regionale Versorgungsnetze [1], stellen sich bei der Umsetzung eines „Boundaryless Hospital“ zusätzliche Herausforderungen, die vorrangig aus der Anforderung einer nahtlosen Verzahnung von digitalen und analogen Prozessen entstehen.

Gerätelogistik

Kernelemente des digilog-Konzepts sind die Nutzung von Medizinprodukten und MedTech-devices im häuslichen Umfeld sowie der Einsatz miniaturisierter, patientennaher Sensorik, um Risikopatienten zu schützen, aber auch um präventive Maßnahmen effektiver zu gestalten. Der Einsatz dieser Geräte erfolgt dabei immer zweckgerichtet, d. h. Grundlage ist eine Leistungsanforderung für eine Langzeitbeobachtung oder eine Diagnostik. Aus dieser Anforderung heraus werden im die Versorgung steuernden eHealth-Center die zu erfassenden Patientendaten definiert und die hierzu für den Patienten geeigneten Geräte festgelegt. Diese werden anschließend über den Hausarzt oder entsprechend geschultes Pflegepersonal (z. B. agneszwei-Gemeindeschwester) im häuslichen Umfeld des Patienten zum Einsatz gebracht. Die über die Geräte erhobenen Daten fließen über eine IT-Infrastruktur an den betreuenden Arzt und das eHealth-Center zurück.
Das skizzierte Zusammenspiel von Leistungsanforderung, erforderlichen Monitoringdaten und eingesetzten Geräten wird in digilog über ein semantisches Netz abgebildet (siehe Abbildung). Dieses Netz bildet sowohl die Grundlage des Gerätemanagements (welcher Patient hat zur Erfassung welcher Daten welches Gerät bekommen) als auch der Berechtigungssteuerung (welche Daten werden über welche Geräte zu welchem Zweck erhoben). Aus dem semantischen Netz werden bereits bei der Geräteausgabe alle erforderlichen Einwilligungsformulare auf den Patienten, die Leistungsanforderung und die konkret erfassten Daten personalisiert. Dadurch, dass das ausgegebene Gerät immer im Bezug zu einer konkreten Leistungsanforderung steht, kann technisch abgesichert werden, dass nur die Daten gespeichert und verarbeitet werden, die für den konkreten Versorgungskontext erforderlich sind. Hierdurch wird die Zweckbindung des Datenschutzes unmittelbar mit der medizinischen Erforderlichkeit verknüpft [2].
Die Verknüpfung von Patienten und ausgegebenen Geräten wird über den Patientenindex der digilog-Plattform verwaltet. Unter Nutzung des IHE PIX-Profils [3] wird dieses in einer Weise realisiert, dass die Gerätenummern der ausgegebenen Geräte von allen angebundenen Systemen als pseudonyme Patienten-IDs nutzbar sind. Hierdurch ist es nur berechtigten Ärzten möglich, die zu einem Patienten erfassten – und unter den jeweiligen Gerätenummern gespeicherten – Daten zusammenzuführen.

Gerätelogistik

Gerätelogistik

Das digilog-Modell geht weit über das „klassische“ Monitoring von Patienten über tragbare Medizingeräte hinaus und beinhaltet auch Verfahren der Diagnostik und Therapie, die im unmittelbaren Umfeld des Patienten ausgeführt werden. Beispiele sind die mobile Labordiagnostik oder der Einsatz tragbarer radiologischer Geräte. Zusätzlich können auch Daten aus typischen Lifestyle-Geräten wie z. B. SmartWatches erfasst und zur Validierung bzw. teilweise sogar Ergänzung medizinischer Daten genutzt werden.
Um dieser Heterogenität von datenerfassenden Endpunkten gerecht zu werden, setzt digilog auf einer ebenso heterogenen, verteilten Architektur von Datenspeichern auf:

  • Einstellen und Abrufen von Daten über die im IHE Profil Cross-Enterprise Document Sharing (XDS) definierten Transaktionen [3]: Die Speicherung der Daten erfolgt in Form von Dokumenten über eine IHE XDS Plattform;
  • Einstellen und Abrufen von Daten als HL7 FHIR Observation Ressourcen [4]: Über einen IoT-Hub und standardisierte REST-Schnittstellen können granulare Daten (z. B. einzelne Messwerte) in einen FHIR-Store geschrieben werden;
  • Anbinden von bestehenden IHE XDS Document Repositories: Bestehende Datenspeicher können transparent angebunden werden, sofern beim Schrieben der Daten eine Registrierung am digilog Datenregister erfolgt. Dieses Verfahren wird aktuell genutzt, um Schlüsselsequenzen von Ultraschalluntersuchungen aus einem von GE gehosteten Cloud-Speicher für digilog nutzbar zu machen.

Eine Besonderheit der digilog-Plattform ist, dass Zugriffe auf die Daten immer sowohl über die Schnittstellen des FHIR-Stores als auch der XDS-Akte möglich sind, auch wenn die angefragten Daten in dem jeweils anderen Speichersystem abgelegt wurden. Beispiele für die Nutzung einer solchen Abstraktion von Speicher- und Zugriffslogik sind:

  • Die Ergebnisse eines Langzeit-EKG werden als strukturiertes Dokument in die XDS-Akte geschrieben. Ärzte können daraus generierte Befunde als PDF-Dateien über die XDS-Schnittstelle abrufen. Über die FHIR-Schnittstelle können die im Dokument kodierten Einzelmessungen abgefragt werden und anschließend mit anderen Daten korreliert werden. Auch eine Umsetzung spezifischer Darstellungsformen kann so realisiert werden (siehe Grafik unten für die Darstellung eines EKG im digilog Arzt-Cockpit);
  • Daten aus patientennaher Sensorik werden als Folge von Einzelwerten über den IoT-Hub in den FHIR-Store geschrieben und können von dort über REST-Schnittstellen abgefragt werden. Bestehende Krankenhausinformationssysteme, die in der Rolle eines IHE Document Consumer agieren, können diese Daten über die IHE-Schnittstelle als dynamisch erzeugtes PDF- oder strukturiertes CDA-Dokument abrufen.

Alle für digilog entwickelten Software-Bausteine laufen innerhalb eigener Docker-Container. Hiermit ist es möglich, die gleiche Komponente einfach über eine Änderung der Konfiguration zwischen dem eHealth-Center, einem externen Rechenzentrum oder einer Cloud hin und her zu verschieben, ohne dass andere Systeme innerhalb des digilog-Ökosystems hiervon etwas mitbekommen würden.

CDA-Dokument

strukturiertes CDA-Dokument abrufen.

Literaturverzeichnis

[1] Witting K, Moehrke J: Health Information Exchange – Enabling Document Sharing Using IHE Profiles. IHE IT Infrastructure White Paper. Januar 2012.
[2] Caumanns J: Datenschutz und Datennutz bei elektronischen Patientenakten. Datenschutz und Datensicherheit 37 (2013), Nr.3, S.137-142
[3] IHE IT Infrastructure Technical Framework: www.ihe.net
[4] HL7 Fast Healthcare Interoperability Resources (FHIR): www.hl7.org

passbild_jc
de_DEGerman
en_GBEnglish de_DEGerman