-
Die
Erfindung betrifft ein Verfahren und ein System zum Verteilen von
Applikationen in einem Datenverarbeitungsnetzwerk, insbesondere
in einem Datenverarbeitungsnetzwerk einer medizinischen Einrichtung.
-
Aus
der
DE 10 2006
051 189 A1 ist ein Verfahren zum Erstellen und Ausführen
zumindest einer Applikation in Abhängigkeit von einer Einsatzumgebung
bekannt. Im Rahmen dieses Verfahrens können verschiedene
Deployment-Szenarien zum Tragen kommen, nämlich Thin-Client,
Rich-Thin-Client, Rich-Client, Adaptive-Client, Fat-Client und Web-Service.
Die Applikationen sind n-schichtig strukturiert und weisen eine Präsentationsschicht
zur Darstellung von Informationen und für Benutzerinteraktionen,
eine Geschäftsprozess-Schicht, die unterschiedliche Geschäfts-Prozess-Logik-Module
umfasst, sowie eine Controllerschicht auf. Im Fall eines Rich-Thin-Client
kann die Controller-Schicht zweigeteilt beziehungsweise als Netzwerkfunktionalität
ausgelegt sein, wodurch die Anforderungen an die Hardware eines
Zielrechners sinken, da viele rechenaufwändige Vorgänge
auf einem leistungsstarken Rechner, den sich mehrere Anwender teilen,
abgearbeitet werden können.
-
Vorzugsweise
sind die verschiedenen Schichten bei dem aus der
DE 10 2006 051 189 A1 bekannten Software-Architektur-System
unabhängig von der Deployment-Strategie programmiert. Die
flexible, je nach Bedarf und Einsatzumgebung herunterladbare Applikations-Architektur
erkennt, in welchem Einsatz sich eine Applikation gerade befindet.
Die Module der Applikation, beispielsweise ihre Schichten, werden
so geladen und angeordnet, dass der Applikation ihre aktuelle Einsatzumgebung „verborgen” bleibt
beziehungsweise bei der Programmierung und/oder beim Programmstart
nicht berücksichtigt werden muss.
-
Häufig
verwendete Bezeichnungen für Schichten einer Systemarchitektur
sind „Model”, „View” und „Controller”,
zusammenfassend auch MVC Softwaremuster genannt. In diesem Zusammenhang
wird auf die
DE 196
25 841 A1 verwiesen, die eine medizinische Systemarchitektur
betrifft. Weiter wird auf die
DE 10 2005 010 405 A1 verwiesen, welche eine
Systemanordnung und ein Verfahren zur automatisierten Applikationsentwicklung
mit Benutzerführung betrifft.
-
In
Krankenhäusern kommen vermehrt PACS-Systeme (Picture Archiving
and Communication System) zum Einsatz. Anwendungsmöglichkeiten
eines PACS-Systems sind zum Beispiel in der
DE 10 2006 033 861 A1 offenbart.
PACS-Systeme sind prinzipiell zur Verarbeitung jeglicher in digitaler
Form vorliegender Bilddaten geeignet. Beispielsweise kann es sich
dabei um mit einem Computertomographiegerät, einem Magnetresonanzgerät,
einem digitalen Röntgengerät oder einem digitalen
Ultraschallgerät erzeugte Bilddaten handeln. Als grundsätzliches
Problem wird in der
DE
10 2006 033 861 A1 das zunehmende Datenvolumen, welches
in medizintechnischen Datenverarbeitungsnetzwerken zu beherrschen
ist, thematisiert. In einem eine Vielzahl von Netzwerkknoten aufweisenden
Datennetzwerk soll dieses Problem mit Hilfe von drei miteinander
verknüpften Verwaltungsprozessen gelöst werden.
Hierbei handelt es sich um einen ersten Verwaltungsprozess zum Zwischenspeichern
von Bilddaten, um einen zweiten Verwaltungsprozess zum Archivieren
der Bilddaten und um einen dritten Verwaltungsprozess zum Laden
der Bilddaten, wie in der
DE 10 2006 033 861 A1 im Detail offenbart
ist. Insgesamt soll damit eine effiziente Verwaltung von medizinischen
Bilddaten ermöglicht sein.
-
Der
Erfindung liegt die Aufgabe zugrunde, die Leistungsfähigkeit
von Datenverarbeitungssystemen, welche mit mehrschichtigen Applikationen
arbeiten, insbesondere im Hinblick auf limitierte Netzwerkressourcen,
gegenüber dem Stand der Technik zu steigern.
-
Diese
Aufgabe wird erfindungsgemäß gelöst durch
ein Verfahren zum Verteilen von Applikationen in einem Datenverarbeitungsnetzwerk
mit den Merkmalen des Anspruchs 1 sowie durch ein zum Verteilen
von Applikationen ausgebildetes System mit den Merkmalen des Anspruchs
6. Im Folgenden im Zusammenhang mit dem Verfahren erläuterte
Vorteile und Ausgestaltungen gelten sinngemäß auch
für die Vorrichtung, das heißt das erfindungsgemäße
System, und umgekehrt.
-
In
einem das Verfahren umsetzenden Datenverarbeitungsnetzwerk, insbesondere
in einem Krankenhaus, existieren mindestens zwei Applikationen,
welche sich hinsichtlich der zu verarbeitenden Datenmengen voneinander
unterscheiden. Jede Applikation ist mehrschichtig aufgebaut, wobei
einzelne Schichten der Applikationen automatisch derart auf unterschiedliche
Hardwareressourcen, nämlich mindestens eine lokale Datenverarbeitungseinheit
und mindestens eine entfernte Datenverarbeitungseinheit, verteilt
werden, dass der Anteil der auf der lokalen Datenverarbeitungseinheit
installierten Schichten an der Gesamtzahl der Schichten der jeweiligen
Applikation bei derjenigen Applikation, welche zur Verarbeitung
der größeren Datenmenge vorgesehen ist, kleiner
als bei der zur Verarbeitung der kleineren Datenmenge vorgesehenen
Applikation ist.
-
Die
Erfindung geht von der Überlegung aus, dass die grundsätzlich
unterschiedliche Behandlung von 2D Daten einerseits und 3D Daten
andererseits einen geeigneten Ansatzpunkt für die Steigerung
der Effizienz in medizintechnischen Datenverarbeitungssystemen darstellt.
Allgemein stellen Applikationen, welche dreidimensionale Bilddaten
(3D Daten) verarbeiten, wesentlich höhere Anforderungen
an den Datentransfer als 2D Applikationen. In einem System mit einer
Mehrzahl lokaler Datenverarbeitungsgeräte und mindestens
einer entfernten, zentralen Datenverarbeitungseinheit scheint es
von daher vorteilhaft zu sein, einen möglichst großen
Teil der 3D Daten lokal zu verarbeiten, um das Netzwerk nicht zu
stark zu belasten, während die 2D Daten, welche einen wesentlich
geringeren Umfang als die 3D Daten haben, zu einem größeren
Anteil zentral verarbeitet und damit häufiger über
das Netzwerk übertragen werden könnten. Dies würde
bedeuten, dass eine in mehrere Schichten gegliederte 2D Applikation,
das heißt eine zur Verarbeitung einer relativ kleinen Datenmenge
vorgesehene Applikation, im Vergleich zu einer 3D Applikation einen
geringeren Anteil an Schichten aufweist, welche lokal installiert
sind.
-
Es
hat sich jedoch gezeigt, dass diese Überlegung den unterschiedlichen
Charakter von Datenverarbeitungsprozessen, welche medizintechnische
3D Daten betreffen, einerseits und Verfahren zur Verarbeitung von
mit bildgebenden medizintechnischen Geräten gewonnenen
zweidimensionalen Daten (2D Daten) andererseits nicht gebührend
berücksichtigt. Zwar übersteigt das Volumen der
3D Daten das Volumen der 2D Daten wesentlich, doch interagiert der
Benutzer mit 2D Applikationen typischerweise sehr viel mehr als
mit 3D Applikationen, wie im Folgenden tabellarisch zusammengefasst
ist:
| | 2D-Applikation | 3D-Applikation |
| Hohe
interaktive Leistung | Ja | Nein |
| Große
Datenvolumina | Nein | Ja |
Tabelle
1: Unterschiede zwischen 2D und 3D Applikationen
-
Basierend
auf der vorstehend erläuterten Erkenntnis wird nach dem
erfindungsgemäßen Verfahren diejenige Applikation,
welche die größere Datenmenge zu verarbeiten hat,
das heißt insbesondere die 3D Applikation, zu einem geringeren
Anteil lokal abgearbeitet als diejenige Applikation, welche zur
Verarbeitung vergleichsweise kleiner Datenvolumina, insbesondere
zur Verarbeitung von 2D Daten, vorgesehen ist. In bevorzugter Ausgestaltung
werden sämtliche Schichten der 2D Applikation lokal ausgeführt,
während zumindest ein Teil der Schichten der 3D Applikation
zentral ausgeführt wird.
-
Die
3D Daten werden vorzugsweise nicht komprimiert verarbeitet, während
die 2D Daten bevorzugt komprimiert, beispiels weise um den Faktor
zehn, verarbeitet werden. Typischerweise handelt es sich bei den 2D
Daten um Datenmengen von einigen Megabyte und bei den 3D Daten um
mehrere Gigabyte.
-
Jede
Applikation umfasst in bevorzugter Ausgestaltung eine Präsentationsschicht,
eine Geschäftsprozess-Schicht und eine Controllerschicht.
Die zur Verarbeitung der kleineren Datenmenge, insbesondere der 2D
Daten, vorgesehene Applikation bildet vorzugsweise eine Rich Client
Konfiguration. Hierbei sind die Präsentationsschicht (V
= View), die Geschäftsprozess-Schicht (M = Model) und die
Controllerschicht (C = Controller) zusammen auf einem einzigen Rechner
installiert. Die zur Verarbeitung der größeren
Datenmenge, insbesondere der 3D Daten, vorgesehene Applikation bildet
vorzugsweise eine Rich Thin Client Konfiguration. Bei dieser Konfiguration
sind die Schichten V und C auf einem die Applikation ausführenden,
lokalen Rechner installiert, während die Schicht M zentral,
das heißt auf einem entfernten Rechner, installiert ist.
-
Das
zur Durchführung des Verfahrens ausgebildete Datenverarbeitungsnetzwerk
weist bevorzugt mehrere Bereiche auf, welche sich hinsichtlich der
maximalen Datenübertragungsraten voneinander unterscheiden.
Die höchste erreichbare Datenübertragungsrate
innerhalb des Datenverarbeitungsnetzwerks beträgt hierbei
vorzugsweise mindestens das 100-fache, beispielsweise das 1000-fache,
der geringsten erreichbaren Datenübertragungsrate innerhalb
des Datenverarbeitungsnetzwerks. Der Bereich mit der höchsten
erreichbaren Datenübertragungsrate stellt den zentralen
Bereich des Datenverarbeitungsnetzwerks dar; der Bereich mit der
geringsten erreichbaren Datenübertragungsrate stellt den äußersten
Bereich des Datenverarbeitungsnetzwerks dar.
-
Der
Vorteil der Erfindung liegt insbesondere darin, dass den spezifischen
Gegebenheiten der 2D- und 3D-Datenverarbeitung in der Medizintechnik
dadurch Rechnung getragen wird, dass die 2D-Datenverarbeitung zu
einem höheren Anteil auf lokalen Datenverarbeitungsgeräten
erfolgt als die 3D-Datenverarbei tung. Bevorzugt erfolgt die 2D-Datenverarbeitung
in einer Rich Client Konfiguration und die 3D-Datenverarbeitung
im selben Netzwerk in einer Rich Thin Client Konfiguration.
-
Nachfolgend
wird ein Ausführungsbeispiel der Erfindung anhand einer
Zeichnung näher erläutert. Hierin zeigen:
-
1 In
einer Symboldarstellung Grundzüge eines für verschiedene
Applikationen ausgelegten medizintechnischen Datenverarbeitungssystems,
-
2 die
Grundstruktur einer 2D Applikation, aufweisend eine Rich-Client-Struktur,
-
3 die
Grundstruktur einer 3D Applikation, aufweisend eine Rich-Thin-Client-Struktur,
-
4 eine
für die Entwicklung der Applikationen vorgesehene Programmierschnittstelle,
und
-
5 die
prinzipielle Unterteilung des Datenverarbeitungssystems in verschiedene,
sich unter anderem hinsichtlich der maximalen Datenübertragungsrate
unterscheidende Bereiche.
-
Ein
in 1 symbolhaft dargestelltes medizintechnisches
Datenverarbeitungsnetzwerk 1 umfasst als zentrale Komponente
ein Bildarchivierungs- und kommunikationssystem (PACS) 2.
Das PACS-System 2 dient der Speicherung und Verarbeitung
von zweidimensionalen und dreidimensionalen Bilddaten, welche mit
bildgebenden Diagnosegeräten 3, 4, beispielsweise
einem Röntgengerät 3 und einem Computertomographen 4, gewonnen
wurden. Ebenso können beispielsweise ein Magnetresonanzgerät,
ein Angiographiegerät oder ein digitales Ultraschallgerät
datentechnisch mit dem ein zentrales Archiv bildenden PACS 2 und
damit mit dem Datenverarbeitungsnetzwerk 1 verknüpft
sein. Die Anzahl der in das Datenverarbeitungsnetzwerk 1 eingebun denen
oder mit diesem verknüpften Diagnosegeräte 3, 4 unterliegt
keiner Beschränkung.
-
Auf
die im PACS-System 2 gespeicherten 2D und 3D Bilddaten
greifen zwei Applikationen A1, A2 zu, wobei die Applikation A1 zur
Verarbeitung zweidimensionaler Bilddaten (2D Daten) und die Applikation
A2 zur Verarbeitung dreidimensionaler Bilddaten (3D Daten) vorgesehen
ist. Jede Applikation A1, A2 weist ein Frontend FE und ein Backend
BE auf. Im Fall der 2D Applikation A1 sind Frontend FE und Backend
BE in einen gemeinsamen Container CO, auch als generischer Behälter
bezeichnet, geladen. Im Unterschied hierzu sind bei der 3D Applikation
A2 für das Frontend FE und das Backend BE gesonderte Container
CO vorgesehen. Diese unterschiedlichen Konfigurationen sind in den 2 und 3 verfeinert
dargestellt:
Sowohl die Applikation A1 als auch die Applikation
A2 umfasst drei Schichten, nämlich eine Präsentationsschicht
V (View), eine Geschäftsprozess-Schicht M (Model) und eine
Controllerschicht C (Control), und bildet damit ein so genanntes
MVC Pattern. Die Schicht V umfasst die Präsentationslogik
der Applikation A1, A2, unter anderem Buttons, Auswahlboxen und
Bildsegmente. Die Schicht M, das heißt das Model, hat die
Geschäftsprozesslogik der Applikation A1, A2 einschließlich
laden, modifizieren und speichern von Daten zum Gegenstand. Die
Schicht C, das heißt der Controller, ist dafür
ausgebildet, im View entstandene Benutzeraktionen, beispielsweise
das Anklicken eines Buttons, zu erfassen und an das Model zur weiteren
Verarbeitung zu übertragen. Insgesamt ist damit eine Entkopplung
gegeben, welche sicherstellt, dass die Entwicklung der Geschäftsprozesslogik
unabhängig von der Präsentationslogik ist und
verschiedene Darstellungsarten (Views) mit derselben Geschäftsprozesslogik
(Model) kombinierbar sind.
-
Sämtliche
Schichten M, V, C der zur Verarbeitung zweidimensionaler Daten vorgesehenen
Applikation A1 werden auf einer einzigen, lokalen Datenverarbeitungseinheit 5,
allgemein als Hardwareressource bezeichnet, ausgeführt.
Diese Konfiguration wird als Rich Client RC bezeichnet.
-
Die
zur Verarbeitung dreidimensionaler Daten vorgesehene Applikation
A2 ist folgendermaßen auf mehrere Hardwareressourcen 6, 7 verteilt:
Die Schichten V, C werden auf einer ersten physikalischen Maschine,
einer lokalen Datenverarbeitungseinheit 6, ausgeführt,
während das Model M als dritte, für die eigentliche Bilddatenverarbeitung
zuständige Schicht auf einer entfernten, zentralen Datenverarbeitungseinheit 7 installiert
ist. Diese Konfiguration wird als Rich Thin Client RTC bezeichnet.
-
Der
Präsentationsschicht V nach den
3 und
4 entspricht
das Frontend FE nach
1. Folgendes ist ein Beispiel
einer Frontendkonfiguration:
-
Der
Geschäftsprozess-Schicht M nach den
3 und
4 entspricht
das Backend BE nach
1. Der in
1 nicht
gesondert dargestellte Controller C ist durch eine spezielle konfigurierbare
Kommunikationskomponente realisiert. Folgendes ist ein Beispiel
einer Backendkonfiguration:
-
In
dieser Konfiguration ist insbesondere auf die jeweils fünfte
Zeile („<ChannelName...”)
hinzuweisen, welche hinsichtlich der Flexibilität der Kommunikation
von besonderer Bedeutung ist: Es werden abstrakte string-basierte
Kommunikationskanäle definiert, über die die Zuordnung
eines Frontends FE und Backends BE zu einer Applikation A1, A2 erfolgt.
Lediglich Kanalnamen werden von den Entwicklern der Applikationen
A1, A2 verwendet. Diese Abstraktion stellt sicher, dass der Code
der Applikationen A1, A2 unabhängig vom physikalischen
Deployment ihrer Schichten M, V, C, das heißt von der Software-Verteilung
innerhalb des Datenverarbeitungsnetzwerks 1, verwendbar
ist. Damit sind gute Voraussetzungen für eine besonders
schnelle Applikationsentwicklung gegeben.
-
Die 4 zeigt
beispielhaft von Applikationsentwicklern verwendbare Programmierschnittstellen
(API, Applikation Programming Interface). Durch die Definition bestimmter
Kommunikationsschnittstellen ist es möglich, erst nach
der Entwicklung der Applikationen A1, A2, gegebenenfalls auch beliebiger
weiterer Applikationen, über die Verteilung der Schichten
M, V, C auf einzelne Hardwareressourcen 5, 6, 7 zu
entscheiden. Die Bedeutung der einzelnen Zeilen in 4 ergibt
sich aus nachfolgender Legende:
-
- 101
- ICommunication
(from syngo. Common. Core)
- 102
- CommandPattern:string
EventPattern:string
- 103
- sendEvent
(string)
- 104
- <<event>>ATEvent
- 201
- ICommunicationClient
(from syngo. Common. Core)
- 202
- Execute
()
InitClientCommandChannel()
- 203
- <<event>>CommandReply
<<event>>ServerConnection
LostEvent
- 301
- ICommunicationServer
(from syngo. Common. Core)
- 302
- ExeptionHandler:CommandExeptionHookCallback
- 303
- InitCommandExecuteHandler()
RegisterExecutionCallback()
RegisterTypedExecutionCallback()
UnRegisterExecutionCallback()
UnRegisterTypedExecutionCallback()
- 304
- <<event>>ClientConnectionLostEvent
<<event>>CommandExecute
-
Eine
besondere Rolle bei der Verteilung der Schichten M, V, C der verschiedenen
Applikationen A1, A2 auf die Hardwareressourcen 5, 6, 7 spielen
die im Datenverarbeitungsnetzwerk 1 gegebenen, nicht einheitlichen
Datenübertragungsraten. Die Anzahl der verfügbaren
Datenverarbeitungseinheiten ist tatsächlich wesentlich
größer als nach den stark vereinfachten 1 bis 3.
Die Struktur des Datenverarbeitungsnetzwerks 1 ist, wie
in 5 wiedergegeben, als Schalenmodell mit ineinander
geschachtelten Bereichen B1 ... B5 beschreibbar.
-
Die
in
5 symbolisch dargestellten Bereiche B1 ... B5
weisen folgende Eigenschaften auf:
| Bereich | Art
der Bilddaten | Datenübertragungsrate |
| B1
(„Modalitäten”) | 3D | 1000
MBit/s |
| B2
(„Radiologie”) | 3D | 100
MBit/s |
| B3
(„Bild-Center”) | 3D | 10
MBit/s |
| B4
(„Kliniker”) | 2D | 1
MBit/s |
| B5
(„Home Office”) | 2D | 1
MBit/s |
Tabelle
2: Bereiche des Datenverarbeitungsnetzwerks
-
Die
zur Gewinnung von Bilddaten vorgesehenen Diagnosegeräte 3, 4,
auch als Modalitäten bezeichnet, befinden sich im zentralen
Bereich B1 des Datenverarbeitungsnetzwerks 1. In diesem
Bereich arbeitet, im Vergleich zur Gesamtzahl der das PACS 2 nutzenden
Personen, eine relativ geringe Anzahl an Personen. Im Bereich B1
wird mit 3D Viewing Applikationen, wie der Applikation A2, gearbeitet.
Zu diesem Zweck steht eine ausreichende Netzwerkbandbreite von 1000
MBit/s zur Verfügung. Die im Bereich B1 zu verarbeitenden
3D Daten haben typischerweise Größen im Gigabyte-Bereich.
-
Ebenso
wie der zentrale Bereich B1 sind auch die beiden nächstäußeren
Bereiche B2, B3 zur Verarbeitung von 3D Daten vorgesehen. Die Netzwerkbandbreite
ist gegenüber dem nächst inneren Bereich B1, B2 in
diesen Bereichen B2, B3 jeweils um den Faktor 10 herabgesetzt. Die
beiden äußersten Bereiche B4, B5 schließlich
weisen eine einheitliche Netzwerkbandbreite von 1 MBit/s auf. In
diesen Bereichen ist im Vergleich zu den inneren Bereichen B1, B2,
B3 eine höhere Anzahl an Personen tätig, jedoch
ist ausschließlich die Verarbeitung von 2D Daten vorgesehen.
Gerade bei der Verarbeitung von 2D Daten treten jedoch, wie oben
bereits ausgeführt, besonders häufig Benutzerinteraktionen
auf, welche das Datenverarbeitungsnetzwerk 1 belasten.
Diesem Umstand wird dadurch Rechnung getragen, dass die 2D Applikation
A1 als Rich Client implementiert ist, während die 3D Applikation
A2 als Rich Thin Client implementiert ist. Im Vergleich zu Systemen, bei
denen 2D und 3D Daten einheitlich entweder mittels Rich Client oder
mittels Rich Thin Client verarbeitet werden, bedeutet dies für
die Benutzer des Datenverarbeitungsnetzwerks 1 eine erhebliche
Zeitersparnis.
-
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 102006051189
A1 [0002, 0003]
- - DE 19625841 A1 [0004]
- - DE 102005010405 A1 [0004]
- - DE 102006033861 A1 [0005, 0005, 0005]
