DE10154740A1 - Medizinische Systemarchitektur mit einem integrierten RIS-Client auf dem Konsolenrechner einer Modalität - Google Patents

Abstract

Die Erfindung betrifft eine medizinische Systemarchitektur mit einer Modalität (1 bis 4) zur Erfassung von Untersuchungs-Bildern, mit einer der jeweiligen Modalität (1 bis 4) zugeordneten Vorrichtung (5 bis 8) zur Verarbeitung der Untersuchungs-Bilder, mit einer Vorrichtung (9) zur Übertragung von Daten und der Untersuchungs-Bilder und mit einer Vorrichtung (10) zur Speicherung der Daten und Untersuchungs-Bilder, wobei die Vorrichtungen (5 bis 8) zur Verarbeitung der Untersuchungs-Bilder als RIS-Client zum Austausch von Textnachrichten, sowie zur Anzeige eines RIS-Client-Fensters und für den Aufbau von RIS-Interaktions-Masken ausgebildet und über einen Netzwerkanschluss (16) der Vorrichtungen (5 bis 8) mit einem RIS-Server (14) zur Kommunikation mit dem RIS-Client (26) auf den Vorrichtungen (5 bis 8) verbunden sind.

Description

Die Erfindung betrifft eine medizinische Systemarchitektur mit einer Modalität zur Erfassung von Untersuchungs-Bildern, mit einer der jeweiligen Modalität zugeordneten Vorrichtung zur Verarbeitung der Untersuchungs-Bilder, mit einer Vorrich­ tung zur Übertragung von Daten und der Untersuchungs-Bilder und mit einer Vorrichtung zur Speicherung der Daten und Un­ tersuchungs-Bilder.

Aus dem Buch "Bildgebende Systeme für die medizinische Dia­ gnostik", herausgegeben von H. Morneburg, 3. Auflage, 1995, Seiten 684ff sind medizinische Systemarchitekturen, sogenann­ te PACS (Picture Archival and Communication Systeme), be­ kannt, bei denen zum Abruf von Patientendaten und durch Moda­ litäten erzeugte Bilder Bildbetrachtungs- und Bildbearbei­ tungsplätze, sogenannte Workstations, über ein Bildkommunika­ tionsnetz miteinander verbunden sind.

Die Client-Software eines Radiologie-Informationssystems (RIS) ist das Bedien-Interface für Medizinisch-Technische Ra­ diologieassistenten (MTRA) und Ärzte in der Radiologie, um beispielsweise Patienten aufzunehmen, die Untersuchungen zu planen und zu terminieren, die Befunde zu verwalten und Ab­ rechnungen einzuleiten, Je nach Einbettung in das übergeord­ nete Krankenhausinformationssystem (KIS) können manche dieser Vorgänge bereits dort erfolgen wie beispielsweise die Patien­ tenaufnahme, Leistungsanforderung und Abrechnung, wobei das RIS die an diese Vorgänge gekoppelten Daten über eine Netz­ werkschnittstelle nur noch übernimmt.

Zusätzlich zu diesen "Verwaltungstätigkeiten" agiert das RIS oft noch als Workflow-Treiber in der Radiologie, um bei­ spielsweise Anforderungsdaten in Form eines DICOM-Worklist- Eintrags zu einer Modalität wie CT-, MR- oder Röntgengerät zu schicken, an der die Untersuchung stattfinden soll. Bei den heutigen Systemen müssen zur notwendigen Übernahme der Unter­ suchungsdaten, beispielsweise Anzahl der Bilder, Serien und Strahlenschutzdaten wie Röhrenspannung (kV), mAs-Produkt (mAs), Zeit (s), Energiedosis (Gy), etc., von der Modalität in das RIS zur Dokumentation und Abrechnung diese Daten manu­ ell von einer Arbeitskraft abgelesen und in das RIS übertra­ gen werden, wodurch sich ein erheblicher Aufwand und zusätz­ liche Fehlerquellen ergeben.

Wird zusätzlich eine PACS-Lösung benutzt, dann stellt das RIS weitere Workflow-Treiber-Funktionen bereit, beispielsweise um Altbilder und -befunde eines Patienten automatisch aus dem Archiv auf eine Befundungsworkstation zu laden, das sogenann­ te Pre-Fetching, oder nach dem sogenannten Auto-Routing aus­ gesuchte Bilder und Befunde an die anfordernden klinischen Abteilungen automatisch zurückzuschicken.

