-
Die vorliegende Erfindung betrifft den Transfer von Bilddatensätzen einer Dual-Energy Messungen an zumindest ein Clientgerät und bezieht sich insbesondere auf Verfahren und Systeme zur Steuerung der Verarbeitung von medizinischen Bilddaten, die sich beispielsweise auf die Darstellung von Gefäßen des Kopfes beziehen können.
-
In der medizinischen Bildgebung wird heute überwiegend der DICOM Standard (Digital Imaging and Communications in Medicine – DICOM) eingesetzt. Er betrifft die digitale Bildverarbeitung und -kommunikation in der Medizin und ist ein offener Standard zur Speicherung und zum Austausch von Informationen im medizinischen Bilddatenmanagement. Diese Informationen können beispielsweise digitale Bilder, Zusatzinformationen wie Segmentierungen, Oberflächendefinitionen oder Bildregistrierungen sein. DICOM standardisiert sowohl das Format zur Speicherung der Daten, als auch das Kommunikationsprotokoll zu deren Austausch. Auf einer abstrakten Ebene ist dieses Format mit anderen Bildformaten wie JPEG o.ä. vergleichbar. Es werden die Bilddaten und deren Attribute und Metadaten (z.B.: Bildbreite, Bittiefe) abgelegt, die zur Darstellung notwendig sind oder die Informationen über die Bilderzeugung (z.B. Modalität, Scan Mode etc.) enthalten. Die Daten/Bilder enthalten selbst aber keine Algorithmen oder Programmcodes zur Darstellung der Daten.
-
Im Rahmen der Entwicklung der bildgebenden Systeme sind Verfahren erfunden worden, bei denen eine geeignete Nachverarbeitung und/oder Visualisierung eingesetzt werden muss, um die volle diagnostische Information aus den Bilddaten zu gewinnen. Beispiele hierfür sind Perfusionsmessungen, Dual Energy Verfahren, etc. Die Bilddaten werden auf einem Bildakquisitionssystem erfasst (z.B. auf einem CT-Scanner) und üblicherweise auf einem oder mehreren (anderen) Clientgerät(en) nachverarbeitet. Das Bildakquisitionssystem und das Clientgerät stehen über eine Netzwerk-Schnittstelle in Datenaustausch.
-
Geeignete Verfahren zur Verarbeitung der Bilddaten sind abhängig von den technischen Parametern und Bedingungen des jeweiligen Clientgerätes. Möchte ein Benutzer an seinem Clientgerät diese Nachverarbeitungen und Visualisierungen bei der Befundung interaktiv ändern, so ist dies bei den heute bekannten Systemen an einem generischen Befundarbeitsplatz nachteiliger Weise nicht möglich. Der Benutzer muss dann die verwendete Software und/oder den Arbeitsplatz wechseln und spezielle, häufig modalitäts- und herstellerspezifische Programme einsetzen. Dazu muss der Benutzer auch wissen, welche DICOM-Bilder / Bilddaten auf welche Art und Weise in eine Applikation geladen werden müssen. Beispielsweise müssen für eine Dual-Energy-Auswertung die korrekten Bildserien identifiziert, transferiert und in die richtige Applikation geladen werden. Teilweise sind auch weitere Einstellungen notwendig (z.B. Auswahl einer Auswertungsmethode). Ist die Auswertung auf dem Clientgerät abgeschlossen, werden meistens weitere Ergebnisobjekte (z.B. in Form von statischen Ergebnisbildern) erzeugt und im DICOM-Format angelegt.
-
Weiterhin gibt es Datenobjekte wie z.B. CT-oder MR-Daten, die mit Standardviewern überhaupt nicht angezeigt werden können. Dies ist ein wichtiger Nachteil bekannter Systeme, da die Nachbearbeitung und Anzeige somit nur unter sehr eingeschränkten Bedingungen auf dem Clientgerät möglich ist.
-
Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, ein System und Verfahren zur Verfügung zu stellen, mit dem die Nachverarbeitung von medizinischen Bilddaten verbessert und insbesondere flexibler gestaltet werden kann. Vorzugsweise sollen Clientgeräte dahingehend erweitert werden, dass eine Nachverarbeitung von Bilddaten möglich wird, ohne dass eine spezielle technische Gerätekonstruktion oder Gerätekonfiguration auf dem Clientgerät erforderlich ist (z.B. Implementierung einer speziellen Viewing Software).
-
Diese Aufgabe wird erfindungsgemäß durch einen Gegenstand mit den Merkmalen gemäß den beiliegenden, nebengeordneten Ansprüchen gelöst, die auf ein System, eine Berechnungseinheit, eine Bildakquisitionseinheit und zwei Verarbeitungsverfahren /zur Vor- und Nachbearbeitung) gerichtet sind.
-
Im Folgenden wird die Erfindung anhand der verfahrensgemäßen Aufgabenlösung beschrieben. Dabei erwähnte Merkmale, Vorteile oder alternative Ausführungsformen sind ebenso auch auf die anderen beanspruchten Gegenstände zu übertragen und umgekehrt. Mit anderen Worten können auch die gegenständlichen Ansprüche (die beispielsweise auf ein System oder auf ein Computerprogramm oder auf ein Produkt gerichtet sind) mit den Merkmalen weitergebildet sein, die in Zusammenhang mit dem Verfahren beschrieben oder beansprucht sind. Die entsprechenden funktionalen Merkmale des Verfahrens werden dabei durch entsprechende gegenständliche Module, insbesondere durch elektronische Hardware-Module oder Mikroprozessor-Module, des Systems ausgebildet und umgekehrt.
-
Das erfindungsgemäße System ist für eine Vielzahl von unterschiedlichen Endgeräten (Viewinggeräten, Befundungsstationen, im Folgenden ‚Clientgerät‘ genannt) ausgelegt und dient zur Erweiterung der Clientgeräte dahingehend, dass darauf eine Nachbearbeitung von unterschiedlichen medizinischen Bilddaten möglich wird. Dazu wird die Transfertechnologie der Bilddaten von einem Bildakquisitionssystem auf das Clientgerät verändert. Die zu übertragenden Bilddaten werden erfindungsgemäß durch Zusatzinformation erweitert. Insbesondere wird ein Container mit einem Steuerobjekt erzeugt und transferiert, in dem eine Nachverarbeitungsfunktionalität für die jeweiligen Bilddaten spezifisch eingebunden ist.
-
Gemäß einem Aspekt betrifft die Erfindung somit ein System zur Verarbeitung von medizinischen Bilddaten, mit:
- – Einem Bilddatenakquisitionssystem, insbesondere einem Dual-Energy-Computertomographiesystem, das zur Akquisition von Bilddaten dient;
- – Einer Berechnungseinheit, die zur Erzeugung eines Containers dient, der die Bilddaten und ein den Bilddaten jeweils eineindeutig zugeordnetes Steuerobjekt umfasst;
- – Zumindest einem Clientgerät, das dazu bestimmt ist, den Container zu erfassen und aus diesem das Steuerobjekt zu extrahieren, um die Verarbeitung der Bilddaten mit dem Steuerobjekt zu steuern;
- – Einem Netzwerk zum Datenaustausch zwischen dem Bilddatenakquisitionssystem, der Berechnungseinheit und dem zumindest einen Clientgerät.
-
Das Bilddatenakquisitionssystem ist in der bevorzugten Ausführungsform der Erfindung ein Dual-Energy-Computertomographiesystem. Die Erfindung kann aber ebenso auf andere Bildakquisitionsgeräte, wie übliche Röntgengeräte, CT- und/oder MRT-Systeme angewendet werden.
-
Die Berechnungseinheit kann in Software oder Hardware implementiert und auf dem Bilddatenakquisitionssystem ausgebildet sein. Alternativ kann sie auch als separate Einheit über eine Schnittstelle an die anderen Module des Systems angeschlossen sein.
-
Das Clientgerät kann ein computerbasiertes System sein. Vorteilhafterweise muss es nicht über spezifischen Nachbearbeitungsfunktionalität mehr verfügen, da diese sozusagen mit den Bilddaten mitgeliefert wird. Das Clientgerät kann ein Personal Computer, ein mobiles Endgerät (Laptop, Mobilfunktelefon), ein Netzwerk aus computerbasierten Instanzen, eine Befundungsstation oder eine Viewingstation sein. Das Clientgerät muss nicht zwangsläufig Bestandteil einer Client/Server-Architektur sein, sondern kann auf einer beliebigen Netzwerkarchitektur basieren. Das Clientgerät ist ein elektronisches System mit einer Schnittstelle zum Empfang von Bilddaten, einer Verarbeitungseinheit und einer Anzeigeeinheit zur Darstellung der Bilddaten entsprechend den Vorschriften, die erfindungsgemäß an die Bilddaten angekoppelt sind. Das Clientgerät dient als Datensenke und wird mit Daten von einer Datenquelle (z.B. einem Bildakquisitionssystem) versorgt. Es ist durchaus möglich (und auch üblich), dass der Bildscanner (die Datenquelle), die Bilddaten mit dem zugeordneten Steuerobjekt an mehr als eine Datensenke (Clientgerät) sendet. Auch kann es vorgesehen sein, dass die Bilddaten mit dem Steuerobjekt von einer ersten Datensenke an weitere Empfängerknoten (z.B. erste und weitere Befundungsworkstations, PACS und andere Zielsysteme) gesendet oder weitergeleitet werden.
-
Bei dem Container handelt es sich um einen Datencontainer. Der Container ist ein digitales Objekt, das neben den Bilddatensätzen eine Erweiterung enthält, die dazu dient, auf dem Empfänger des Containers, dem jeweiligen Clientgerät, eine Nachverarbeitungs- und Visualisierungsfunktionalität bereitzustellen. Diese Funktionalität wird in dem Steuerobjekt bereitgestellt und kann spezifisch für die jeweils übertragenen Bilddatensätze erzeugt und ausgelegt sein. Das Steuerobjekt kann an die Bilddaten angehängt werden oder auf sonstige Weise mit den Bilddaten kombiniert werden (z.B. in Form von Attributen oder Schattenattributen in einem DICOM-Datensatzes). Somit enthält z.B. ein erster Container für Dual-Energy Bilddaten ein erstes Steuerobjekt mit einer Menge von für die Dual-Energy Daten ausgelegten Steuerfunktionen und ein zweiter Container für Röntgendaten ein zweites Steuerobjekt mit einer Menge von für die Röntgen Daten ausgelegten Steuerfunktionen. In einer weiteren Ausführungsform der Erfindung kann es optional vorgesehen sein, dass der Container spezifisch für das empfangende Clientgerät erzeugt wird. So kann ein erster Container für eine komplexe Viewingstation ausgelegt sein, während ein zweiter Container für einen einfachen PC ausgelegt ist, der über keine spezifischen Installationen und Hardwarekonfigurationen verfügt.
-
Gemäß einer bevorzugten Ausführungsform der Erfindung dient das Steuerobjekt zur Steuerung der Visualisierung der Bilddaten auf dem Clientgerät. Die Visualisierung kann interaktiv sein, so dass zusätzlich Masken erzeugt werden, die zur Nachverarbeitung der Bilddaten auf dem Clientgerät angezeigt und vom Anwender bedient werden können. Vorteilhafterweise wird es damit möglich, die Bilddaten an einen beliebigen Empfänger zusenden, der z.B. nur über einen Standardviewer verfügt und keine oder keine spezifische Viewingfunktionalität bereitstellt.
-
Gemäß einer weiteren, bevorzugten Ausführungsform der Erfindung ist die Berechnungseinheit als Cloud-Server ausgebildet. Damit kann eine weitere Flexibilität erreicht werden, da die Bildakquisitionssysteme über eine Schnittstelle an die Berechnungseinheit angeschlossen werden können und nicht direkt eine solche Berechnungseinheit bereitstellen müssen. Es ist deshalb vorteilhafterweise nicht erforderlich, dass die bisherigen Bildakquisitionssysteme erweitert oder verändert werden müssen.
-
Gemäß einer weiteren, bevorzugten Ausführungsform der Erfindung umfasst das Steuerobjekt eine Auswertevorschrift für die im Container transferierten Bilddaten.
-
Diese Auswertevorschrift kann direkt in Form eines Programmcodes (HTML- oder Web-Assemblies) bereitgestellt werden. Alternativ oder kumulativ (für Teile oder Ausschnitte der Auswertevorschrift) kann die Auswertevorschrift auch als eine Referenz auf einen Programmcode bereitgestellt werden, der über eine Netzwerkschnittstelle zugreifbar ist. Damit wird es möglich, die Auswertevorschrift zu ändern, ohne dass eine Änderung an dem Container oder an der Berechnungseinheit ausgeführt werden muss.
-
Gemäß einer weiteren, bevorzugten Ausführungsform der Erfindung umfasst das Steuerobjekt einen Transformationsbefehl. Dieser dient dazu, eine Datenrepräsentation in den Bilddaten in Pixelwerte auf dem Clientgerät umzuwandeln.
-
Gemäß einer weiteren, bevorzugten Ausführungsform der Erfindung dient das Steuerobjekt dazu, auf dem Clientgerät ein Ergebnisobjekt zu erzeugen. Das Ergebnisobjekt kann final gerenderte Bilder umfassen. Das Ergebnisobjekt kann an die jeweiligen technischen Systembedingungen des Clientgerätes, angepasst sein und z.B. Parametersätze zur Steuerung der Bilddarstellung umfassen. Die Parametersätze können vorzugsweise an die Bilddaten angepasst sein, die in dem Container transferiert werden.
-
Gemäß einer weiteren, bevorzugten Ausführungsform der Erfindung umfasst das Steuerobjekt ein Interaktionsmodul. Das Interaktionsmodul ist dazu ausgebildet, eine spezifische, an die Bilddaten und an das Clientgerät angepasste Benutzerschnittstelle zur Interaktion mit den auf dem Clientgerät zur Darstellung gebrachten oder zur Darstellung zu bringenden Bilddaten zu erzeugen und anzuwenden. Das Interaktionsmodul dient somit zur Erzeugung von Bildschirmmasken auf dem Clientgerät. Die erzeugten Bildschirmmasken können dediziert sowohl auf die technischen Konfigurationen des Clientgerätes und auf die im Container übertragenden Bilddaten ausgerichtet sein. Damit kann die Übertragungskapazität effizient ausgenutzt werden, indem nur die für den Empfänger (Clientgerät) und für die im Container transferierten Bilddaten relevanten Befehle zur Nachbearbeitung und Visualisierung übertragen werden. Die Bildschirmmasken können Fenster zur Ein- und Ausgabe von Daten umfassen. Sie können auch dazu dienen eine maskierte Darstellung von Bilddaten anzuzeigen, indem z.B. automatisch eine Maske erzeugt werden kann, die alle Knochenstrukturen der Bilddaten überdeckt. Der Anwender kann dann diese Masken editieren und verbessern oder anpassen. Es ist z.B. auch möglich, mit Hilfe der Maske die Knochen aus einer 3D-Darstellung entfallen zu lassen, um damit einen „freien Blick“ auf die Gefäße zu bekommen.
-
Interaktionen des Anwenders auf dem Clientgerät sind aber nicht immer mit Masken verbunden. Es gibt auch völlig maskenfreie Interaktionen. Beispielweise wenn bei einem CT der Jodgehalt in einer ROI (region of interest) angezeigt werden soll oder falls bei einer Perfusionsberechnung der Gehirnbereich geändert werden soll, der zur Normalisierung dient.
-
Gemäß einem weiteren Aspekt betrifft die Erfindung ein Verfahren zur Vorverarbeitung von Bilddaten. Die Vorverarbeitung dient der Übersendung an ein oder mehrere Clientgerät(e). Das Verfahren kann auf dem Bildakquisitionssystem ausgeführt werden. Das Ergebnis der Vorverarbeitung kann – vorzugsweise auf dem Bildakquisitionssystem oder zentral – gespeichert werden. Das Verfahren umfasst folgende Verfahrensschritte:
- – Erfassen von Bilddaten auf dem Bildakquisitionssystem;
- – Bestimmen von Steuervorschriften zur Nachverarbeitung und Auswertung der Bilddaten und Ablegen derselben in einem Steuerobjekt;
- – Erzeugen eines Containers, umfassend die erfassten Bilddaten mit dem zugeordneten Steuerobjekt;
- – Speichern des erzeugten Containers.
-
Das Verfahren kann auch ein Versenden des erzeugten Containers an ausgewählte oder bestimmte Empfänger (Clientgeräte) umfassen.
-
In einer vorteilhaften Weiterbildung der Erfindung umfasst die Auswertevorschrift einen ausführbaren Auswertecode oder einen Verweis (link), der den ausführbaren Auswertecode referenziert.
-
Gemäß einem weiteren Aspekt bezieht sich die vorliegende Erfindung auf ein Verfahren zur interaktiven Nachbearbeitung von medizinischen Bilddaten auf einem Clientgerät, mit folgenden Verfahrensschritten:
-
- – Einlesen eines Containers mit Bilddaten und mit einem Steuerobjekt über eine Schnittstelle;
- – Herauslösen des Steuerobjektes aus dem Container, um die Nachverarbeitung der Bilddaten mit dem Steuerobjekt zu steuern.
-
In einer vorteilhaften Weiterbildung der Erfindung ist die Nachverarbeitung der Bilddaten an die Bilddaten und an die technischen Konfigurationen des Clientgerätes angepasst. Das Verfahren wird vorzugsweise zur Laufzeit mit dem Laden der Bilddaten ausgeführt.
-
Die Erfindung bezieht sich somit auf zwei unterschiedliche Verfahren, die entweder auf dem Bildakquisitionsgerät (oder der Berechnungseinheit) ausgeführt werden oder auf dem Clientgerät. Das Verfahren umfasst einerseits Abschnitte, die auf dem Bildakquisitionssystem und andererseits Abschnitte, die auf dem Clientgerät ausgeführt werden. Das System umfasst entsprechend Abschnitte (im Sinne von funktionalen Modulen), die auf dem Bildakquisitionssystem implementiert sind und andererseits Abschnitte, die auf dem Clientgerät implementiert werden. Gemäß einem weiteren Aspekt kann die Erfindung auch ein System betreffen, das nur den bildakquisitionsgerätebezogenen Abschnitt umfasst oder das nur den clientgerätebezogenen Abschnitt umfasst.
-
Die beschriebenen Verfahren können als Computerprogramm bereitgestellt werden, die Befehle umfassen, die zur Ausführung des jeweiligen Verfahrens bestimmt sind, wenn das Programm auf dem Computer ausgeführt wird.
-
In der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen.
-
Kurze Beschreibung der Figuren
-
1 zeigt in einer schematischen Übersichtsdarstellung ein Bildakquisitionssystem in Datenaustausch mit einem Clientgerät.
-
2 zeigt ein Ablaufdiagramm für ein Verfahren zur Erzeugung eines Containers.
-
3 zeigt ein Ablaufdiagramm für ein Verfahren zur Nachverarbeitung von Bilddaten auf einem Clientgerät.
-
Detaillierte Beschreibung der Erfindung
-
1 zeigt eine schematische Übersichtsdarstellung des erfindungsgemäßen Systems. Das System umfasst einen Bildakquisitionsteil mit dem Bildakquisitionssystem A und einen Nachverarbeitungs- und Visualisierungsteil, der einem Clientgerät C zugeordnet ist.
-
Das Bildakquisitionssystem A umfasst eine Bilddatenmesseinheit A1 und dient zur Messung und Erfassung von Bilddaten RBD. Dabei kann es sich z.B. um ein Dual-Energy CT-System handeln. Alternativ können die Messdaten auch von einem Speicher eingelesen werden und bereits zu einem früheren Zeitpunkt erfasst worden sein. Eine Berechnungseinheit B dient zur Erfassung von Auswertevorschriften zur Nachbearbeitung für die erfassten Bilddaten RBD, um daraus ein Steuerobjekt 2 zu erzeugen. Die Berechnungseinheit B kann in dem Bildakquisitionssystem A integriert sein (wie in dem in 1 dargestellten Ausführungsbeispiel gezeigt). Vorzugsweise kann die Berechnungseinheit B auch als separate Instanz über ein Netzwerk NW zugeschaltet werden. Die Berechnungseinheit B kann auch als Webserver ausgebildet sein und ist in dieser Ausführungsform der Erfindung an das Bildakquisitionssystem A angeschlossen und nicht direkt auf dem Bildakquisitionsgerät implementiert. Damit entsteht der Vorteil, dass weder das Akquisitionssystem A noch das Clientgerät C verändert werden müssen, obwohl die grundlegenden Prozesse, Funktionen und Rechenvorschriften geändert sind und dynamisch geändert werden können.
-
Die Berechnungseinheit B dient zur Erzeugung eines Containers 1. Der Container 1 umfasst die jeweils an ein Clientgerät C zu übertragenden Bilddaten RBD und ein diesen Bilddaten RBD dediziert und spezifisch zugeordnetes Steuerobjekt 2. Der erzeugte Container 1 wird über eine Ausgangsschnittstelle A2 und dem Netzwerk NW an ein ausgewähltes Clientgerät C übertragen.
-
Auf dem Clientgerät C befindet sich eine Eingangsschnittstelle C1, die zum Einlesen des Containers 1 und zum Weiterleiten desselben an einen Extraktor C2 bestimmt ist. Der Extraktor C2 ist zur Extraktion der Bilddaten RBD und des Steuerobjektes 2 aus dem Container 1 und zum Weiterleiten der extrahierten Daten an einen Prozessor C3 bestimmt. Der Prozessor C3 dient zur Nachbearbeitung der empfangenen Bilddaten RBD, indem auf die Bilddaten RBD das Steuerobjekt 2 mit einer darin enthaltenden Auswertevorschrift angewendet wird, um die Bilddaten BD auf einem Monitor M des Clientgerätes C darzustellen.
-
In einer bevorzugten Ausführungsform der Erfindung kann die Auswertevorschrift spezifisch an die jeweiligen Bilddaten RBD angepasst sein. Zudem kann die Auswertevorschrift in einer Weiterbildung der Erfindung kumulativ an die technischen Betriebsbedingungen des Clientgerätes C angepasst sein.
-
2 beschreibt einen Ablauf zur Erzeugung des Containers 1. Nach dem Start des Verfahrens erfolgt in Schritt 21 ein Bestimmen eines Typs der auf dem Bildakquisitionssystem A erfassten Bilddatensätze RBD. In Schritt 22 werden Auswertevorschriften für den bestimmten Typ von Bilddatensätzen RBD erfasst. In Schritt 23 werden die technischen Parameter des Clientsystems bzw. Clientgerätes C erfasst. Dabei kann es sich um Speicherkapazität, Rechnerressourcen, Nachbearbeitungsfunktionalität und um weitere technische Aspekte des Clientgerätes C handeln. In Schritt 24 werden die Auswertevorschriften für den erfassten Typ von Bilddatensätzen RBD und für die erfassten technischen Parameter ausgewählt. Damit ist die ausgewählte Auswertevorschrift spezifisch sowohl an die jeweiligen Bilddatensätze RBD (z.B. an die anatomische Region, den Typ der Datenerfassung, den erfassten Ausschnitt, die Auflösung etc.) als auch an die technischen Betriebsbedingungen des Clientgerätes C (z.B. bereits vorhanden Viewingfunktionalität, Speicher, Prozessorkapazität etc.) ausgelegt. In Schritt 25 erfolgt das Erzeugen des Containers 1 mit den Bilddaten RBD und der bilddatenspezifischen Auswertevorschrift für diese Bilddaten RBD. In Schritt 26 kann der Container 1 über das Netzwerk NW an das Clientgerät C gesendet werden.
-
Im Folgenden wird ein Verfahrensablauf für die Nachbearbeitung der Bilddaten RBD auf dem Clientgerät C unter Bezugnahme auf 3 näher erläutert. Nach dem Start des Verfahrens wird in Schritt 31 der Container 1 empfangen, um in Schritt 32 in dem Extraktor C2 extrahiert zu werden. Insbesondere werden hier die Bilddaten RBD und das Steuerobjekt 2 extrahiert, das ein Instruktionsobjekt umfasst. In Schritt 33 wird das extrahierte Steuerobjekt mit den enthaltenen Auswertevorschriften auf die extrahierten Bilddatensätze RBD angewendet, um Bilddatensätze zu erzeugen, die in Schritt 34 auf einem Monitor des Clientgerätes C darstellbar sind.
-
Im Allgemeinen zielt die vorliegende Anmeldung darauf ab, dass Bilddaten RBD von medizinischen Geräten (CT, MR, AX ...) mit Erweiterungen (Steuerobjekt 2) gespeichert und übertragen werden. Die Erweiterung dient zur Nachbearbeitung, Visualisierung und/oder zur Auswertung der Bilddaten RBD. Das Steuerobjekt 2 kann eine Auswertevorschrift umfassen oder eine solche referenzieren. Dadurch können aus den DICOM-Bilddaten RBD, auf dem Clientgerät C Bilddaten BD erzeugt, angezeigt und/oder verarbeitet werden. Die Bilddaten werden gemeinsam mit dem Steuerobjekt 2 mit einer Erweiterung (nämlich mit einer Auswertevorschrift zur Auswertung der Bilddaten) gespeichert und übertragen. Die Erweiterung umfasst nicht nur die Bilddaten (Voxel) und Attribute (Matrixgröße, Bittiefe, Aufnahmedatum etc.), sondern auch die Information (oder eine Referenz) zur Visualisierung und/oder Nachverarbeitung der Bilddaten RBD. Dadurch wird aus den Bilddaten RBD ein Container 1, der Daten und Verfahren (Funktion) zusammenbringt. Dies bringt Vorteile in der Handhabung. Es erlaubt aber auch, standardisierte Rechner als Endkundensysteme zu verwenden, die nicht speziell für bestimmte Postprocessing Funktionalitäten ausgerüstet werden müssen. Weiterhin können Standardtechnologien wie Web-Browser verwendet werden, um spezielle Funktionalitäten (z.B. einen neuen Visualisierungsmodus oder eine Dual-Energy-Nachverarbeitung) auf einen Standardarbeitsplatz zu bringen.
-
Der Anwender am Clientgerät C muss kein Wissen mehr über die zugrundeliegenden Datenstrukturen, über die Post-Processing Software und über deren Bedienung haben, wenn er Bilddaten RBD nachverarbeiten will. So ist es z.B. nicht mehr erforderlich, Bildserien auf CT Cardiac zu mappen, um eine Funktionsaussage zu bekommen. Im Gegenteil, kann eine beliebige Befundungs- oder Auswertesoftware für Nachbearbeitung & Visualisierung genutzt werden, da die notwendigen Algorithmen & Verfahren im Container 1 enthalten sind oder dort referenziert werden. Vorteilhafterweise kann auch eine konkrete Version einer Nachbearbeitungsfunktionalität zur Visualisierung / Verarbeitung der Daten im Container 1 abgelegt oder referenziert werden. Ein Update einer Nachverarbeitungsworkstation / Software führt nicht mehr zu veränderten Ergebnissen. Es können Daten visualisiert und nachverarbeitet werden, für die es keine standardisierte Darstellungsform gibt (z.B. CT- oder MR-Daten oder -Eingangsbilder). Die Rechenoperationen für Nachverarbeitung und Visualisierung können an einen Server oder eine Cloud ausgelagert werden. Insbesondere kann die in den Daten enthaltene Referenz neben den Algorithmen bzw. der Referenz auf die Algorithmen ebenso eine Referenz auf den Server / die Cloud enthalten. Die in dem Container 1 enthaltenen / referenzierten Rechenoperationen können beim Eintreffen auf einem Rechnersystem vorberechnet werden (bzw. eine Vorberechnung kann von einem Server / Cloud angefordert werden). Dadurch sind die Ergebnisse für den Benutzer ohne Wartezeit verfügbar. Die in dem Container 1 mit den Bildern enthaltenen / referenzierten Cloud/Server Systeme könnten den Bildtransfer a priori durchführen und so Wartezeiten vermeiden. Die Verwendung von Cloud/Servern kann mit anonymisierten Daten erfolgen, da der konkrete Patientenkontext nicht notwendig ist und lokal auf dem System des Clientgerätes C erzeugt werden kann. Das Verfahren bietet sich insbesondere für neue Methoden wie Counting-CT an, bei denen Daten erzeugt werden, deren Betrachtung in standardisierten DICOM-Viewern keinen Mehrwert erzeugt. Sogenannte Image Call-Up Verfahren können einfach mit Hilfe von Standard Technologie auf generischen Workstations wie Web-Browsern erfolgen. Ein versierter Anwender kann über definierte Schnittstellen eigene Verarbeitungs- und Darstellungsfunktionalität integrieren – ohne die komplette Befundarbeitsplatzinfrastruktur an sich aufbauen zu müssen. Bei dem Verfahren kann die Kompatibilität mit bestehenden Bildgebungsstandards erhalten werden.
-
Das System wird im Folgenden anhand einer Dual-Energy-Messung zur Darstellung der Gefäße des Kopfes erläutert. Typischerweise werden heute zwei Serien mit einigen hundert einzelnen 2D-DICOM-Bildern abgespeichert. Erfindungsgemäß werden die akquirierten Bilddaten RBD in einem DICOM Multiframe Objekt abgelegt, das die gesamten 2D Daten in einem Objekt enthält. Weiterhin werden mit dem Bild weitere Attribute abgelegt. In einer Ausführungsform der Erfindung sind diese Attribute herstellerspezifische Schattenattribute. Vorzugsweise sind diese Attribute auch Teil eines erweiterten Standards.
-
In diesen zusätzlichen Attributen des Steuerobjektes 2 wird html/Javascript Code abgelegt, der es erlaubt, die Daten geeignet zu rendern. Der Code wird von einem Standard Web-Browser ausgeführt, wobei der Code als Datenobjekt das DICOM Bild selbst als Referenz übergibt. Weiterhin erzeugt der Code im Rahmen des Interaktionsobjektes auch Bedienelemente. In dem genannten Beispiel würde der html/Javascript Code aus den Daten eine für die Bilddaten RBD spezifische Calcium bzw. Knochenmaske errechnen, die auf dem Monitor M zur Anzeige gebraucht wird und die entsprechenden Eingabesignale des Anwenders verarbeitet. Die entsprechenden Daten würden dann in der Visualisierung nicht angezeigt. Die Visualisierung selbst könnte z.B. ein Mittelwertbild aus den beiden Serien sein.
-
Die Bedienelemente können beispielsweise die Visualisierung der Knochenmaske als andersfarbige Überlagerung erlauben. Weiterhin ist eine interaktive Editierung der Maske auf dem Clientgeräte C möglich.
-
Analog könnte der html/Javascript Code in dem Container 1 zu den Bildern inklusive Version auch referenziert werden. Durch den Aufruf einer Seite in einem Standardbrowser könnte die komplette Darstellung inkl. Verarbeitung in einer Cloud erfolgen. Die Cloud lädt DICOM Datenobjekt selbst wiederum direkt von einem Klinik-Server. Hierbei können Standards, wie z.B. WADO für web-basierten DICOM Zugriff genutzt werden. Der Patientenkontext (z.B. Name) kann lokal beim Benutzer angezeigt werden.
-
Erfindungsgemäß werden zum Erzeugen neuer Bilder auch spezifische Masken generiert, die editiert werden können.
-
Auf dem Clientgerät C können somit nach dem Empfang des Containers 1 auch Ergebnisse erzeugen werden. Ergebnisse können final gerenderte Bilder sein (im Sinne von „secondary captures“). Ergebnis kann auch eine Art „presentation state“ sein, der dann aus den erforderlichen Bilddaten und einem „eingefrorenen“ Parametersatz zur Steuerung der Bilddarstellung (Bildposition, gewählte Overlayoption, Fusion-Blending Wert, LUT, aktivierbare Tools, etc.) besteht. Weiterhin können im Bearbeitungsverlauf Hilfsobjekte wie binäre Masken (Editierungsergebnisse) und ähnliches erzeugt werden. Solche neuen Objekte können persistiert werden und von Benutzern verwendet werden. Die Originaldaten können optional Referenzen auf solche Hilfsobjekte speichern und diese bei Bedarf einbinden.
-
Der Transfer der erzeugten Ergebnisbilder auf das Kundensystem kann dann wiederum durch den eingebetteten Code erfolgen; beispielsweise durch einen webbasierten DICOM Transfer nach WADO Standard in umgekehrter Richtung.
-
Benutzerspezifische Einstellungen können mit dem vorgestellten System verwaltet werden. Im konkreten Beispiel kann dies z.B. mit Cookies erfolgen, die dann im Browser oder im Profil des Benutzers gespeichert werden.
-
Durch die logische Separation von Bilddaten und Verarbeitungs- und Darstellungslogik ist es möglich, die Bilddaten mit einer generischen Verarbeitungs- und Darstellungslogik für eine bestimmte Benutzergruppe (z.B. „All Users“) zu kombinieren und weitergehende Premium Darstellungs- und Verarbeitungsvarianten nur authentifizierten Benutzern (z.B. durch Anmeldung an Befundstation, Cloud-Login, etc.) zu ermöglichen. So könnte ein Premium-User neben der reinen Darstellung von funktionalen Overlays auch noch weiterführende quantitative Auswertungsschritte durchführen, wenn er die ihn zuvor angebotenen Lizenz erworben hat.
-
Das System kann in eine generische Portallösung eingebunden werden (Webportal). Die erfassten und übertragenen Bilddaten RBD selbst „tragen“ über den Container 1 ihre Funktionalität in sich.
-
Durch Context-Sharing Methoden ist es möglich, auch komplexere Applikationen zu realisieren, z.B. synchronisiertes Scrolling über verschiedene Bildsegmente hinweg, wobei die Visualisierungsfunktionalität von außen über das Portal gesteuert werden kann (Bild-Navigation, Fensterung, Blending, Darstellungsmodus (MIP, VRT, MPR, etc.)).
-
Durch die ad-hoc-Einbindung von online verfügbaren Visualisierungs- und Bearbeitungsoptionen ist es möglich über eine große Nutzergruppe hinweg Usage-Patterns zu erfassen und für künftige Optimierungsentscheidungen zu nutzen (Usage Tracking).
-
Weiterhin kann die Cloudbasierte Verarbeitung von Bilddaten die Bilddaten in einer anonymisierten und abstrakten Form zur Verfügung stellen. Dies kann für die Ableitung von Erkenntnissen (Lern-basierte Algorithmen, Mustererkennung, ähnliche Fälle, Statistik) genützt werden.
-
Da die Darstellungsverfahren und Algorithmen in den Daten selbst vorhanden sind bzw. referenziert werden, ist es denkbar, dass nicht validierte oder manipulierte Verfahren zum Einsatz kommen, ohne dass der Endbenutzer dies bemerkt. Dieses Problem kann umgangen werden, in dem die in den Bildern enthaltene Information zur Algorithmik / Visualisierung mit einem PKI Verfahren signiert wird. Das Vorliegen einer gültigen Signatur kann dem Benutzer angezeigt werden.
-
Mit der vorliegenden Anmeldung wird von dem bisherigen Ansatz mit einer Verteilung von Bilddaten, Parametern (DICOM) und Algorithmik (Server/Workstation) abgewichen. Die Bilder bekommen erfindungsgemäß intrinsisch mit dem Container 1 einen ausführbaren Kontext für Darstellung und Nachverarbeitung, der nicht mehr an eine herstellerspezifische Workstation gebunden ist.
-
Das System umfasst vorzugweise einen Bildakquisitionsabschnitt und einen Clientabschnitt. Der Bildakquisitionsabschnitt ist der Bilderfassung zugeordnet und bezieht sich auf die modifizierte Erzeugung von zu übertragenden Bilddaten RBD und deren Abspeicherung. Der Clientabschnitt ist der Nachbearbeitung der Bilddaten auf dem Clientgerät C zugeordnet und dient der Darstellung der Bilddaten BD und der Erzeugung einer Benutzeroberfläche mit spezifischen Masken für die Nachbearbeitung der jeweiligen Bilddaten RBD.
-
Es liegt jedoch ebenso im Rahmen der Erfindung nur die einzelnen, vorstehend erwähnten Abschnitte bereitzustellen, nämlich den Bildakquisitionsabschnitt zur Erweiterung des Bildakquisitionssystems oder den Clientabschnitt zur Erweiterung des Clientgerätesystems bzw. Endusersystems.
-
Erfindungsgemäß wird auf dem Clientgerät C nicht nur, wie bisher, vorimplementierte funktionale Logik / Businesslogik bereitgestellt, sondern mit dem erfindungsgemäßen System kann eine definierte Erweiterungsschnittstelle für das Clientgerät C angeboten werden. Dadurch kann der zusätzliche mit der Bilddatei übertragene Programmcode den vorinstallierten Programmcode erweitern oder verändern. Wichtig ist dabei, dass diese Veränderung zur Laufzeit mit dem Laden der Bilddaten RBD erfolgen kann. Dieser Teil des Gesamtsystems wird im Folgenden als Steuersystem bezeichnet.
-
Der zusätzliche Programmcode enthält dabei Erweiterungen, welche es dem Steuersystem erlauben, die Bilder in verschiedenen und neuen Arten darzustellen. Diese Darstellungen umfassen die programmatische Umwandlung der Datenrepräsentation in den Ursprungsdaten (Bilddaten RBD) in Pixelwerte auf dem Darstellungsgerät. Die Darstellung kann dabei auf einer Schicht (2D), auf einem Volumen (3D) oder auch über Zeitpunkte oder Modalitäten hinweg (4D) erfolgen. Konkret erfolgt die Umwandlung durch einen Prozess, der die Daten in einen Speicher des Rechners lädt und anhand der Programmvorschrift mit der räumlichen und/oder zeitlichen Umgebung verrechnet.
-
Weiterhin kann der Programmcode Erweiterungen enthalten, die es dem Steuersystem erlauben, aus den Daten neue Ergebnisse zu erzeugen. Dazu werden die übermittelten Daten geladen, mit Hilfe der Erweiterung umgerechnet und dann erneut abgelegt oder zur Darstellung gebracht. Ergebnisse können weitere Bild, strukturierte Informationen oder Masken sein. Konkret erfolgt die Umwandlung durch einen Prozess, der die Daten in den Speicher des Rechners lädt und anhand der Programmvorschrift mit der räumlichen und/oder zeitlichen Umgebung verrechnet. Weiterhin können Informationen aus Referenzdatenbanken in die Berechnung einfließen. Diese können beispielsweise anatomischer Natur sein (z.B. Wahrscheinlichkeit, dass nach Abbildung auf eine Struktur in Standardkoordinaten (z.B. Standard Anatomie, insbesondere Kopf) an dieser Stelle Knochen vorliegt).
-
Da die Daten die Erweiterungen des Steuersystems intrinsisch enthalten, muss der Benutzer auch keine Modi am Clientgerät C manuell auswählen, sondern bekommt die Erweiterungen automatisch angeboten. Ebenso können die Möglichkeiten des Gesamtgeräts über den Datensatz erweitert werden; d.h. nach der Installation.
-
Die Erfindung schlägt im Kern eine veränderte Datenablage, Datenverarbeitung und/oder Datenübertragung zwischen einem Bildakquisitionssystem und einem oder mehreren Clientgerät(en) vor. Die erfassten Bilddaten RBD werden nicht mehr direkt und ohne zusätzliches Steuerobjekt, so wie sie erfasst werden, transferiert. Erfindungsgemäß werden die Bilddaten RBD einer Berechnungseinheit B zugeführt, die eineindeutig für diese Eingangsdaten bzw. Bilddaten RBD einen Container 1 erzeugt, der als Erweiterung ein Steuerobjekt umfasst.
-
Abschließend sei darauf hingewiesen, dass die Beschreibung der Erfindung und die Ausführungsbeispiele grundsätzlich nicht einschränkend in Hinblick auf eine bestimmte physikalische Realisierung der Erfindung zu verstehen sind. Alle in Verbindung mit einzelnen Ausführungsformen der Erfindung erläuterten und gezeigten Merkmale können in unterschiedlicher Kombination in dem erfindungsgemäßen Gegenstand vorgesehen sein, um gleichzeitig deren vorteilhafte Wirkungen zu realisieren.
-
Der Schutzbereich der vorliegenden Erfindung ist durch die Ansprüche gegeben und wird durch die in der Beschreibung erläuterten oder den Figuren gezeigten Merkmale nicht beschränkt.
-
Für einen Fachmann ist es insbesondere offensichtlich, dass die Erfindung nicht nur für Dual-Energy CT-Bildakquisitionsgeräte angewendet werden kann, sondern auch für andere medizinische Bildakquisitionsgeräte, die eine spezifischen Nachbearbeitung oder Visualisierung der Bilddaten erfordern. Des Weiteren können die Bauteile bzw. Module des Bildakquisitionssystems auch auf mehrere physikalischen Produkte verteilt realisiert sein, so dass z.B. die Berechnungseinheit auch auf einem zentralen Server implementiert sein kann.
