-
Die
Erfindung betrifft Computer-Plattform zum Verwalten, Speichern und
Austausch von computergestützten medizinischen Taskflows.
Des Weiteren bezieht sich die Erfindung auf ein Verfahren zur Ablaufsteuerung
eines computergestützten medizinischen Taskflows, der unter
mehreren Servern einer Gruppe von Servern ausgetauscht wird, sowie
ein Computerprogrammprodukt mit Computerprogrammcode zur Durchführung
des Verfahrens.
-
Moderne
Krankenhäuser sind hocheffiziente Unternehmen, die ihren
Patienten die beste und schnellste Behandlung jeglicher Krankheiten
anbieten wollen. Um dieses Ziel zu erreichen und wettbewerbsfähig
zu sein, werden die Krankenhäuser mit aktuellen Hard- und
Softwaresystemen ausgestattet. Eine komplette IT-Landschaft eines
Krankenhauses besteht aus einer Vielzahl von Servern und Workstations,
die Ärzte bei ihrer täglichen Arbeit unterstützen.
-
Dabei
ist die gesamte IT-Landschaft gemäß den Krankenhausabteilungen
unterteilt. Jede Krankenhausabteilung enthält die für
ihren Zweck nötige IT-Landschaft. Entwicklung einer IT-Landschaft
für eine Krankenhausabteilung ist ein sehr schwieriger und
aufwendiger Prozess. Der Prozess beginnt mit einer IT-Anforderungsanalyse.
Um die Anforderungen mit einer speziellen IT-Lösung erfüllen
zu könnnen, wird festgelegt, wie die speziell konzipierte IT-Lösung
mit IT-Lösungen in anderen Krankenhausabteilungen und übergreifenden
Systemen zusammenarbeiten und kommunizieren können.
-
Orientierungshilfen
für den Entwurf einer IT-Architektur einer Krankenhausabteilung
gibt es derzeit nicht. Ferner existiert auch kein „generisches Template” für
IT-Architekturen der Krankenhausabteilungen, das instanziiert werden
kann, um eine geeignete IT-Architektur für eine Abteilung
zu erstellen. Dies führt dazu, dass Krankenhausabteilungen
unterschiedliche IT-Architekturen besitzen und daher eher eine sehr
heterogene IT-Landschaft aufweisen. Die Folge solcher heterogenen
IT-Architekturen in den einzelnen Krankenhausabteilungen ist, dass
ein reibungsloser und performanter Datenaustausch zwischen den Abteilungen
erschwert wird. Ein weiteres Problem dabei ist, dass Service Techniker
die IT-Architekturen in den einzelnen Abteilungen nicht nach einem
einheitlichen Schema warten können. Sie müssen
für jede einzelne IT-Architektur trainiert werden, um Wartungsarbeiten
durchführen zu können.
-
Um
eine IT-Architektur für eine Krankenhausabteilung zu erstellen,
werden zuerst Anforderungen gesammelt, die spezifizieren, was ein
System leisten soll. Anhand dieser Spezifikation werden die Bausteine
(Server, Workstations etc.) für ein System festgelegt.
Wenn die Bausteine definiert sind, wird deren Integration spezifiziert.
Dabei steht der Datenaustauschaspekt im Vordergrund. Eine Ansammlung der
Systembausteine zusammen mit deren Interaktionen ergibt eine fertige
IT-Architektur einer Krankenhausabteilung. Des Weiteren wird festgelegt,
wie sich die entstandene IT-Architektur in die bestehende IT-Architektur
im Krankenhaus integrieren lässt.
-
Dabei
wird betrachtet, wie die neue Abteilung mit bestehenden Abteilungen
effizient Daten austauschen kann. Außerdem wird in Betracht
gezogen, wie die neue Abteilung mit bestehenden übergeordneten Systemen
wie z. B. das sogenannte Health In formation System kommunizieren
kann. Der ganze oben beschriebene Prozess ist manuell, fehlerträchtig
und muss zudem für jede Krankenhausabteilung wiederholt
werden. Eine IT-Architekturentwicklung für Krankenhausabteilungen
ist demnach ein sehr aufwendiger, nicht standardisierter und deshalb
verbesserungswürdiger Prozess.
-
Um
den Entwurf der IT-Architekturen für Krankenhausabteilungen
zu erleichtern und automatisierter zu gestalten, werden Ähnlichkeiten
der Abteilungen aufgedeckt und zu einem generischen, instanziierbaren
Template geführt. Eine Krankenhausabteilung wie z. B. Radiologie,
Mammographie oder Kardiologie beschäftigt sich im IT-Sinne
im Wesentlichen mit drei datenverarbeitungstechnischen Schritten:
- 1. Akquisition, Verarbeitung und Nachverarbeitung
der medizinischen Patientenbilder,
- 2. Kurz- und langfristige Speicherung sowie dauerhafte Archivierung
der medizinischen Patientenbilder und
- 3. Transfer (Empfang und Versand) der medizinischen Patientenbilder.
-
Für
die Akquisition wird spezielle Hardware wie Computertomographen,
Magnetresonanzgeraete, Ultraschallgeraete etc. verwendet. Diese
Geräte produzieren medizinische Bilder, die als Basis für
jegliche weiteren Datenverarbeitungsaktivitäten in einer Krankenhausabteilung
dienen. Nachdem die Bilder akquiriert wurden, werden sie an speziellen
Workstations verarbeitet. Sie werden von den Ärzten analysiert
und bei Bedarf verändert. In dem Verarbeitungsschritt werden
auch Patientenbefunde durchgeführt. Im nächsten
Verarbeitungsschritt werden die Bilder gespeichert. Die Speicherung
kann dabei entweder kurz-(maximal ein Tag) oder langfristig (maximal
einige Ta ge) sein. Außerdem werden manche Bilder am Ende
der Verarbeitung dauerhaft in einem speziellen Archiv gespeichert.
Schließlich sollte eine Krankenhausabteilung in der Lage
sein, medizinische Bilder über ein Krankenhausnetzwerk
zu empfangen und verschicken. Das dabeiverwendete Netzwerkprotokoll
ist derzeit das sogannte standardisierte DICOM-Protokoll.
-
Wenn
man den vorstehend erläuterten Prozess analysiert, ist
erkennbar, dass die Daten in einer Krankenhausabteilung sowohl berechnet
(vertreten durch Akquisition sowie Vor- und Nachverarbeitung, gespeichert
und transferiert werden.
-
Diese
Datenverarbeitungsschritte (Berechnen, Speichern, Transferieren)
sind den Verarbeitungsschritten in einem Standard-PC sehr ähnlich. Ein
Standard-PC kann wie eine Krankenhausabteilung die Daten in einem
Prozessor berechnen, im Speicher speichern und durch einen Datenaustauschbus
zwischen Prozessor und Speicher transferieren.
-
Es
ist demnach Aufgabe der Erfindung, eine einheitliche IT-Architektur
für ein Krankenhaus bzw. Klinik oder eine ähnlich
organisierte medizinische Praxis zu entwickeln, die in allen Abteilungen
(z. B. Kardiologie, Radiologie, Onkologie etc.) eingesetzt werden
kann, wobei diese für den Einsatz von Standardsoftware-Applikationen
sowie einem standardisierten Datenaustausch geeignet sein soll.
-
Diese
Aufgabe wird durch die in den unabhängigen Patentansprüchen
angegebenen Merkmale gelöst. Vorteilhafte Weiterbildungen
sind in den abhängigen Ansprüchen gekennzeichnet.
-
Ein
Aspekt der Erfindung ist eine Computer-Plattform zum Verwalten,
Speichern und Austausch von computergestützten medi zinischen Taskflows.
Dabei kann die Computer-Plattform Hardware- und/oder Software-Subsysteme
aufweisen. Folgende Subsysteme werden von der erfindungsgemäßen
Computer-Plattform umfasst:
- – zumindest
einen Anwendungsserver (EA) zur Verwaltung und Steuerung von medizinischen
Anwendungsprogrammen sowie deren Ablauf,
- – zumindest einen Ressourcenmanagement-Server (ER)
für ein Taskflow-Management, zur Daten- und Speicherverwaltung,
- – und zumindest ein Netzwerk-Service (EN) zur Zugriffssteuerung
von außen, Lastverteilung und Verwaltung von Servern und/oder
Gruppen von Servern,
wobei jedes Subsystem auf einem separaten
Server und/oder Gruppe von Servern betrieben wird.
-
Zweckmäßigerweise
kann eine Gruppe von Servern zumindest eine Server-Farm und/oder
Server-Cluster umfassen, wie im nachstehenden Ausführungsbeispiel
erläutert ist.
-
Vorteilhafterweise
kann jedes Subsystem in einen lokalen und einen abgesetzten Anteil,
auch remote-Anteil genannt, aufweisen.
-
Ein
weiterer Anspekt der Erfindung ist ein Verfahren zur Ablaufsteuerung
eines computergestützten, medizinischen Taskflows, der
unter mehreren Servern (AS1, AS2, AS3) einer Gruppe von Servern
ausgetauscht wird.
-
Das
erfindungsgemäße Verfahren umfasst folgende Schritte:
- a) Starten eines medizinischen Taskflows auf
einem ersten Server (AS2) der Gruppe, initialisiert durch einen
den ersten Server steuernden zweiten Server (CSM) der Gruppe,
- b) Unterdrücken des medizinischen Taskflows auf dem
ersten Server durch den zweiten Server, wobei die Zwischenergebnisse
der bereits abgelaufenen Tasks (T1, T2, T3) des Taskflows (TF1)
zwischengespeichert werden,
- c) Lastabhängige Zuweisung des Taskflows durch den
zweiten Server an zumindest einen dritten Server (AS3) der Gruppe
und Wiederbelebung des Taskflows und
- d) Weiterverarbeitung des Taskflows auf dem dritten Server mit
Hilfe eines für den dritten Server möglichen Zugriffs
auf die zwischengespeicherten Zwischenergebnisse.
-
Dabei
kann das erfindungsgemäße Verfahren auf der erfindungsgemäßen
Computer-Plattform angewendet werden.
-
Günstig
ist es, wenn die Taskflows zustandsunabhängig ablaufen.
-
Eine
vorteilhafte Weiterbildung der Erfindung ist es, wenn Tasks eines
Taskflows durch einen sogenannten Frontend- und Backend-Anteil repräsentiert werden.
-
Ein
weiterer Aspekt der Erfindung ist ein Computerprogrammprodukt mit
Computerprogrammcode zur Durchführung der Verfahrensschritte des
erfindungsgemäßen Verfahrens, wobei der Computerprogrammcode
auf einem Computer, insbesondere auf der erfindungsgemäßen
Computer-Plattform, ausgeführt wird. Der Computerprogrammcode kann
hierbei auf einem von einem Computer lesbaren Medium gespeichert
sein.
-
Vorteile
der Erfindung ergeben sich aus dem nachfolgend beschriebenen Ausführungsbeispiel.
-
Nachstehend
wird ein Ausführungsbeispiel der Erfindung unter Bezugnahme
auf eine Zeichnung näher erläutert.
-
In
der Zeichnung zeigen:
-
1 eine
mögliche erfindungsgemäße Architektur
eines Krankenhauscomputersystems, als Departmental Computer bezeichnet,
-
2 eine
mögliche Architektur mehrere Departmental Computer,
-
3 den
erfindungsgemäßen Datenaustausch als sogenannten
Taskflow,
-
4 eine
mögliche Zweiteilung der Plattformsubsysteme in ein lokalen
und eine „remote” (abgesetzten) Anteil.
-
5 beispielhaft
eine sogenannte Transfer Server Farm und eine sogenannte Applikation
Server Farm in einer Krankenhausabteilung,
-
6 und 7 jeweils
beispielhaft ein Krankenhaus-Computer-Netwerk, das mindestens zwei
Krankenhausabteilungen versorgt,
-
8 und 9 jeweils
beispielhaft eine Vernetzung von mehreren Krankenhausnetzwerken mit
und ohne einem zentralen Datenzentrum.
-
Die
Umsetzung des in 1 dargestellten Departmental
Computers basiert auf der Möglichkeit, einzelne Subsysteme
des Computers auf einer eigenständigen Server Farm bzw.
auf einem eigenständigen Server Cluster ablaufen zu lassen.
-
Unter
dem Begriff „Server Farm” wird hierbei verstanden,
dass mehrere Servern mit derselben Software und einem sogenannten
Load Balancer – wie er beispielsweise in der älteren
Patentanmeldung
DE 10 2008
040 009.2 bereits vorgeschlagen worden ist – ausgestattet
sind. Der Load Balancer wählt für jede Anfrage
an die Farm einen Server der Farm mit der geringsten Last für
die Anfragebearbeitung aus. Die Server der Farm be arbeiten in der
Regel parallel die Anfragen an die Farm, um insgesamt die vom Benutzer
wahrgenommene Performance bzw. Leistung der Software zu erhöhen.
Ein Server Cluster hingegen besteht aus mehreren Servern, von denen
zu einem Zeitpunkt nur einer die Anfragen bearbeitet und bei dessen
Auswahl ein anderer Server des Clusters in Betrieb genommen wird.
Die Server des Clusters bearbeiten die Anfragen an die Farm also
nicht parallel, sondern werden für die Implementierung
eines sogenannten Failover-Konzepts (Fehlerbehandlungskonzept) verwendet,
um die Verfügbarkeit der Software zu erhöhen.
-
Die
Subsysteme des in der 1 dargestellten Departmental
Computers ist ein Teil einer Plattform für medizinische
Applikationen. Im Gegensatz zu anderen Softwareplattformen, deren
Subsysteme alle zusammen auf einer einzigen Serverfarm/Cluster laufen
gelassen werden können, ist es mit der erfindungsgemäßen
Platform möglich, jedes Subsystem auf einer separaten Server
Farm/Cluster ablaufen zu lassen. Diese starke Verteilung der einzelnen
Subsysteme der Plattform auf eigenständige physische Server
Farmen/Cluster ist im medizinischen Bereich günstig, um
der hohen Last an Anfragen an jedes Subsystem durch eine Krankenhausabteilung
bzw. ein ganzes Krankenhaus – wie z. B. in 2 dargestellt – bewältigen
zu können. Krankenhausabteilungen können – wie
in 2 gezeigt – eine Radiologie, Cardiologie
und eine Ökologie sein.
-
Die
Verteilung der Plattformsubsysteme auf disjunkte Server Farmen/Cluster
ist für die Plattformapplikationen – auch Medical
Tasks genannt – komplett transparent.
-
Diese
präsentieren sich dem Benutzer als sogenannte Rich Thin
Client Tasks. Solche Tasks werden in einen sogenannten Frontend-
und Backend-Anteil aufgeteilt. Das Backend solcher Tasks wird auf
dem Departmental Computer ausgeführt, während das
Frontend als Rich Client (kein Web Client) auf der lokalen Workstation
angeführt wird.
-
Die
erfindungsgemäße Plattform weist dabei folgende
Komponenten bzw. Subsysteme auf:
- 1. einen Enterprise
Application Servers EA (vergleichbar mit einem Main Board Funktionalität
bei einem Standard-PC),
- 2. Enterprise Runtime & Resource
Services ER (vergleichbar mit einer Memory Board Funktionalität
bei einem Standard-PC),
- 3. Enterprise Network Services EN (vergleichbar mit einer Mother
Board & Backplane
Funktionalität bei einem Standard-PC).
-
Diese
Plattformkomponenten (in verschiedenen Ausprägungen) sind
in der Regele in einer Krankenhausabteilung zu finden. Im Folgenden
werden die vorstehend genannten drei Komponenten genauer erläutert:
-
Zu 1.) Enterprise Application Servers:
-
- a) Web Server WS – viele der in Krankenhausabteilungen
eingesetzten medizinischen Software Applikationen sind web-basiert
und laufen auf Web Servern. Um Ihre Verfügbarkeit zu erhöhen, werden
sie oft als Web Server Farm verwendet.
- b) Application Server AS – auf diesen Server können
nicht webbasierte medizinische Applikationen ablaufen. Auch sie
werden oft als Server Farm verwendet.
- c) Der DICOM Server DS ist für das Empfangen von medizinischen
DICOM-Bildern zuständig. Bei Bedarf wird der Server in
einer Server Farm verwendet.
- d) Der Transfer Server TS ist für das Versenden von
medizinischen DICOM Bildern zuständig. Bei Bedarf wird
der Server in einer Server Farm verwendet.
-
All
diese Server sind durch ein Lokal Area Network LAN vernetzt, das
mit dem Krankenhaus Wide Area Network WAN verbunden ist.
-
Zu 2.) Enterprise Runtime & Ressource Services
ER:
-
- a) Workflow Server WMS – Ärzte
in einer Krankenhausabteilung arbeiten nach einem bestimmten, in
der Regel vordefinierten Arbeitsablauf (auch Workflow genannt).
Auf dem Workflow Server läuft das entsprechende Workflow
Management System ab. Der Workflow Server kann bei Bedarf in Cluster
zusammengefasst (oder repliziert) werden, um eine hohe Ausfallsicherheit
zu erreichen.
- b) Operational Management Server OM – Systeme, die
alle anderen Systeme in der Krankenhausabteilung überwachen.
Hier wird bei Bedarf auch Clustering eingesetzt.
- c) Index DB (Datenbank) Server DMS – verwaltet Index
Daten von medizinischen Bildern. Dieser Server ist in der Regel
in Clustern verwaltet.
- d) Enterprise Application Integration Server EAI – ist
für die Anbindung der Krankenhauseabteilung an externe
Systeme zuständig. Hier wird auch nach Bedarf Clustering
verwendet.
- e) Storage Server WFS – beinhaltet Short Term Storage
STS (repräsentiert durch bestimmte Verzeichnisse im File
System) und Long Term Storage LTS (repräsentiert durch
ein PACS Archiv).
-
All
diese Server sind in einem LAN vernetzt, das an das Krankenhaus
WAN angeschlossen ist.
-
Zu 3.) Enterprise Network Services EN:
-
- a) Firewall – schützt die
Abteilung vor unerlaubten Zugriffen von außen.
- b) Load Balancer – ermoeglicht Server Load Balancing
(Verteilung der Last) für den Enterprise Application Server
EA.
- c) Open Switch und Cluster Server – sind für
Clustering zuständing
-
Das
sogenannte Departmental IT Architektur Template ist die in der 1 vorgestellte
Architektur. Das Template kann verwendet werden, um eine IT Architektur
für eine beliebige Krankenhausabteilung zu erstellen.
-
Im
Folgenden beschreiben wir die für eine Template Instanziierung
nötigen Schritte. Um das Template zu instanziieren, muss
für eine Krankenhausabteilung geklärt werden:
- 1. Werden Webapplikationen eingesetzt? Falls
ja, müssen Web Server verwendet werden. Falls die Webapplikationen
sehr interaktiv und nicht nur gelegentlich verwendet werden, müssen
die Webserver in einer Server Farm zusammengefasst werden. In diesem
Fall, sollte ein LoadBalancer verwendet werden.
- 2. Wie viele Applikationsserver werden benötigt? Je
nach Benutzer Profil sollten die Server mit dem LoadBalancer zu
einer Farm zusammengefaßt werden.
- 3. Falls Applikationen medizinische Bilder empfangen werden,
sollten DICOM-Server aufgestellt und nach Bedarf mit dem LoadBalancer
zu einer Farm zusammengefaßt werden.
- 4. Falls durch Applikationen medizinische Bilder versendet werden,
müssen Transfer Server aufgestellt und nach Bedarf mit
dem LoadBalancer zu einer Farm zusammengefasst werden.
- 5. Falls die Abteilung mit Workflows arbeitet, solte ein Workflow
Server für das Workflow Management System aufgestellt werden.
Bei Bedarf muss er mit OpenSwitch oder Cluster Server geclustered
werden.
- 6. Um Ressourcen in der Abteilung zu überwachen, sollte
ein Operational Management Server aufgestellt und bei Bedarf in
Cluster zusammengefaßt werden.
- 7. Für die Datenbankverwaltung sollte eine Index DB
Server verwendet und in Cluster zusammengefasst werden.
- 8. Für die externe Anbindung der Abteilung sollte ein
Enterprise Application Integration Server EAI aufgestellt und bei
Bedarf in Cluster zusammengefasst werden.
- 9. Je nach Abteilungsgröße sollte eine bestimmte Anzahl
an Servern für Short Term Storage (STS) installiert werden.
Darüber hinaus sollte ein Archiv für Long Term
Storage von medizinischen Bildern aufgestellt werden.
- 10. Um den Datenzugriff von außen abzusichern, wird
ein Firewall Server benoetigt.
- 11. Falls Load Balancing gebraucht wird, sollte ein entsprechender
Server installiert werden.
- 12. Fall Clustering benoetigt wird, sollten Open Switch und/oder
Cluster Server installiert werden.
-
Im
Folgenden wird die Funktionalität der Komponenten bzw.
Subsysteme der Plattform erläutert:
-
1. Verteilung der Service
Software an Web Server WS
-
Links
oben in der 1 ist eine Web Server Farm dargestellt.
Diese wird verwendet, um die Service Software der Plattform zu anzuwenden.
Die Service Software wird von den klinischen Administratoren verwendet,
um die Plattform zu konfigurieren. Die Software ist als Web Applikation
realisiert, die stateless (zustandslos) ist. Die Realisierung der
Software als Web Applikation hat den Vorteil, dass sie auf einem
Web Server ablaufen kann und über einen Web Browser von
einem beliebigen Rechner im Krankenhaus zugänglich ist.
-
Die
Realisierung der Service Software als eine Stateless Web Applikation
bedeutet, dass die Anfragen an den Server völlig unabhängig
voneinander sind. Die Daten einer Anfrage werden während der
Anfragebearbeitung transaktional persistiert. Bei Bedarf extrahiert
die nächste Anfrage die Daten aus dem persistenten Speicher
(wie z. B. Datenbank). Es existieren keine transienten Daten im
Cache der Applikation, die über eine Anfrage hinweg gespeichert werden.
-
Dieses
Verhalten ermöglicht es, eine Web Server Farm für
die Service Software aufzustellen, deren Server die Anfragen parallel
zueinander bearbeiten, um die Performance der Software zu verbessern.
Der Load Balancer der Farm wählt bei Ankunft einer Anfrage
einen freien Web Server aus und übergibt ihm die Anfrage
zur Bearbeitung. Für das Load Balancing der Web Server
Farm werden Standardlösungen verwendet.
-
2. Verteilung der Taskflows
an Application Server AS
-
Der
Application Server AS, rechts vom Web Server WS in der 1 angeordnet,
ist in der Lage, sogenannte Medical Taskflows auszuführen.
-
Taskflows
sind eine Abfolge von Tasks bzw. Aufgaben. Wie beispielsweise in 3 gezeigt,
wird ein Taskflow TF1 vom sogenannten Central Strategy Manager CSM
erzeugt und verwaltet. Bei Erzeugung eines Taskflows werden seine
einzelnen Tacks T1, T2, T3 vom CSM instanziiert und gestartet.
-
Bei
Vorhandensein einer Application Server (AS) Farm, erzeugt der CSM
einen Taskflow auf dem Server der Farm, der am meisten Ressourcen
besitzt und gerade für den Taskflow zur Verfügung
hat. Ein Taskflow ist in der Lage, benötigte Ressourcen
durch Konfiguration zu spezifizieren. Außerdem ist der CSM
in der Lage, bei einem AS die momentane Belegung bestimmter Ressourcen
abzufragen. Folglich kann der CSM den besten Server für
die Ausführung eines Taskflows ermitteln. Dieser Load Balancing
Algorithmus ist ein Dienst zur automatischen Ver teilung von softwaregestützten
medizinischen Arbeitsabläufen innerhalb einer Gruppe von
Anwendungsservern. Dieser ist beispielsweise in der älteren
Patentanmeldung
DE 10 2008
040 009.2 bereits vorgeschlagen worden.
-
Taskflows
können deshalb auf einzelne AS der Farm verteilt werden,
weil sie unabhängig voneinander sind. Sie speichern ihre
Ergebnisdaten im Short Term Storage (STS), über den der
Datenaustausch zwischen den Taskflows stattfindet. Es existieren
keine transienten Daten zwischen den Taskflows. Mehrere Taskflows
können also parallel zueinander auf unterschiedlichen Servern
ablaufen, um die Performance des Gesamtsystems zu erhöhen.
-
Ein
Taskflow kann im Laufe seines Lifecycles (Lebenszyklus) vom CSM
mehrmals suspendiert (unterdrückt = Suspend) und wiederbelebt
(Resume) werden. Dieser Vorgang ist in der 3 dargestellt.
-
Als
erstes wird in 3 ein Taskflow TF1 auf dem Application
Server AS2 vom CSM gestartet. Dabei werden die Tasks T1, T2 und
T3 des Taskflows auf AS2 gestartet. Der CSM wählt den AS2
gemäß des oben beschriebenen Algorithmus. Einige
Zeit später im Schritt 2 wird der Taskflow unterdrückt.
Die Tasks T1, T2 und T3 bekommen entsprechende Benachrichtigungen
und reagieren darauf, indem sie ihre temporären Arbeitsergebnisse
im STS persistieren.
-
Im
Schritt 3 wird der Taskflow TF1 durch den CSM wiederzubelebt. Dabei
wird wieder der oben beschriebene Load Balancing Algorithmus konsultiert, um
einen geeigneten Server der Farm – z. B. AS3 – auszuwählen.
Anschließend wird der TF1 auf dem AS3 wiederbelebt. Die
Tasks T1, T2 und T3 erhalten entsprechende Benachrichtigungen und
reagieren darauf, indem sie ihre beim Suspend gesicherten Arbeitsergebnisse
aus dem STS herausholen und weiter verarbeiten. Die Implementierung
des Suspend/Resume Protokolls durch Tasks macht es möglich,
Load Balancing nicht nur beim Hochfahren der Taskflows anzuwenden,
sondern auch während ihrer Ausführung, beim sogenannten
Resume-Vorgang.
-
Ein
weiterer wichtiger Aspekt der Taskrealisierung ist, dass Tasks nicht
direkt auf die in 1 dargestellten Subsysteme zugreifen,
die auf Serverfarmen bzw. Serverclusters laufen. Vielmehr hat jedes
Subsystem einen lokalen und einen remote Anteil. Dies ist in der 4 dargestellt.
-
4 zeigt
5 Subsysteme der Plattform: EAI, TMS, DMS, WMS und OM. Jedes dieser
Subsysteme hat einen Anteil, wobei der Taskflow lokal abläuft. Dieser
wird Framework genannt. Folglich hat die Plattform 5 Frameworks,
die in 4 illustriert sind: EAIF, TMF, DMF, WMF und OMF.
Ein Framework läuft immer im Betriebssystemprozess der
Task, die es benutzt. Falls Tasks eines Taskflows in verschiedenen
Betriebssystemprozessen laufen, wird jeweils eine Frameworkinstanz
pro Prozess vom CSM erzeugt.
-
Die
Frameworks nehmen Requests der Tasks entgegen und leiten diese an
die im unteren Teil der 4 dargestellten entsprechenden
Subsysteme weiter, die in einer Farm bzw. Cluster organisiert sind.
Die in 4 gezeigte Zweiteilung der fünf Subsysteme
hat den entscheidenden Vorteil, dass Stateful Anteile, d. h. zustandsabhängige
Anteile, lokal bei Stateful Tasks laufen gelassen werden. Diese Anteile
sind wegen Statefulness nicht für eine Farm geeignet. Die
Stateless Anteile sind hingegen für eine Farm bzw. Cluster
geeignet.
-
Die
Kopplung zwischen dem entsprechenden Framework und seinem remote
Anteil (abgesetzten Anteil) auf der Farm/dem Cluster wird mittels
eines Netzwerkprotokolls realisiert. Deshalb ist es möglich,
diese physisch über verschiedene Server zu verteilen, ohne
dass die Software auf den Servern geändert werden muss.
-
4 zeigt
ebenfalls eine Besonderheit der erfindungsgemäßen
Plattform: Es werden sowohl die einzelnen Subsysteme der Plattform
in einer Farm bzw. Cluster (EAI, TMS, DMS, WMS, OM) als auch die
Taskflows selbst auf der AS Farm zusammengefaßt.
-
In
den nächsten fünf Abschnitten wird detailliert
auf das Farming/Clustering Verfahren in den fünf in 4 dargestellten
Subsystemen eingegangen.
-
3. Verteilung des Transfer
Management Subsystems TMS
-
Das
Transfer Management Subsystem wird in 1 auf zwei
eigenständige Server verteilt: DICOM Server und Transfer
Server. Der DICOM Server ist für den Empfang der medizinischen
Bilder über DICOM Protokoll verantwortlich, während
der Transfer Server für den Versand der Bilder zuständig
ist. Beide Server können in einer Farm betrieben werden.
-
Das
Farming des DICOM Servers wird dadurch möglich, dass seine
Implementierung mittels Stateless Service Components umgesetzt wird,
die einen bestimmten Port/Ausgang des Servers überwachen.
Eine Anforderung bzw. Request an den Server kann von jedem beliebigen
Server der Farm bearbeitet werden. Die Requests sind unabhängig
voneinander.
-
Für
das Farming des DICOM Servers kann ein Load Balancing Algorithmus,
wie z. B. vorstehend angegeben, verwendet werden. Der Transfer Server basiert
auf dem Konzept asynchroner Aufträge. Ein asynchroner Auftrag
wird vom CSM auf dem AS in einem separaten sogenannten Thread abgearbeitet. Damit
der CSM den Auftrag abarbeiten kann, benötigt er eine entsprechende self-contained
Auftragsbeschreibung. Da die Aufträge unabhängig
voneinander sind, können sie auf einzelne Server der Farm verteilt
werden, um die Performance der Auftragsabarbeitung zu erhöhen.
Für das Farming des Transfer Servers wird der Load Balancing
Algorithmus (siehe 2.) verwendet.
-
4. Verteilung des Workflow
Management Subsystems WMS
-
Das
Workflow Management System besteht aus zwei Remote Service Components
(RSCs): WorkflowRSC und InformationRSC. Die WorkflowRSC verwaltet
eine Datenbank, die Workflow Informationen der Abteilung speichert.
Zu den Workflow Informationen gehören: Ein Workflow Template,
das den Inhalt des Workflows beschreibt; Workitems des Workflows;
Zustandsinformationen über Workflows und Workitems;
Zugehörigkeit
eines Workflows zu einer DICOM Procedure etc. Die InformationRSC
verwaltet eine Datenbank, die Patienteninformationen des Departments
speichert. Zu den Patienteninformationen gehören: Patientenname,
Alter (evtl. auch Demographische Daten), Besuch, Auftrag, Vorgehen
bzw. Behandlung etc.
-
WMS
Informationen werden normalerweise nicht in einer Farm behandelt,
da an der Stelle kein Leistungsengpaß zu erwarten ist.
Für eine hohe Verfügbarkeit soll ein Cluster verwendet
werden. Dies ist möglich, da sowohl die WorkflowRSC als
auch die InformationRSC stateless (zustandsunabhängig)
sind. Für das WMS Clustering können bekannte Clustering Algorithmus
verwendet werden.
-
Darüber
hinaus kann die Datenbank, in der die eigentlichen WMS Informationen
gespeichert werden, zusätzlich je nach Bedarf mit nativen
DB-Mitteln für Performanceverbesserungen in einer Farm oder
für die Erhöhung der Verfügbarkeit in
einem Cluster betrieben werden.
-
5. Verteilung des Operational
Managements OM
-
Operational
Management setzt auf folgende Softwaresysteme auf:
Active Directory
für das Benutzer Management,
ADAM für die
Benutzer Authorisierung und Authentifikation, Oracle für
allgemeine Datenspeicherung (wird z. B. von WMS und DMS verwendet),
Clustering (und bei Bedarf auch Farming) möglich, weil
alle oben aufgeführten Softwareprodukte dies unterstützen.
-
6. Verteilung des Data Management
Subsystems DMS
-
Das
Data Management Subsystem erzeugt und verwaltet einen DB-Index über
medizinische Bilder, die sich im STS befinden. Der Index wird von
den Tacks verwendet, um schnell Abfragen der vorhandenen Bilder
durchführen zu können. Die Indexverwaltung wird
von einer Remote Service Component (RSC) realisiert.
-
DMS
Clustering erfolgt auf der einen Seite durch Clustering der darunterliegenden
Oracle Datenbank, die den Index speichert. Auf der anderen Seite
kann bei Bedarf die Verwaltungs-RSC selbst auf einem separaten Cluster
angewendet werden, da sie Stateless (zustandsunabhängig)
realisiert ist. Dabei kann ein bekannter Clustering Algorithmus
verwendet werden.
-
7. Verteilung der Enterprise
Application Integration EAI
-
EAI
Subsystem besteht im Wesentlichen aus einem OpenLink Server und
einer Komponente, die den Zugriff auf den Server verwaltet. Clustering
des Servers, um seine Verfügbarkeit zu erhöhen,
wird unterstützt.
-
Darüber
hinaus formuliert das EAI Subsystem asynchrone Aufträge
(ähnlich wie oben bereits beschrieben). Diese können
auf der Application Server Farm abgearbeitet werden.
-
8. Verteilung des Short Term Storage STS
-
Short
Term Storage wird als Network Attached Storage (NAS) realisiert.
D. h. es ist ein eigenständiger Server mit eigenem Betriebssystem.
Folglich kann der Server in einer Farm bzw. Cluster betrieben werden.
Es kann auch von Vorteil sein, den Server zu replizieren.
-
9. Verteilung des Long Term
Storage LTS
-
LTS
ist ein Langzeitarchiv für medizinische Bilder. Hier kann
ein Softwareprodukt eingesetzt, das Clustering/Farming mit DB-Mitteln
unterstützt. Es kann auch von Vorteil sein, den Server
zu replizieren.
-
5 zeigt
beispielhaft eine sogenannte Transfer Server Farm und eine sogenannte
Applikation Server Farm in einer Krankenhausabteilung.
-
Die 6 bis 9 zeigen
Beispielanwendungen der Plattform für Krankenhäuser
bzw. Kliniken vor, die auf dem erfindungsgemäßen
Konzept basieren.
-
6 und 7 zeigt
jeweils beispielhaft ein Krankenhaus-Computer-Netwerk, das mindestens zwei
Krankenhausabteilungen versorgt. 8 und 9 zeigt
jeweils beispielhaft eine Vernetzung von mehreren Krankenhausnetzwerken
mit und ohne einem zentralen Datenzentrum.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- - DE 102008040009 [0033, 0049]