Die Bedienung des RIS erfolgt dabei über spezielle Client- Terminals, früher einfache ASCII-Terminals, heute in der Re­ gel handelsübliche PCs. Das heißt insbesondere, dass sich ne­ ben jedem Konsolenrechner einer Modalität und neben jeder PACS-Befundungs-Workstation üblicherweise ein extra Personal- Computer (PC) mit eigener Tastatur als RIS-Client befindet. Der Bediener, beispielsweise MTRA oder Arzt, muss dabei per­ manent zwischen den verschiedenen Rechnern und Tastaturen hin- und her wechseln. Oft muß der Bediener auch doppelte Eingaben derselben Daten vornehmen, nämlich an den Konsolen­ rechnern der Modalität wie auch an den Terminals des RIS- Clients. Dies gilt besonders für alle Daten, die nicht stan­ dardisiert über die DICOM-Worklist ausgetauscht werden kön­ nen, beispielsweise Mengenangaben von Verbrauchsmitteln oder spezielle Arbeitsschritte, die später in der Abrechnung rele­ vant sind:

Bisher konnte durch mehrere verteilte Rechner, beispielsweise die Konsolenrechner der Modalität und daneben aufgestellten PCs mit dem RIS-Client, zwar die radiologische Leistung er­ bracht werden, aber die Bedienung wies nur einen geringen Be­ dienungskomfort für MTRAs und Ärzte im Hinblick auf die Mög­ lichkeiten der Steuerung und Optimierung der Abteilungsres­ sourcen (Utilization Management) und auf den möglichen Auto­ matisierungsgrad der Informationsflüsse.

In der DE 196 25 835 A1 ist eine medizinische Systemarchitek­ tur der eingangs genannten Art beschrieben, bei der einem Verfahren zum Datenaustausch zwischen verschiedenen Anwen­ dungsprogrammen ein WWW-Erweiterungstyp (MIME) für Bilder, Videos oder ein Viewer von Objekten des Industriestandards im WWW-Browser zugeordnet ist. Weiterhin wird der Umfang der MIME-Erweiterung als DICOM-Bilder, Videos und Objekte defi­ niert. Dabei wird von einem Austausch der Nachrichten mittels DICOM über das Netzwerk-Interface ausgegangen.

Die US 5,654,555 betrifft ein System zur Übertragung von Röntgenbildern über ein Netzwerk zu einer örtlich entfernten Vorrichtung mit physikalischen Netzwerkverbindungen sowie Transportprotokollen und medizinischen Protokolle, wobei Pa­ tienten-Untersuchungsdaten von einem RIS abgefragt werden können.

Aus der US 6,011,552 ist ein verschiebbares Menu Icon zum Zugriff auf eine Applikation in einem graphischen User-Inter­ face (UI) bekannt, bei dem Windows und Icons übersichtlich übereinander bzw. nebeneinander auf dem Bildschirm arrangiert werden, speziell wenn eines der Windows Zugang zu einer Vide­ oconferencing-Session bietet.

Die Erfindung geht von der Aufgabe aus, die angesprochenen Schwächen des heute üblichen Konzepts von speziellen RIS- Clients zu beseitigen, durch die das Bedienpersonal zwischen "Client-Terminal" und Konsolenrechnern der Modalitäten wech­ seln muss, den Bedienkomfort zu erhöhen, die Steuerung und Optimierung der Abteilungsressourcen (Utilization Management) zu ermöglichen und die erforderlichen Informationsflüsse zu automatisieren.

Die Aufgabe wird erfindungsgemäß dadurch gelöst, dass die Vorrichtungen zur Verarbeitung der Untersuchungs-Bilder als RIS-Client zum Austausch von Textnachrichten sowie zur An­ zeige eines RIS-Client-Fensters und für den Aufbau von RIS- Interaktions-Masken ausgebildet und über einen Netzwerkan­ schluss der Vorrichtungen mit einem RIS-Server zur Kommunika­ tion mit dem RIS-Client auf den Vorrichtungen verbunden sind.

Die vorliegende Erfindung beschreibt die Innovation, wie der RIS-Server mit dem RIS-Client auf der Modalität kommuniziert, wobei der RIS-Client aber Desktop-integriert auf der Bedie­ nerkonsole der Modalitäten zur Verfügung gestellt wird; dies erfolgt zusätzlich zu der bekannten DICOM-Kommunikation. Ein Netzwerk-Interface kann dazu benutzt werden (Netzwerkkarte mit TCP/IP-Adresse), oder ein zweites Interface kann einge­ baut werden. Die vorliegende Erfindung betrifft keine blosse RIS-Kopplung gemäß dem Stand der Technik, sondern spezifi­ ziert insbesondere die Desktop-Integration des RIS-Clients auf einer Modalität.

Durch die Realisierung des RIS-Clients auf beliebigen Konso­ lenrechnern beispielsweise als RIS-Fenster kann die RIS-Funk­ tion von derselben Tastatur ohne "Ortswechsel" bedient wer­ den; dies ist ein wesentlicher Vorteil der Desktop-Integra­ tion. Zusätzlich können nützliche neue Applikationen auf den Konsolenrechnern der Modalitäten verfügbar gemacht werden, insbesondere in Richtung Utilization Management, also die bessere Planung, Überwachung und Optimierung der Auslastung der Modalitäten und aller beteiligten Ressourcen wie Perso­ nal, Verbrauchsmittel, Zeit und sonstige Kostenfaktoren. Ein weiterer Vorteil ist die Verfügbarmachung der Funktionen des RIS auf den Modalitäten, was zur verbesserten Automatisierung des Informationsflusses und damit zur Beschleunigung der Pro­ zessabläufe in der diagnostischen Radiologie führen wird. Au­ ßerdem kann eine notwendige automatische Übernahme der Unter­ suchungsdaten, beispielsweise Anzahl der Studien, Bilder, Se­ rien, Art der Sequenzen und Strahlenschutzdaten wie Röhren­ spannung (kV), mAs-Produkt (mAs), Zeit (s), Energiedosis (Gy), etc., von der Modalität in das RIS zur Dokumentation und Abrechnung erfolgen. Aus dem Untersuchungsprotokoll kann auch eine Vorgabe bezüglich des verwendeten Verbrauchsmateri­ als vorgegeben werden, welche nur bestätigt werden muss und bei Bedarf korrigierbar ist.

Durch den integrierten RIS-Client auf einem Konsolenrechner einer Modalität vereinfacht sich somit die Bedienung, ver­ bessern sich die Workflow-Eigenschaften und erweitern sich die Utilization Management-Funktionalitäten.

Die beschriebenen Probleme lassen sich besonders einfach da­ durch lösen, dass die Vorrichtungen zur Verarbeitung der Un­ tersuchungs-Bilder eine RIS-Client-Software aufweisen, wobei die RIS-Client-Software in die Software und gleichzeitig in die Benutzeroberfläche der Vorrichtungen durch sogenannte Desktop Integration von radiologischen Modalitäten integriert sein kann.

Besonders günstig ist die Integration der RIS-Client-Software in eine Plattform-Software, da dann die Möglichkeiten der RIS-Client-Software für alle Modalitäten, die diese Platt­ form-Software nutzen, auf einfache Weise bereitgestellt wer­ den können.

Bei Vorrichtungen zur Verarbeitung der Untersuchungs-Bilder mit Monitoren hat es sich als zweckmäßig erwiesen, wenn auf der Benutzeroberfläche neben den Untersuchungs-Bildern im Bildbearbeitungsfenster ein Fenster mit dem RIS-Client auf den jeweiligen Monitoren einblendbar ist.

In vorteilhafter Weise können die Vorrichtungen derart ausge­ bildet sein, dass auf der Benutzeroberfläche ein Icon ange­ ordnet ist, durch das sich das Fenster mit dem RIS-Client öffnen lässt.

Der RIS-Client wird auf einfache Weise und schnell auf der Benutzeroberfläche wiedergegeben, wenn die Vorrichtungen der­ art ausgebildet sind, dass auf der Benutzeroberfläche das Fenster mit dem RIS-Client als eigene Task-Card realisiert ist, so dass der Benutzer lediglich auf den RIS-Karteikarten­ reiter am rechten Bildschirmrand klicken muss.

Der Gebrauchswert der erfindungsgemäßen Vorrichtungen lässt sich erhöhen, wenn der Workflow von dem RTS-Client zur auto­ matischen Informationsübermittlung gesteuert wird.

Analysen über die Häufigkeit, bei welchen klinischen Frage­ stellungen welche Effekte auf die Diagnosegüte oder die dar­ aus resultierende Therapieentscheidung durch die Untersuchung verursacht werden, können erreicht werden, wenn der RIS- Client auf dem Konsolenrechner einer Modalität Daten zu Out­ come-Analysen liefert.

Eine bessere Planung, Überwachung und Optimierung der Auslas­ tung der Modalitäten und aller beteiligten Ressourcen lässt sich erreichen, wenn der RIS-Client einen Statistik-Modul für Auswertungen von gesammelten Daten aufweist.

Die Erfindung ist nachfolgend anhand von in der Zeichnung dargestellten Ausführungsbeispielen näher erläutert. Es zei­ gen:

Fig. 1 ein Beispiel einer Systemarchitektur eines Kranken­ hausnetzes,

Fig. 2 eine schematische Darstellung eines Monitors der Systemarchitektur mit einer erfindungsgemäßen Be­ nutzeroberfläche, beispielsweise eines CT mit in­ tegriertem RIS-Client,

Fig. 3 eine weitere Ausführung einer erfindungsgemäßen Be­ nutzeroberfläche,

Fig. 4 ein Workflow-Szenario einer erfindungsgemäßen Vor­ richtung und

Fig. 5 Erläuterungen zur Kommunikation des RIS-Servers mit dem RIS-Client.

In der Fig. 1 ist beispielhaft die Systemarchitektur eines Krankenhausnetzes dargestellt. Zur Erfassung medizinischer Bilder dienen die Modalitäten 1 bis 4, die als bilderzeugende Systeme beispielsweise eine CT-Einheit 1 für Computertomogra­ phie, eine MR-Einheit 2 für Magnetische Resonanz, eine DSA- Einheit 3 für digitale Subtraktionsangiographie und eine Röntgeneinheit 4 für die digitale Radiographie 4 aufweisen kann. An diese Modalitäten 1 bis 4 sind Bedienerkonsolen 5 bis 8 der Modalitäten oder Workstations angeschlossen, mit denen die erfassten medizinischen Bilder verarbeitet und lo­ kal abgespeichert werden können. Auch lassen sich zu den Bil­ dern gehörende Patientendaten eingeben.

Die Bedienerkonsolen 5 bis 8 sind mit einem Kommunikations­ netz 9 als LAN/WAN Backbone zur Verteilung der erzeugten Bil­ der und Kommunikation verbunden. So können beispielsweise die in den Modalitäten 1 bis 4 erzeugten Bilder und die in den Bedienerkonsolen 5 bis 8 weiter verarbeiteten Bilder in zent­ ralen Bildspeicher- und Bildarchivierungssystemen 10 abge­ speichert oder an andere Workstations weitergeleitet werden.

An dem Kommunikationsnetz 9 sind weitere Viewing-Workstations 11 als Befundungskonsolen angeschlossen, die lokale Bildspei­ cher aufweisen. Eine derartige Viewing-Workstation 11 ist beispielsweise ein sehr schneller Kleincomputer auf der Basis eines oder mehrerer schneller Prozessoren. In den Viewing- Workstations 11 können die erfassten und im Bildarchivie­ rungssystem 10 abgelegten Bilder nachträglich zur Befundung abgerufen und in dem lokalen Bildspeicher abgelegt werden, von dem sie unmittelbar der an der Viewing-Workstation 11 ar­ beitenden Befundungsperson zur Verfügung stehen können.

Weiterhin sind an dem Kommunikationsnetz 9 Server 12, bei­ spielsweise Patientendaten-Server (PDS), Fileserver, Pro­ gramm-Server und/oder EPR-Server angeschlossen.

Der Bild- und Datenaustausch über das Kommunikationsnetz 9 erfolgt dabei nach dem DICOM-Standard, einem Industriestan­ dard zur Übertragung von Bildern und weiteren medizinischen Informationen zwischen Computern, damit eine digitale Kommu­ nikation zwischen Diagnose- und Therapiegeräten unterschied­ licher Hersteller möglich ist. An dem Kommunikationsnetz 9 kann ein Netzwerk-Interface 13 angeschlossen sein, über das das interne Kommunikationsnetz 9 mit einem globalen Daten­ netz, beispielsweise dem World Wide Web verbunden ist, so dass die standardisierten Daten mit unterschiedlichen Netz­ werken weltweit ausgetauscht werden können.

Erfindungsgemäß ist an dem Kommunikationsnetz 9 ein RIS-Ser­ ver 14 angeschlossen, mit dem die Bedienerkonsolen 5 bis 8 mittels des Kommunikationsnetzes 9 über TCP/IP-Protokolle kommunizieren.

In der Fig. 2 ist ein Monitor 15 eines Konsolen- oder Zweit­ konsolenrechners, beispielsweise der Bedienerkonsole 5 der CT-Einheit 1 dargestellt. Über einen Netzwerkanschluss 16 der Bedienerkonsole 5 ist der RIS-Client mit dem RIS-Server 14 verbunden, kann aber auch über TCP/IP-Protokoll mit ande­ ren DICOM und/oder HL7 standardisierten RIS-, KIS- und PACS- Servern 12 über das interne Kommunikationsnetz 9 kommunizie­ ren, beispielsweise einem KIS-Server für das Krankenhausin­ formationssystem, einem EPR-Server, oder verschiedenen PACS- Servern wie Befundungskonsolen, Bildarchiv, Web-Bildvertei­ lungsserver, usw. Dabei benutzt der RIS-Client Standard-An­ wendunsprotokolle wie DICOM, HL7, aber auch http, um Inter­ net-/Intranet-Server zu erreichen.

Auf der Benutzeroberfläche 17 des Monitor 15 ist ein Bildbe­ arbeitungsfenster 18, beispielsweise die "Examination Task- Card", mit mehreren nebeneinanderliegenden CT-Aufnahmen wie­ dergegeben, neben denen in bekannter Weise Icons 19 zum Aus­ lösen von Befehlen angeordnet sind.

Derartige Task-Cards sind aus der WO 00/31673 bekannt, durch die in einfacher und schneller Weise Benutzeraufträge oder Tasks, die als eine Aktivität eines Workflows zu betrachten sind und insbesondere bei der Bildnachbearbeitung und Befun­ dung bei allen bildgebenden Verfahren der Medizintechnik in vorteilhafter Weise einsetzbar sind, ausgewählt werden kön­ nen, wobei mehrere Tasks oder Aktivitäten, parallel verarbei­ tet und beliebig aufgerufen werden können. Dabei ist die Be­ nutzeroberfläche in Bereiche unterteilt, wobei in einem Steu­ erbereich Einblendungen mit Informationen des Benutzerauftra­ ges erfolgen, am Rande der Benutzeroberfläche Felder in der Art von Kartenreitern 23 angeordnet sind, denen jeweils ein anderer Benutzerauftrag zugeordnet ist, und der derzeit auf­ gerufene, aktuelle, sichtbare Benutzerauftrag auf dem Karten­ reiter 23 erkennbar markiert ist. Die am Rande angeordneten Kartenreiter 23 nach diesem Task-Card-Konzept sorgen für eine klare Einteilung. Damit wird ein medizinischer Workflow rea­ lisiert.

Sollen nun Eingaben von der CT-Bedienerkonsole 5 als RIS- Client in den RIS-Server 14 gemacht oder Daten aus dem RIS- Server 14 in den RIS-Client, die Bedienerkonsole 5 der CT- Einheit 1, übertragen werden, so wird durch Klicken mit der Maus auf ein RIS-Icon 20 ein RIS-Client-Fenster 21 auf dem Monitor 15 geöffnet, beispielsweise die Bildschirmmaske für Patientenregistrierung. Alle RIS-Eingaben von MTRA oder Arzt erfolgen nun über die Tastatur des Konsolenrechners, ohne dass der Bediener zu einem extra RIS-Client-Terminal gehen muss. Auch kann er problemlos zwischen dem Bildbearbeitungs­ fenster 18 und dem RIS-Client-Fenster 21 wechseln.

In Fig. 3 ist eine alternative Lösung der Desktop-Integra­ tion dargestellt, bei der der RIS-Client als eigene Task-Card 22 realisiert ist. Hier erscheint die Benutzeroberfläche des RIS-Client, wenn der Benutzer auf den RIS-Karteikartenreiter 24 am rechten Bildschirmrand klickt, so dass sich wieder das aus Fig. 2 bekannte RIS-Client-Fenster 21 für Patientenre­ gistrierung als Task-Card 22 öffnet. Die Arbeit mit dem RIS- Client erfolgt danach genauso wie im Fall der Lösung in Fig. 2.

In der Fig. 4 ist ein mögliches Workflow-Szenario einer er­ findungsgemäßen Vorrichtung wiedergegeben. Sie beschreibt den klinischen Arbeitsfluss mit den verschiedenen Arbeitsschritten und den Einsatz der Softwarepakete der verschiedenen Systeme, wie beispielsweise das RIS oder die Modalität. Auf der linken Seite ist die verwendete Applikationssoftware, das jeweilige Softwarepaket/-funktion der verschiedenen Systeme in der Rei­ henfolge des klinischen Arbeitsflusses, und auf der rechten Seite der Datenfluss dargestellt. Der Datenfluss ist eine Auflistung der Daten, die während der verschiedenen Arbeits­ schritte von den Softwarepaketen eingesetzt werden.

Zuerst wird die jeweilige Applikationssoftware der verschie­ denen Systeme in der Reihenfolge des klinischen Arbeitsflus­ ses beschrieben (linke Spalte):

• a) Durch das RIS erfolgt zuerst die Patientenregistrierung und die Patientendaten werden automatisch in die DICOM- Worklist übernommen.
• b) In der Modalität werden diese Patientendaten, nach Emp­ fang der DICOM-Worklist, über diese Worklist übertragen. Bei der Anwahl eines Patienten werden die Daten und das Untersuchungsprogramm entsprechend der Fragestellung ge­ laden und die Untersuchung gestartet.
• c) Es erfolgt die Untersuchung durch die Modalität.
• d) Nach dem Untersuchungsende erfolgt über DICOM die Über­ gabe der Untersuchungsdaten an das RIS. Hier erfolgt die Bestätigung und Dokumentation der Untersuchung.
• e) Als nächstes werden die Daten zur Abrechnung an das KIS weitergeleitet.
• f) Die Untersuchungsdaten gehen von der Modalität zur wei­ teren Befundung beispielsweise an eine Workstation.

Jetzt wird der von den Softwarepaketen eingesetzte Datenfluss der verschiedenen Arbeitsschritte in der Reihenfolge des kli­ nischen Arbeitsflusses beschrieben (rechte Spalte):

• a) Die Patientenstammdaten und Untersuchungsanforderung werden erfasst oder aufgerufen.
• b) Die Untersuchungsangaben werden eingegeben.
• c) Während der Untersuchung werden die Aufnahmedaten und das Verbrauchsmaterials erfasst, beispielsweise Studien-, Serien- und Bildanzahl, Art der Sequenzen, Strahlenschutzdaten (kV, mAs, sec., Gy).
• d) Die Daten werden vom RIS übernommen.

Die Vereinfachung der Bedienung auf einem einzigen Rechner mit einer einzigen Tastatur ist der unmittelbar sichtbare und sofort bereitstellbare Nutzen für MTRAs und Ärzte, der aus der Desktop-Integration des RIS-Clients auf dem Konsolenrech­ ner einer Modalität folgt.

Ein weiterer Vorteil für die Effizienz der Arbeit in der dia­ gnostischen Radiologie ist die Möglichkeit von Workflow-Steu­ erungen aus dem RIS auf den Konsolen der Modalitäten, wie beispielsweise die "prefetching"- und "autorouting"-Funktionen zur automatischen Informationsübermittlung. Heute kann auf einer Modalität nur genau ein Zielknoten für die Weiterlei­ tung einer Patientenbildstudie vordefiniert werden, oder es muss jedesmal "von Hand" ein neuer Zielknoten eingegeben wer­ den; dies lässt sich über den RIS-Client dynamisieren, also automatisch die Weiterleitung der Studien ermöglichen, wobei sich das Ziel beispielsweise aus der Auswertung der Parameter für untersuchtes Organ, anfordernde Stelle, Information über Vorbefunde, usw. ergibt.

Zusätzlicher Nutzen aus der Integration des RIS-Clients auf dem Konsolenrechner einer Modalität kommt zum Tragen, wenn die RIS-Schnittstelle zur besseren Planung, Überwachung und Optimierung der Auslastung der Modalitäten und aller betei­ ligten Ressourcen wie Personal, Verbrauchsmittel, Zeit und sonstige Kostenfaktoren eingesetzt wird, also zum sogenannten "Utilization Management". Jedes RIS besitzt auch ein soge­ nanntes "Statistik-Modul", in dem der Arzt beliebige Auswer­ tungen der gesammelten Daten vornehmen kann, beispielsweise Anzahl der verschiedenen Untersuchungen, durchschnittliche Untersuchungsdauer, durchschnittlich verwendete Verbrauchsma­ terialien wie Filme, Kontrastmittel, Nuklide und vieles mehr. Dieses Statistik-Modul ist der Ausgangspunkt für jedes Utili­ zation Management und kann nun auch auf den Konsolenrechnern der Modalitäten eingesetzt werden, beispielsweise zur Proto­ kollierung und Auswertung, welche verschiedenen Sequenzen auf einem MR in einer bestimmten Periode angewendet wurden, oder welche Einstellungen wie Vorschub, Schichtdicke, etc., wie oft bei einem Mehrschicht-CT gewählt wurden, und welche Aus­ wirkungen auf Untersuchungszeiten und damit -kosten diese Einstellungen hatten.

Die Integration des RIS-Clients auf dem Konsolenrechner kann einer Modalität zusätzlich zum Ausgangspunkt für das Sammeln von Daten zu Outcome-Analysen werden. Solche Analysen können beispielsweise untersuchen, welche Sequenzen eines MR in wel­ cher Häufigkeit bei welcher klinischen Fragestellung gewählt wurden, und welchen Effekt auf die Diagnosegüte oder die dar­ aus resultierende Therapieentscheidung die Sequenzen hatten. Damit wird dann langfristig die Integration von radiologi­ schen Modalitäten in ein umfassendes "Disease Management"- Konzept ermöglicht.

Anhand der Fig. 5 wird die Kommunikation des RIS-Servers mit dem RIS-Client näher erläutert. Eine RIS-Server-Application 25 kommuniziert mit einer RIS-Client-Application 26, die auf einer Maschine 27 läuft. Auf der gleichen Maschine 27 kann auch eine Modality 28 laufen, die eine Modality-RIS-Mediator- Application 29 und Modality-Applications 30 bis 32 aufweisen kann.

Die Modality-RIS-Mediator-Application 29 fügt einen Button 33 zum Starten der RIS-Client-Application 26 in das Hauptmenu der Modalität 28 ein.

Die Modality-Applications 30 bis 32 haben einen Extension-Me­ chanismus 34 bis 36, um anderen Applications (z. B. 30 bis 32 oder 27) eine Aktivierung zu ermöglichen, und erweitert eine Modality-RIS-Mediator-Application 27 damit.

Die Modality-Applications 30 bis 32 starten eine RIS-Client- Application 26 mittels des Buttons 33 aus dem Hauptmenu der Modality 28.

Die RIS-Client-Application 26 kommuniziert beispielsweise über ein OLE-Protokoll 37 mit Modality-RIS-Mediator-Applica­ tion 29 und erfragt deren Modality-Application-Extensions 34 bis 36.

Die Modality-RIS-Mediator-Application 27 liefert Verweise auf seine aktuellen Extensions 34 bis 36 über das OLE-Protokoll 37 zurück und ein sogenanntes "Magic-Cookie" 38 bis 40 für jede Extension. Diese werden von der RIS-Client-Application 26 in dessen User Interface (UI) zur nachfolgenden Aktivie­ rung eingefügt.

Wenn aus der RIS-Client-Application 26 die UI-Aktivierung einer bestimmten Modality-Application-Extension 34 bis 36 er­ folgt, wird diese zusammen mit der im RIS-Client 26 angewähl­ ten Patienten-Information und dem "Magic-Cookie" 38 bis 40 an die Modality-RIS-Mediator-Application 29 weitergeleitet. Die­ se versucht über einen anderen Transport 41 die nötigen Bild­ daten zu besorgen und gibt sie an die jeweilige Extension 34 bis 36 weiter, die durch das "Magie Cookie" 38 bis 40 refe­ renziert sind. Die jeweilige Extension 34 bis 36 transferiert die Anforderung schließlich an die jeweilige Modality-Appli­ cation 30 bis 32.

Für die Modality-Application 30 bis 32 ist der Auftrag durch die Extensions 34 bis 36 vorbestimmt und nicht mehr unter­ scheidbar, wer letztlich die Aktivierung veranlasst hat, d. h. es ist kein spezieller Mechanismus für RIS-Client pro Appli­ cation nötig.

Die Modality-Application 30 bis 32 kann daraufhin die Bildda­ ten zur Befundung laden.

Dieses Verfahren ist dynamisch zur Laufzeit beliebig für wei­ tere Modality-Applications 30 bis 32 wiederholbar, die ebenso dynamisch aus der RIS-Client-Application 26 aktivierbar sind. Dadurch ist gewährleistet, dass neue und bestehende Applica­ tions automatisch mit der RIS-Client-Application 26 verbunden werden können und in jede Modality 28 integriert werden kön­ nen. Weiterhin können Modality-Applications 30 bis 32 und RIS-Client-Application 26 unabhängig voneinander geändert werden.

Die RIS-Client-Application 26 läuft in der Regel (keine Be­ dingung) auf der gleichen Maschine 27 wie die Modalität 28 und kommuniziert mit dem Informationssystem der RIS-Server- Application 25 über einen anderen Transportmechanismus, um die Patienteninformationen des Informationssystems mit den Modality-Applications 30 bis 32 einer Modality 37 zu verbin­ den.

Die Extensions der RIS-Client-Application 26, die "Magic- Cookie" 38 bis 40, stellen User Interface plug-ins im RIS- Client zur Verfügung, um die Modality-Applications 30 bis 32 so zu aktivieren, als wenn diese von einer anderen Modality- Application gekommen wäre. Die Modality-RIS-Mediator-Appli­ cation fungiert hier als Bindeglied zwischen RIS-Client und Modality-Application.

Die Modality-RIS-Mediator-Application ist ein Vermittler oder Bindeglied. In diesem Fall adaptiert sie zwischen Modality- Applications - über deren Extensions an den Mediator, da die­ se wie eine Modality-Application gebaut ist - und dem RIs- Client.

Anhang In der Beschreibung verwendete Abkürzungen

DICOM Digital Imaging and Communications in Medicine
DICOM-Standard ist ein Industriestandard zur Über­ tragung von Bildern und weiteren medizinischen In­ formationen zwischen Computern zur Ermöglichung der digitalen Kommunikation zwischen Diagnose- und The­ raphiegeräten unterschiedlicher Hersteller.
EPR Electronic-Patient-Record (Elektronische Patienten- Akte)
HL7 Health Level 7 - ein ANSI-zugelassener Standard der Standards Developing Organizations (SDOs)
HL7 Spezifikation ist das Anwendungsprotokoll für elektronischen Datenaustausch in medizinischer Um­ gebung
KIS Krankenhaus-Information-System:
System für allgemeines Krankenhaus-Management, mit den Hauptmerkmalen Patienten-Management, Buchhal­ tung und Rechnungswesen, Personal-Management usw.
MTRA Medizinisch-Technische(r) Radiologieassistent(in)
PACS Picture Archival and Communication-System
RIS Radiologie-Informationssystem (Radiology Informati­ on System):
Information System zum Daten-Management innerhalb der Radiologie-Abteilung, das beispielsweise den Patienten-Zugang, die Kreation von Worklisten, das Berichtswesen, Report-Management, die Buchhaltung und das Rechnungswesen usw. unterstützt.

Claims (11)

1. Medizinische Systemarchitektur mit einer Modalität (1 bis 4) zur Erfassung von Untersuchungs-Bildern, mit einer der jeweiligen Modalität (1 bis 4) zugeordneten Vorrichtung (5 bis 8) zur Verarbeitung der Untersuchungs-Bilder, mit einer Vorrichtung (9) zur Übertragung von Daten und der Untersu­ chungs-Bilder und mit einer Vorrichtung (10) zur Speicherung der Daten und Untersuchungs-Bilder, wobei die Vorrichtungen (5 bis 8) zur Verarbeitung der Untersuchungs-Bilder als RIS- Client (26) zum Austausch von Textnachrichten, sowie zur An­ zeige eines RIS-Client-Fensters (21) und für den Aufbau von RIS-Interaktions-Masken ausgebildet und über einen Netzwerk­ anschluss (16) der Vorrichtungen (5 bis 8) mit einem RIS-Ser­ ver (14) zur Kommunikation mit dem RIS-Client (26) auf den Vorrichtungen (5 bis 8) verbunden sind.

2. Medizinische Systemarchitektur nach Anspruch 1, dadurch gekennzeichnet, dass die Vorrichtungen (5 bis 8) zur Verarbeitung der Untersuchungs- Bilder eine RIS-Client-Software aufweisen.

3. Medizinische Systemarchitektur nach Anspruch 2, dadurch gekennzeichnet, dass die RIS-Client-Software in die Software der Vorrichtungen (5 bis 8) integriert ist.

4. Medizinische Systemarchitektur nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass die RIS-Client-Software in die Benutzeroberfläche (17) der Vor­ richtungen (5 bis 8) integriert ist.

5. Medizinische Systemarchitektur nach einem der Ansprüche 2 bis 4, dadurch gekennzeichnet, dass die RIS-Client-Software in eine Plattform-Software in­ tegriert ist.

6. Medizinische Systemarchitektur nach einem der Ansprüche 1 bis 5, bei der die Vorrichtungen (5 bis 8) Monitore (15) aufweisen, dadurch gekennzeichnet, dass die Vorrichtungen (5 bis 8) zur Verarbeitung der Unter­ suchungs-Bilder derart ausgebildet sind, dass auf der Benut­ zeroberfläche (17) neben den Untersuchungs-Bildern im Bildbe­ arbeitungsfenster (18) ein Fenster (21) mit dem RIS-Client auf den jeweiligen Monitoren (15) einblendbar ist.

7. Medizinische Systemarchitektur nach Anspruch 6, dadurch gekennzeichnet, dass die Vorrichtungen (5 bis 8) derart ausgebildet sind, dass auf der Benutzeroberfläche (17) ein Icon (20) angeordnet ist, durch das sich das Fenster (21) mit dem RIS-Client öffnen lässt.

8. Medizinische Systemarchitektur nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Vorrichtungen (5 bis 8) derart ausgebildet sind, dass auf der Benutzeroberfläche (17) das Fenster (21) mit dem RIS-Client als eigene Task-Card (22) realisiert ist.

9. Medizinische Systemarchitektur nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass der Workflow von dem RIS-Client zur automatischen Infor­ mationsübermittlung gesteuert wird.

10. Medizinische Systemarchitektur nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass der RIS-Client auf dem Konsolenrechner einer Modalität Daten zu Outcome-Analysen liefert.

11. Medizinische Systemarchitektur nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass der RIS-Client ein Statistik-Modul für Auswertungen von gesammelten Daten aufweist.