DE102012213910A1

DE102012213910A1 - Steuerungsmodul und -verfahren zur Perspektivenbestimmung beim Rendern von medizinischen Bilddatensätzen

Info

Publication number: DE102012213910A1
Application number: DE102012213910.9A
Authority: DE
Inventors: Stephan Nufer; Jens Gühring
Original assignee: Siemens AG
Current assignee: Siemens Healthcare GmbH
Priority date: 2012-08-06
Filing date: 2012-08-06
Publication date: 2014-02-06
Also published as: US20140035811A1; US9208747B2

Abstract

Die Erfindung betrifft ein Steuerungsverfahren, eine Steuerungseinheit (10) und ein Computerprogrammprodukt zur Kontext-spezifischen Bestimmung von zumindest einer SOLL-Perspektive beim Rendern von medizinischen Bilddaten (BD) auf einem Monitor (M). Dazu wird ein grafisches oder bildliches Symbol (S) dynamisch und in Abhängigkeit von einem Bildstatus auf einem User Interface (UI) erzeugt, um ein Perspektivenwechselsignal zu erfassen und zur Steuerung des Renderings verwendet wird.

Description

Die vorliegende Erfindung liegt auf den Gebieten der Bildverarbeitung und der Medizintechnik und betrifft insbesondere einen Ansatz, die Perspektive(n) im Vorfeld zu bestimmen, die Grundlage des nachgeordneten Rendering-Prozesses sein sollen, um die medizinischen Bilddatensätze auf einem Monitor in einer bestimmten Perspektive darzustellen.
Insbesondere auf dem Gebiet der Medizintechnik ist es beispielsweise im Rahmen der Befundung von Bilddaten eine unabdingbare Voraussetzung, dass die Bilddatensätze auch in der relevanten Perspektive auf einem Monitor zur Darstellung gebracht werden. Dabei sind die Auswahl der anatomischen Orientierung und einer Darstellungsart wichtige Faktoren. Medizinische Bilddaten werden von unterschiedlichen Akquisitionsgeräten, sogenannten Modalitäten, erfasst, wie beispielsweise Computertomographen, Magnetresonanztomographieanlagen, Positronen-Emissions-Tomographen etc. Durch die bildgebenden Geräte werden Bildrohdaten akquiriert, die dann durch unterschiedliche Bildverarbeitungsprozesse in zweidimensionale oder mehrdimensionale Bilder transformiert werden.
Dazu können beispielsweise multiplanare Rekonstruktionsverfahren (MPR-Verfahren) verwendet werden, um die dargestellten Bilddaten auch aus anderen Perspektiven bzw. Orientierungen auf dem Monitor zur Darstellung zu bringen. Je nachdem, welcher medizinische Vorgang durchzuführen ist (z.B. eine Differenzialdiagnose oder eine Befundung der akquirierten Bilddaten etc.), ist es notwendig, die jeweilige Perspektive bzw. Ansicht zu bestimmen, in der die akquirierten Bilddaten auf dem Monitor dargestellt werden sollen.
Bisherige Verfahren zur Bestimmung der jeweiligen Orientierung bzw. Perspektive, in der die Bilddaten zur Darstellung kommen sollen, basieren in der Regel auf der Darstellung eines Würfels oder eines anderen User-Interface-Elementes, über das der Benutzer nach einem Mausklick aus einer Liste von Texteinträgen wählen kann. Diese Verfahren haben den Nachteil, dass sie für User Interfaces, die durch direkte Manipulation gesteuert werden, also interaktive Benutzeroberflächen oder berührungssensitive Oberflächen (z.B. Touchscreens), nicht optimal sind. Dies ist darin begründet, weil eine Auswahl von textuellen, listenstrukturierten Menüs und Untermenüs für einen Touchscreen meist schwierig (da zu wenig präzise) zu bedienen ist. Weiterhin besteht ein Problem darin, dass die auszuwählenden Einträge auf einer textuellen Beschreibung der Perspektive basieren.
Möchte ein Benutzer beispielsweise einen dreidimensionalen MRT-Datensatz eines menschlichen Kopfes in transversaler Ansicht sehen, so werden ihm nach dem bisherigen Auswahlverfahren gemäß dem Stand der Technik Auswahlmenüs für die Bestimmung der Perspektive angeboten. Der Benutzer kann hier beispielsweise aus einer Listenstruktur bestimmte Einträge auswählen, um zu bestimmen, aus welcher Perspektive er die dreidimensionale Bildserie betrachten möchte. Da üblicherweise 5, 6 oder mehr Perspektiven zur Verfügung stehen, kann die Auswahl, insbesondere bei einem kleinen Bildschirm, schwierig sein.
Eine weitere Schwierigkeit ist darin zu sehen, dass die Listen-basierte Auswahl auf einer textuellen Nennung von medizinischen Fachausdrücken basiert (z.B. anterior -posterior, Head-Feet, oder bei Herzuntersuchungen: Vierkammerblick, Zweikammerblick etc.). Da diese Begriffe zum einen landessprachenspezifisch sind und zum anderen bestimmte Bilddaten, Untersuchungsarten und/oder Befundungsformen eine spezifische Auswahl von Perspektiven erfordern, sind hier je nach Modalität, Untersuchungsart und/oder Befundung unterschiedliche Konfigurationen notwendig, was das Produkt insgesamt aufwendig macht (da z.B. die Fachausdrücke in die jeweilige Landessprache übersetzt werden müssen und es leicht zu Verwechslungen bei der Auswahl von ähnlichen Menüeinträgen kommen kann und da bestimmte Perspektiven nur bei bestimmten Untersuchungen sinnvoll sind und bei anderen keinen Sinn machen; so ist es z.B. nicht sinnvoll bei einer orthopädischen Knieuntersuchung Perspektiven anzubieten, die für das Herz relevant sind (wie z.B. 2/4-Kammerblick)).
Ein signifikanter Nachteil von bekannten Verfahren nach dem Stand der Technik ist somit auch darin zu sehen, dass der Kontext der jeweiligen Untersuchung und/oder Befundung mit den jeweils akquirierten Bilddaten bei der Perspektivensteuerung bislang nicht berücksichtigt wird.
Von daher hat sich die vorliegende Anmeldung zur Aufgabe gestellt, einen Weg aufzuzeigen, mit dem die Steuerung des Rendering-Vorganges von medizinischen Bildern hinsichtlich der auszuwählenden Perspektiven verbessert werden kann. Insbesondere soll eine Perspektivenauswahl möglich sein, die auch für Touch-User-Interfaces verwendbar ist. Des Weiteren soll die Fehlerquote, die auf eine falsche Perspektivenauswahl zurückzuführen ist, verringert werden.
Diese Aufgabe wird durch ein Steuerungsverfahren zur Bestimmung von Perspektiven beim Rendern eines Bilddatensatzes gelöst, durch eine Steuerungseinheit und ein Computerprogramm und ein Computerprogrammprodukt gemäß den beiliegenden nebengeordneten Patentansprüchen.
Im Folgenden wird die Lösung der Aufgabe in Bezug auf das beanspruchte Verfahren beschrieben. Hierbei erwähnte Merkmale, Vorteile und/oder alternative Ausführungsformen sind ebenso auch auf die anderen beanspruchten Gegenstände zu übertragen und umgekehrt. Mit anderen Worten können auch die Steuerungseinheit und das Computerprogrammprodukt mit den Merkmalen weitergebildet sein, die im Zusammenhang mit dem Verfahren bzw. mit Merkmalen aus den Unteransprüchen zu dem Verfahren beschrieben und/oder beansprucht sind. Dabei entsprechen die funktionalen Merkmale des Verfahrens den entsprechenden gegenständlichen computerimplementierten Modulen, insbesondere Mikroprozessormodulen von Einheiten der Vorrichtung. Diese können beispielsweise in der Grafikkarte des Computersystems implementiert sein. Die Steuerungseinheit kann auch als eingebettetes System (embedded System) in eine Grafikkarte und/oder in ein computerimplementiertes Befundungssystem integriert sein.
Gemäß einem Aspekt der Erfindung bezieht sich die Aufgabenlösung auf ein computer-basiertes Steuerungsverfahren zur Auswahl von Perspektiven beim Rendern von medizinischen Bilddatensätzen in einer SOLL-Perspektive zur Darstellung auf einem Monitor. Das Verfahren umfasst folgende Verfahrensschritte:

– Erfassen des jeweiligen Bilddatensatzes und eines, dem Bilddatensatz zugeordneten Bildstatus. Alternativ ist es auch möglich, dass ein Bilddatensatz bereits auf dem Monitor dargestellt wird (in einer IST-Perspektive), die durch das Steuerungsverfahren zu ändern oder beizubehalten ist. In diesem Fall werden der dargestellte Bilddatensatz und der zugeordnete Bildstatus erfasst.
– Zugriff auf einen Speicher, in dem Regeln abgelegt sind, um eine Menge von auswählbaren Perspektiven in Abhängigkeit von dem erfassten Bildstatus zu bestimmen. Falls das Bild bereits auf dem Monitor dargestellt ist (siehe oben), wird zusätzlich die IST-Perspektive des bereits gerenderten Bildes bestimmt.
– Berechnen der Menge von auswählbaren Perspektiven, basierend auf dem Zugriff auf den Speicher. Dabei handelt es sich um eine Auswahl von für den jeweiligen Kontext der Bilddaten(anzeige) relevanten Perspektiven.
– Dynamisches Erzeugen eines interaktiven Symbols zur grafischen Repräsentation der berechneten Menge von auswählbaren Perspektiven. Vorzugsweise handelt es sich bei dem interaktiven Symbol um eine grafische bzw. bildhafte Repräsentation von Perspektiven, die auch ohne Textverständnis unmittelbar und intuitiv verständlich sind. Das erzeugte Symbol ist interaktiv. Es kann Schaltflächen umfassen, da es zum Erfassen von Eingabesignalen des Anwenders bestimmt ist. Insbesondere kann durch Betätigen eines Mausklicks ein bestimmter Bereich des Symbols aktiviert werden, der eine bestimmte Perspektive repräsentiert.
– Einblenden des interaktiven erzeugten Symbols auf einer Benutzeroberfläche zur Auswahl einer SOLL-Perspektive aus der mit dem Symbol repräsentierten berechneten Menge von auswählbaren Perspektiven.
– Erfassen eines Perspektivensteuerungssignals auf dem eingeblendeten, interaktiven Symbol zur Bestimmung der SOLL-Perspektive.
– Rendern des Bilddatensatzes in der bestimmten SOLL-Perspektive, basierend auf dem erfassten Perspektivensteuerungssignal.

Mit anderen Worten betrifft die Erfindung das Erzeugen eines Benutzeroberflächenelementes zur Steuerung eines Renderingprozesses, bei dem eine Perspektive zu bestimmen ist, aus der die Bilddaten gerendert werden sollen. Des Weiteren betrifft die Erfindung das Steuern des Renderings auf Basis von Interaktionen über das erzeugte Benutzeroberflächenelement. Bei dem Benutzeroberflächenelement handelt es sich um ein Symbol und nicht um textuelle Listenartig strukturierte Auswahlmenüs und ggf. mit Untermenüs. Das Symbol wird für jeden Vorgang Anwendungs-spezifisch und Bilddaten-spezifisch dynamisch generiert. Das Symbol kann Icons und/oder Buchstaben umfassen. Bei den Buchstaben kann es sich um Einzelbuchstaben oder Buchstabenkombinationen handeln, die jedoch an sich keinen Texteintrag (z.B. kein eigenes Wort oder Wortkombination) bilden. Das Symbol kann zumindest ein Sensorelement umfassen. Das Sensorelement kann ein berührungsempfindlicher Benutzeroberflächensensor sein. Das Symbol umfasst in der bevorzugten Ausführungsform der Erfindung Schaltflächen, die als I/O-Schaltflächen zur Interaktion aktiviert werden können. Die Größe und/oder Form des Symbols und/oder der Schaltflächen kann konfiguriert werden. Das erfindungsgemäße Steuerungsverfahren bzw. die Steuerungseinheit interagiert (bzw. tauscht digitale Daten) mit einem Symbolprozessor, in dem Regeln, Daten und ein Prozessor zur Verarbeitung Symbol-bezogener und/oder Perspektiven-bezogener Daten vorgehalten werden.
Im Folgenden werden die im Rahmen dieser Anmeldung verwendeten Begrifflichkeiten näher erläutert.
Das Verfahren dient zur Bestimmung von Perspektiven beim Rendern von Bildern. Damit wird eine Orientierung, in der die Bilder auf dem Monitor dargestellt werden, bestimmt. Erfindungsgemäß wird zwischen einer IST-Perspektive und einer SOLL-Perspektive unterschieden. Der Begriff „IST-Perspektive“ bezieht sich auf die Perspektive des aktuell dargestellten Bildes bzw. Bilddatensatzes. In diesem Fall (falls also bereits ein Bild in einer Perspektive auf dem Monitor dargestellt ist) wird das Verfahren als Perspektivenwechselverfahren angewendet, um zukünftige Perspektiven bei der Darstellung zu bestimmen. Falls ein solches Bild noch nicht auf dem Monitor dargestellt ist, wird das Verfahren als initiales Steuerungsverfahren zur Bestimmung der (ersten) Perspektive verwendet. Die SOLL-Perspektive wird vom Anwender ausgewählt und dient zur Berechnung des Bilddatensatzes. Es kann selbstverständlich auch sein, dass die IST-Perspektive mit der SOLL-Perspektive übereinstimmt, dann wird dem User zwar ein Perspektivenwechsel über die Einblendung des Symbols angeboten, das er aber nicht nutzt, um bei der ursprünglichen Perspektive zu bleiben.
Bei der Berechnung des Bilddatensatzes können beispielsweise unterschiedliche Rekonstruktionsverfahren, insbesondere die multiplanare Rekonstruktion, zur Anwendung kommen. Alternativ können auch Projektionsverfahren, wie beispielsweise die Maximum-Intensitätsprojektion (maximum-intensity-projection – MIP) oder die minimum-intensity-projection (mIP) verwendet werden, um rekonstruierte Schichtaufnahmen (beispielsweise aus einer MRT-Aufnahme) zu erzeugen. Moderne Rekonstruktionsverfahren sind dabei nicht auf die drei Raumachsen bei der Auswahl der Perspektive beschränkt, sondern können auch nicht orthogonale Ebenen als Perspektive bestimmen, um bestimmte anatomische Strukturen darstellen zu können, die sonst durch andere Gewebestrukturen verdeckt werden würden. Insbesondere im Rahmen der Befundung ist es ganz wesentlich, die richtige Perspektive zu bestimmen, um alle medizinisch relevanten Daten auch zur Anzeige bringen zu können.
Gemäß einer bevorzugten Ausführungsform der Erfindung bezieht sich diese auf die Darstellung von medizinischen Bilddatensätzen, die von unterschiedlichen Modalitäten (CT, MRT, Ultraschall, PET etc.) akquiriert worden sind. Dabei kann es sich um zweidimensionale, dreidimensionale oder höherdimensionale Bilddatensätze handeln. Die darzustellenden Bilddaten können auch von einer Herzuntersuchung (z.B. einer Herzkathederuntersuchung) stammen oder mit funktionalen Verfahren akquiriert worden sein (z.B. fMRT oder SPECT etc).
Der „Bildstatus“ bezeichnet einen Vektor mit unterschiedlichen Parametern. Insbesondere umfasst der Bildstatus Daten bzw. Angaben über die jeweilige Modalität der Bilddaten (CT, MRT, Ultraschall etc.), die Art bzw. den Zweck der Bildsichtung (einerseits: inhaltliche Befundung, andererseits: rein formelle, kursorische Sichtung des Bilddatensatzes auf Fehler oder Überprüfung dahingehend, ob diese überhaupt vorliegen und/oder gespeichert wurden). Der Bildstatus umfasst darüber hinaus vorzugsweise Angaben über das jeweils untersuchte Organ (z.B. Herz, Knie, Leber, gesamter Unterbauch etc.). Des Weiteren kann der Bildstatus auch eine Position der Bilddaten im menschlichen Körper bezeichnen. Dabei kann es sich um eine anatomische Angabe handeln. Diese Position gibt dann beispielsweise an, dass die Bilddatensätze aus einer anatomischen Struktur stammen, die sich im Kopf des Patienten oder beispielsweise im Bein des Patienten befindet. Aus diesen Angaben können dann – vorzugsweise automatisch – weitere Daten abgeleitet werden, die für die Auswahl der jeweiligen Perspektive relevant sind. In einer bevorzugten Ausführungsform werden auch Metadaten der jeweiligen Bilddatensätze analysiert, insbesondere dann, wenn die Daten im DICOM-Format vorliegen (DICOM: Digital Information and Communications in Medicine).
In einer bevorzugten Ausführungsform umfasst somit das Erfassen des Bildstatus weitere automatisch ausgeführte Verfahrensschritte. Insbesondere werden einzelne Parameter des Bildstatus aus anderen Daten abgeleitet, wie z.B. aus den Metadaten. Dazu kann auf eine Regelbasis zurückgegriffen werden, die beispielsweise in einem bestimmten Speicher (lokal oder remote) abgelegt sind.
Der Bildstatus umfasst somit Angaben in Bezug auf die Modalität, mit der die Bilddaten akquiriert worden sind, auf die Art der Untersuchung, auf das untersuchte Organ, auf die Art der Befundung, auf die Position und/oder auf dem Kontext der Bilddaten. Somit wird erfindungsgemäß erfasst, ob es sich bei den Bilddaten z.B. um Bilddaten einer Herzuntersuchung oder um rekonstruierte MRT-Bilddaten einer Knieuntersuchung handelt. Dieser Bildstatus hat signifikanten Einfluss auf die auswählbaren Perspektiven bei der nachfolgenden Darstellung.
Gemäß einer bevorzugten Ausführungsform ist eine Konfigurationsphase vorgesehen, die der Perspektivenbestimmungs- oder Ausführphase vorgelagert ist und in der konfiguriert werden kann, welche Parameter für den Bildstatus zu berücksichtigen sind. Vorzugsweise sind bestimmte Parameter vorkonfiguriert, die für die Berechnung des Bildstatus herangezogen werden. Diese umfassen zumindest: Die Position des untersuchten Organs bzw. die anatomische Struktur, die Art der akquirierenden Modalität bzw. die Art der akquirierten Bilddaten, die Art der Befundung.
Vorzugsweise ist es vorgesehen, dass der Bildstatus automatisch berechnet wird, ohne dass Benutzereingaben erforderlich sind.
Unter anderem aus diesem Bildstatus wird eine Menge von auswählbaren Perspektiven berechnet. Hier fließt beispielsweise ein, dass bei Herzuntersuchungen typischerweise Perspektiven entlang der Achsen (kurze Achse oder lange Achse) bzw. ein Zweikammerblick oder ein Vierkammerblick gewählt werden, während bei einer organischen, orthopädischen Untersuchung die Angabe „L“ (für left/links) oder „R“ (für right/rechts) gewählt wird. Es liegt auf der Hand, dass die Angaben Rechts/-Links bei einer Herzuntersuchung keinen Sinn machen und umgekehrt. Mit anderen Worten muss die Art der Untersuchung und die Art der erfassten Bilddaten Einfluss auf die Auswählbarkeit der Perspektiven haben. Vorteilhafterweise wird dies erfindungsgemäß berücksichtigt. Dies hat den Vorteil, dass der Anwender nicht mit unnötigen bzw. irrelevanten Perspektivenauswahlanfragen oder -optionen konfrontiert ist. Er kann somit nur aus relevanten Perspektiven auswählen bzw. eine SOLL-Perspektive bestimmen. Damit können darüber hinaus Fehler durch falsche Perspektivenbestimmungen vermieden werden.
Bei der „Menge von auswählbaren Perspektiven“ handelt es sich um eine Auswahl von Perspektiven. Diese Menge ist Bilddatensatz-spezifisch und/oder Untersuchungs-spezifisch. Mit anderen Worten wird diese Menge auf den jeweiligen Fall der darzustellenden Bilddaten abgestellt und kennzeichnet die Auswahl von relevanten Perspektiven. So werden beispielsweise bei einer Herzkatheteruntersuchung nicht die Perspektiven „Rechts“ / „Links“ angeboten und umgekehrt werden bei einer bildlichen Darstellung des Femur beispielsweise nicht die Perspektiven „vertikale lange Achse“ / „horizontale lange Achse“ / „kurze Achse“ angeboten. Entsprechendes gilt für andere anatomische Strukturen, andere Untersuchungen und/oder andere medizinische Fragestellungen.
Grundsätzlich sind zwei unterschiedliche Anwendungsszenarien bei dem erfindungsgemäßen Perspektivensteuerungsverfahren vorgesehen:

1. Steuerung eines initialen Renderings: In diesem Anwendungsmodus ist es vorgesehen, dass grundsätzlich vor der ersten Darstellung der Bilder die jeweilige Perspektive für die Darstellung ausgewählt wird. In diesem Fall bestimmt sich die Menge der auswählbaren Perspektiven aus der Gesamtmenge aller für den Anwendungsfall relevanten Perspektiven.
2. Ausführen eines Perspektivenwechsels: In diesem Fall sind die Bilddaten bereits in einer Perspektive, der sogenannten IST-Perspektive auf dem Bildschirm dargestellt und es soll nun ein Perspektivenwechsel in eine andere Perspektive ausgeführt werden. Um nicht unnötige Anzeigen auf dem Bildschirm zu generieren, ist es in einer bevorzugten Ausführungsform vorgesehen, dass die Menge von auswählbaren Perspektiven bestimmt wird, wobei die IST-Perspektive nicht berücksichtigt wird, da diese bereits aktuell verwendet wird und ein Wechsel nur auf andere Perspektiven sinnvoll ist. In diesem Fall kann für den Verfahrensschritt des Berechnens der Menge von auswählbaren Perspektiven die IST-Perspektive mit berücksichtigt werden, neben dem Bildstatus und möglicherweise noch weiteren Datensätzen. Alternativ kann die IST-Perspektive auch hervorgehoben als aktuell verwendete Perspektive gekennzeichnet werden.

Erfindungsgemäß wird die berechnete Menge von auswählbaren Perspektiven nicht mehr, wie im Stand der Technik vorgesehen, in Form einer Listenstruktur bzw. in Form eines Menüs auf dem Bildschirm zur Anzeige gebracht, sondern in Form eines Symbols. Das Symbol repräsentiert in grafischer Form die berechnete Menge von auswählbaren Perspektiven. Das Symbol umfasst Schaltfläche mit einer grafischen und/oder textuellen Kurzdarstellung von Perspektiven. Dabei kann eine Perspektive in Form einer schematischen bildlichen Kurzdarstellung repräsentiert sein, beispielsweise in Form einer schematischen Vorderansicht, Seitenansicht oder Rückansicht eines Patienten. Das Symbol kann auch kumulativ zur grafisch-bildlichen Darstellung eine textuelle Kennzeichnung umfassen, beispielsweise in der Art „back“ / „posterior“ / „rück“. Das Symbol kann auch als Icon oder Piktogramm repräsentiert sein. Es umfasst eine Schaltfläche zum Empfang von Steuerungsbefehlen. Die Steuerungsbefehle können vom Benutzer eingegeben werden. Je nach Ausführungsform können unterschiedliche Funktionen der Schaltfläche des Symbols vorgesehen sein. So kann beispielsweise eine Schaltfläche des Symbols durch einen einfachen Mausklick oder durch einen Doppelklick schaltbar sein. Je nach Konfiguration können hier auch andere Funktionalitäten gewählt werden, so dass beispielsweise das Symbol auch durch eine Tastaturbedienung schaltbar ist. Ebenso kann das Symbol auch durch eine Druck- und/oder Wischgeste auf einem Touch Screen aktiviert werden. Vorzugsweise umfasst das Symbol also alle auswählbaren Perspektiven für den jeweiligen Anwendungsfall und damit alle relevanten Perspektiven aus der berechneten Menge von auswählbaren Perspektiven.
Gemäß einer bevorzugten, alternativen Ausführungsform der Erfindung kann zusätzlich zum Berechnen der Menge von Perspektiven noch ein weiterer Selektionsvorgang hinzu geschaltet werden. In dem zweiten Selektionsvorgang kann aus der Menge von auswählbaren Perspektiven eine zweite Menge von auswählbaren Perspektiven bestimmt werden, die die Auswahlmöglichkeiten noch weiter auf den jeweiligen Anwendungsfall hin limitiert. Hier kann beispielsweise die aktuelle IST-Perspektive berücksichtigt werden, die nicht zur Auswahl zur Verfügung stehen soll. Des Weiteren kann die Auswahl für die zweite Menge von auswählbaren Perspektiven auf einer syntaktischen und/oder semantischen Auswahl von Bildstatusdaten und/oder anderen Metadaten basiert sein.
Gemäß einem Aspekt der Erfindung kann ein Triggersignal bereitgestellt werden, das dem Computersystem signalisiert, dass ein neues Bild bzw. eine neue Bildfolge zur Darstellung gebracht werden soll. Beispielsweise kann dies nach einem Ladevorgang für Bilddaten automatisch ausgelöst werden. Gemäß einer bevorzugten Ausführungsform ist es vorgesehen, dass das interaktive Symbol erst nach Erfassen des Triggersignals auf der Benutzeroberfläche eingeblendet wird. Dies hat den Vorteil, dass das Symbol nicht unnötigerweise auf dem Bildschirm erscheint und den Benutzer von anderen Aufgaben ablenkt. Somit erscheint das Symbol in diesem Fall nur dann, falls der Benutzer auch tatsächlich eine Perspektive beim Rendern von Bilddaten auswählen muss. Das Triggersignal kann beispielsweise durch Berührung des Symbols selbst aktiviert werden oder nach einer Berührung einer entsprechenden Schaltfläche zur Darstellung von Bilddaten.
Ein wesentlicher Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass das erzeugte interaktive Symbol intuitiv verständlich ist und auch ohne textuelle Erklärungen bedienbar wird. Damit können beispielsweise auch aufwändige Übersetzungen der textuellen Einträge in anderen Sprachen unterbleiben.
Das Symbol wird vorzugsweise so auf der Benutzeroberfläche eingeblendet, dass es einen bereits dargestellten Bilddatensatz in der IST-Perspektive überlagert. Vorzugsweise ist es vorgesehen, dass die Eingabe eines Perspektivensteuerungssignals notwendig ist, um den Bilddatensatz zu rendern. Falls der Benutzer kein entsprechendes Perspektivensteuerungssignal eingibt, kann es vorgesehen sein, dass er hierzu durch eine Aufforderung (z.B. in einem Popup-Fenster) aufgefordert wird.
Bei dem Perspektivensteuerungssignal kann es sich um einen Mausklick oder um ein anderes benutzerseitiges Eingabesignal handeln.
In einer bevorzugten Ausführungsform wird das Perspektivensteuerungssignal durch eine benutzerseitige Aktion gesteuert bzw. aktiviert. Vorzugsweise handelt es sich um einen Mausklick oder um eine Eingabe auf einer entsprechenden Eingabevorrichtung. Alternativ kann es sich auch um eine Folge von Eingabesignalen handeln, die in der Konfigurationsphase definiert wird. Dies bringt den Vorteil, dass der Benutzer durch eine einfache Aktion, insbesondere durch einen Mausklick, das Perspektivensteuerungssignal eingeben kann, aufgrund dessen dann das Rendern des Bilddatensatzes ausgeführt wird. Bestimmte Anwendungen ermöglichen es, dass nicht der Benutzer das Perspektivensteuerungssignal über eine bereitgestellte Mensch-Maschine-Schnittstelle eingeben muss, sondern dass das Perspektivensteuerungssignal automatisch aus anderen Daten abgeleitet werden kann. Wenn beispielsweise eine Studie, die mehrere Serien umfasst, zur Darstellung gebracht werden soll und das Perspektivensteuerungssignal für die Serie bereits erfasst ist, so kann diese Perspektive auch für die anderen Serien der Studie übertragen werden. Damit wird eine erneute Eingabe des Perspektivensteuerungssignals durch den Benutzer nicht mehr notwendig und die Perspektive kann somit automatisch aus den analysierten Datensätzen abgeleitet werden. Alternativ kann das Perspektivensteuerungssignal auch aus anderen Datensätzen automatisch abgeleitet werden. Dies kann z.B. dann angewendet werden, wenn eine Ganzkörperaufnahme einer „Composed“ Serie gesichtet werden soll (also z.B. ein Full Body Scan bei MR- oder PET-Untersuchungen, der aus mehreren Stationen / Etagen besteht). Dort wählt der Benutzer z.B. das Abdomen aus. Gemäß einer bevorzugten Ausführungsform der Erfindung der Erfindung bietet das System ihm dann Auswahlmöglichkeiten an, aus welcher Perspektive er die Abdomen Aufnahmen sehen möchte. So kann der Anwender einerseits den Überblick über den Full Body Scan behalten und andererseits dort spezifisch in eine Körperregion (z.B. Abdomen) in einer bestimmten Perspektive schnell hingelangen.
In einer bevorzugten Ausführungsform kann es jedoch sinnvoll sein, den Benutzer über die aktuell verwendete Perspektive, also die IST-Perspektive, zu informieren. In diesem Fall umfasst das Symbol auch die Repräsentation der IST-Perspektive neben der Menge der auswählbaren Perspektiven, die als Grundlage für die SOLL-Perspektive verwendet werden können. Vorzugsweise ist die aktuell verwendete IST-Perspektive hervorgehoben dargestellt, beispielsweise in Fettdruck oder dick umrandet oder mit sonstigen Markierungselementen versehen.
Gemäß einem Aspekt der Erfindung ist es vorgesehen, dass das Symbol nur für ein bestimmtes Zeitintervall auf dem User Interface dargestellt wird. Falls nach einem vor-konfigurierbaren Zeitintervall keine Benutzerinteraktion auf dem Symbol ausgeführt wird, kann das Symbol automatisch ausgeblendet werden, um den Benutzer nicht unnötig abzulenken.
Ein Vorteil des erfindungsgemäßen Verfahrens ist darin zu sehen, dass es sowohl für eine Mausinteraktion als auch für eine Touch-Screen-Interaktion anwendbar ist. Des Weiteren kann das Verfahren durch die grafische bzw. symbolhafte Repräsentation der Perspektiven sehr leicht für andere Landessprachen übertragen und internationalisiert werden. Ein wesentlicher Vorteil ist jedoch in der Kontext-spezifischen Auswahl von Perspektiven zu sehen. Der Vorteil ist darin begründet, dass das interaktive Symbol jeweils dynamisch erzeugt und dargestellt wird. „Dynamisch“ meint in diesem Zusammenhang, dass das Symbol auf den jeweiligen Anwendungsfall bezogen ist und somit Anwendungs-spezifisch bzw. Kontext-spezifisch ist. Dabei können unter anderem sowohl die Untersuchungsart, die jeweilige klinische Fragestellung, anatomische Positionsangaben, bisherige Aktionen und/oder explizite Auswahlvorgaben berücksichtigt werden.
Demnach wird beispielsweise für die Darstellung von Bildern einer Herzuntersuchung ein anderes Symbol eingeblendet als dasjenige bei einer Darstellung von Bildern einer orthopädischen Befundung.
Die Darstellung des Perspektivenauswahlsymbols kann auch „in-place“ und sozusagen an einer frei wählbaren, aber möglicherweise fixen Position auf dem Bildschirm erfolgen, auf dem die Bilddaten dargestellt werden – und sozusagen „innerhalb“ der dargestellten Bilddaten. Es ist auch möglich, dass die Auswahl alternativ oder kumulativ durch eine direkte Manipulation auf dem angezeigten Bild ausgeführt wird, beispielsweise mittels Mausinteraktion oder durch eine Touch-Geste, wie z.B. einem Long-press.
Dabei kann vorzugsweise in einer Konfigurationsphase festgelegt werden, ob das Perspektivensteuerungssignal durch das Symbol und/oder durch eine direkte Eingabe auf der Oberfläche ausgelöst werden soll (z.B. durch eine Wischgeste auf dem Touchscreen).
Gemäß einer bevorzugten Ausführungsform umfasst das Symbol zusätzlich einen auswählbaren Rendermodus, der beim Rendern und/oder beim Anzeigen des Bilddatensatzes in der SOLL-Perspektive berücksichtigt wird. Damit kann auch der „Rendermode“ eine zusätzliche Selektion bei der nachfolgenden Darstellung der Bilder sein (neben der Bestimmung der Perspektive). Der Rendermodus bezieht sich beispielsweise auf die Art der Darstellung von bestimmten Bildinhalten. So kann es beispielsweise eingestellt werden, dass Gefäße sagittal in einer VRT- oder MIP-Technik dargestellt werden sollen (VRT: volume rendering technique; MIP: maximum intensity projection).
Die sogenannte In-Place-Perspektivenbestimmung kann über einen anatomischen Kontext gesteuert sein. Möchte ein Benutzer beispielsweise eine Leber befunden, so werden ihm erfindungsgemäß z.B. transversale Schnitte eines Abdomens auf dem Monitor angezeigt. Über eine Auswahl der Leberbilder selbst kann der Benutzer die für die jeweilige Befundungsaufgabe sinnvollen Perspektiven und Rendermodi ansteuern. Üblicherweise werden dafür fiktive, verallgemeinerte und/oder thematische Darstellungen der Bilder (hier: Abdomen) angezeigt. Damit wird es möglich, das Perspektivensteuerungssignal direkt und unmittelbar auf der jeweiligen Bilddarstellung zu manipulieren bzw. einzugeben, ohne dass ein separates Menü oder das Einblenden des Symbols erforderlich ist.
Vorzugsweise erfolgt das Rendern des Bilddatensatzes in der bestimmten SOLL-Perspektive aus einem Speicher, insbesondere dem Framebuffer. Gemäß einer Variante endet das Verfahren nach dem Rendern des Bilddatensatzes in der bestimmten SOLL-Perspektive. Alternativ kann auf einen bestimmten Befehl hin die Anzeige des gerenderten Bilddatensatzes auf zumindest einem Monitor ausgeführt werden.
Neben dem vorstehend beschriebenen Verfahren wird die Aufgabe der Erfindung auch gelöst durch eine Steuerungseinheit, die unter anderem als Grafikprozessor in einer Grafikkarte implementiert sein kann.
Die einzelnen Module bzw. Einheiten der Steuerungseinheit sind dazu bestimmt, die Funktionen auszuführen, die vorstehend im Zusammenhang mit der Beschreibung des Verfahrens beschrieben worden sind.
Die Steuerungseinheit dient zur Bestimmung von Perspektiven beim Rendern eines Bilddatensatzes in einer SOLL-Perspektive auf einem Anzeigegerät bzw. auf einem Monitor.
Die Steuerungseinheit umfasst eine Erfassungseinheit, einen Speicher, eine Berechnungseinheit, eine Symboleinheit und eine Rendering-Einheit.
In komplexeren Ausbildungen der Steuerungseinheit kann diese noch weitere Module umfassen, um die weiteren Funktionalitäten zu implementieren, die vorstehend im Zusammenhang mit der Beschreibung des erfindungsgemäßen Verfahrens beschrieben worden sind.
Es liegt ebenso im Rahmen der Erfindung die vorstehend erwähnten Schritte des Verfahrens nicht zwangsläufig in der vorstehend beschriebenen Reihenfolge zur Ausführung zu bringen. Ebenso ist es möglich, bestimmte Verfahrensschritte zu kombinieren bzw. zu einem Schritt zusammenzulegen. Beispielsweise kann das dynamische Erzeugen des Symbols und das Einblenden des erzeugten interaktiven Symbols in einem einzigen Verfahrensschritt ausgeführt werden.
Gemäß der bevorzugten Ausführungsform werden nahezu alle Verfahrensschritte automatisch (also ohne Benutzerinteraktion) ausgeführt. Die einzige Benutzerinteraktion besteht in der Eingabe des Perspektivensteuerungssignals auf dem interaktiven Symbol (etwa durch Mausklick oder sonstige Eingabe). In anderen Ausführungsformen der Erfindung ist diese manuelle Eingabe jedoch nicht erforderlich und das Perspektivensteuerungssignal wird automatisch aus anderen Datensätzen, insbesondere dem Bildstatus, abgeleitet. Alle weiteren Verfahrensschritte werden automatisch ausgeführt.
Darüber hinaus ist es möglich, das Verfahren als Client-Server-System auszubilden, so dass einzelne Abschnitte des vorstehend beschriebenen Verfahrens auf einer Instanz und die restlichen Abschnitte des Verfahrens auf einer anderen Instanz ausgebildet werden können. Bei den Instanzen kann es sich um jeweils getrennte, separat verkaufsfähige Einheiten (insbesondere Computerprogrammprodukte) handeln. Damit kann das erfindungsgemäße Verfahren als verteiltes System auf unterschiedlichen computer-basierten Instanzen (z.B. Client-Server-Instanzen) ausgeführt werden. Bezogen auf die vorrichtungsgemäße Lösung können einzelne Einheiten in dem Grafikprozessor und andere Einheiten in anderen Prozessormodulen ausgebildet sein.
Eine weitere Lösung der vorstehenden Aufgabe bezieht sich auf ein Computerprogrammprodukt gemäß dem beiliegenden Anspruch. Eine weitere Aufgabenlösung sieht ein Computerprogramm vor, das Computerbefehle umfasst. Die Computerbefehle können auf einem Speicher eines Computers gespeichert sein und umfassend vom Computer lesbare Befehle, die zur Ausführung des vorstehend beschriebenen Verfahrens bestimmt sind, wenn die Befehle auf dem Computer ausgeführt werden. Das Computerprogramm kann auch auf einem Speichermedium gespeichert sein. Dabei kann es als ausführbares Programm oder als Objektcode gespeichert sein. Alternativ kann das Programm auch über ein entsprechendes Netzwerk von einem Server heruntergeladen werden.
In der nachfolgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen. In dieser zeigen:
1 eine schematische, übersichtsartige Darstellung über eine erfindungsgemäße Steuerungseinheit und weitere computer-basierte Instanzen gemäß einer bevorzugten Ausführungsform der Erfindung,
2 ein Ablaufdiagramm gemäß einer bevorzugten Ausführungsform der Erfindung,
3 eine beispielhafte Darstellung eines Symbols gemäß einer Ausführungsform der Erfindung und
4 eine beispielhafte Darstellung des Symbols anhand einer zweiten beispielhaften Ausführungsform der Erfindung.
Im Folgenden wird die Erfindung näher unter Bezugnahme auf die Figuren erläutert.
Die Erfindung bezieht sich auf das Steuern eines Rendering-Prozesses zur Darstellung von medizinischen Bilddaten BD. Die medizinischen Bilddaten BD können von unterschiedlichen bildgebenden Akquisitionsgeräten erfasst worden sein (z.B. CT-, MRT-, Ultraschall-Geräten etc.). Je nach Art der Modalität und nach Art der Befundung sollen zwei-, dreidimensionale oder mehrdimensionale Bilddatensätze BD gerendert werden. Dazu ist es erforderlich, dass der Benutzer in Abhängigkeit von dem spezifischen Kontext, der sich unter anderem aus der Art der Bilder und der Art der Befundung und/oder aus dem untersuchten Organ ergibt, eine bestimmte Perspektive bzw. Orientierung und Darstellungsart auswählt, damit die Bilddaten BD auf einem Monitor M zur Darstellung gebracht werden können.
Nach Start des Systems wird in Schritt A zunächst der Bilddatensatz BD erfasst. Des Weiteren wird in dem Schritt A ein Bildstatus erfasst, der dem Bilddatensatz zugeordnet ist. Der Bildstatus erfasst alle Parameter, die zur Definition des Kontextes relevant sind. Hierzu zählen unter anderem die bildgebende Modalität, die Art der Untersuchung (z.B. Herzkatheteruntersuchung etc.) und das untersuchte Organ. Das Herz, eine orthopädische Untersuchung des Knies etc.), die Art der Befundung und die anatomische Position. Des Weiteren können weitere Kontextdaten der Bilddaten erfasst werden. In einer bevorzugten Ausführungsform werden die Bildstatusdaten aus den Metadaten zu den Bilddaten abgeleitet. Die Bilddaten BD liegen vorzugsweise in einem DICOM-Format vor und umfassen neben den reinen Bilddaten auch Header-Daten. Aus den Header-Daten können dann die Bildstatusdaten automatisch abgeleitet werden. Vorzugsweise wird dieser Bildstatus und damit auch ein Kontext der Bilddaten bei der Auswahl der Perspektive beim Rendern der Bilddaten BD berücksichtigt.
In einem zweiten Verfahrensschritt B erfolgt ein Zugriff auf einen Speicher MEM, in dem Regeln und möglicherweise weitere Daten abgelegt sind. Vorzugsweise umfasst der Speicher MEM Regeln, die angeben, welche grundsätzlich möglichen und auswählbaren Perspektiven zu einem Bildstatus gehören. Diese Regeln werden vorzugsweise in einer Konfigurationsphase definiert. Diese Konfigurationsphase ist der Ausführungsphase vorgelagert. In der Konfigurationsphase kann bestimmt werden, welche Parameter als Bildstatus erfasst und berücksichtigt werden. Des Weiteren können die Regeln definiert werden, die einem Bildstatus eine Menge von Perspektiven zuordnen. So kann beispielsweise definiert werden, dass bei Herzuntersuchungen und der Verwendung einer 90°-basierten Herz-Ebenenbenennung folgende Perspektiven wählbar sein sollen: Kurze Achse, vertikale lange Achse und horizontale lange Achse. Diese Begriffe entsprechen einem sogenannten Zweikammerblick bzw. einem Vierkammerblick bei der traditionellen zweidimensionalen Echokardiographie. Bei einer Untersuchung des Herzens kann mit dem erfindungsgemäßen Perspektivensteuerungsverfahren ausgeschlossen werden, dass nicht relevante bzw. nicht anwendbare Perspektiven auch nicht auswählbar sind und somit auch nicht auf einem User Interface UI erscheinen. Beispielsweise macht es bei einer Herzuntersuchung keinen Sinn, zwischen „Rechts“ und „Links“ zu wählen.
In Schritt C wird die Menge von auswählbaren Perspektiven berechnet. Dabei wird vorzugsweise auf die Regeln zurückgegriffen, die im Speicher MEM abgelegt sind. Mit anderen Worten erfolgt das Berechnen der Menge von auswählbaren Perspektiven auf dem erfassten Bildstatus, der den jeweiligen Bilddatensatz BD zugeordnet ist. Damit ist auch die Menge von auswählbaren Perspektiven Kontext-spezifisch.
In Schritt D wird dynamisch ein interaktives Symbol S erzeugt. Das Symbol S dient zur grafischen Repräsentation der berechneten Menge von auswählbaren Perspektiven.
An dieser Stelle ist hervorzuheben, dass das interaktive Symbol S jeweils dynamisch erzeugt wird. Je nachdem welcher Bilddatensatz gerendert und/oder angezeigt werden soll, erscheint ein spezifisch angepasstes Symbol S. Das Symbol S umfasst eine grafische Repräsentation der berechneten Menge von auswählbaren Perspektiven. Somit werden also nur die relevanten Perspektiven als Symbol S zur Auswahl angezeigt, die in dem jeweiligen Kontext der Bilddaten BD sinnvoll sind. „Dynamisch“ bedeutet also auch, dass das Symbol S unterschiedliche Schaltflächen hat, die die auswählbaren Perspektiven repräsentieren. Unterschiedliche Bilder und/oder unterschiedliche Anwendungen haben also auch unterschiedliche Symbole S.
Im Schritt E erfolgt das Einblenden des erzeugten, interaktiven Symbols S auf der Benutzeroberfläche UI. Das Symbol S ist interaktiv, so dass der Benutzer durch Aktivierung bestimmter Schaltflächen auf dem Symbol S eine Perspektive als SOLL-Perspektive aus der Menge von auswählbaren Perspektiven bestimmten kann.
Daraufhin erfolgt in Schritt F das Erfassen des Perspektivensteuerungssignals. Das Perspektivensteuerungssignal bezieht sich auf die Interaktion auf dem Symbol S. Je nachdem, welche Schaltfläche der Anwender auf dem Symbol S ausgewählt hat, wird ein spezifisches Perspektivensteuerungssignal erzeugt, das dazu führt, dass dieses Signal an eine Rendering-Einheit weitergegeben wird, die zum Rendern des Bilddatensatzes BD in der bestimmten SOLL-Perspektive bestimmt ist. Das Rendern erfolgt in Verfahrensschritt G und basiert auf dem erfassten Perspektivensteuerungssignal.
Nach dem Rendern in Schritt G und/oder nach einer Anzeige der Bilddaten BD in der SOLL-Perspektive in Schritt H kann das Verfahren iterativ fortgesetzt werden. Dies ist in 2 dadurch gekennzeichnet, dass alternativ zur Beendigung des Verfahrens der Vorgang auch erneut bei Schritt A beginnen kann.
Grundsätzlich ist die Anzeige des gerenderten Bilddatensatzes BD optional und nicht zwingend erforderlich. Es ist ebenso möglich, dass das Verfahren nach dem Rendern G des Bilddatensatzes BD endet. Vorzugsweise werden die gerenderten Bilddaten BD in einen Framebuffer geschrieben.
Das Symbol S wird vorzugsweise so erzeugt, dass die jeweilige Perspektive alleine aus der grafischen Darstellung (oder der Darstellung als Piktogramm) verständlich ist. Dies hat den Vorteil, dass die Perspektivenauswahl intuitiv und leicht verständlich ist, ohne dass ein zugehöriger Text gelesen und/oder übersetzt werden muss. Alternativ kann die grafische Darstellung der Schaltflächen des Symbols S auch noch durch textuelle Angaben angereichert sein. Die textuellen Angaben können einzelne Buchstaben (z.B. „R“ für Rechts/right oder „H“ für head/Kopf etc.) sein, die als Kurzkennzeichnung dienen.
Ein Beispiel einer Darstellung des Symbols S findet sich in 3. Das Symbol S umfasst in dieser Ausführungsform sechs Schaltflächen, die um einen zentralen Perspektivenwürfel angeordnet sind. Der Perspektivenwürfel dient zur Kennzeichnung der drei Raumachsen, die in diesem Fall mit „H“ (Kopf), „R“ (für right/Rechts) und „F“ (für front/Vorderseite) bezeichnet sind. Die Schaltflächen des Symbols S umfassen die Perspektiven, die für den jeweiligen Kontext relevant sind. In diesem Fall umfasst das Symbol S sechs Schaltflächen, die folgendermaßen gekennzeichnet sind:

– R – für rechtes Profil
– P – für posterior bzw. Rückenansicht
– F – für feet/Füße
– A – für anterior bzw. Vorderansicht
– L – für linkes Profil und
– H – für head bzw. Ansicht des Kopfes.

Wie in 3 schematisch dargestellt, können die einzelnen Schaltflächen des Symbols S per Tastendruck auf einem Touchscreen bedient werden. Alternativ können die Schaltflächen des Symbols S auch auf einem herkömmlichen Monitor M dargestellt werden und über Mausklicks oder andere Eingaben (z.B. Tastatur) bedient werden. Dabei können die Größe der einzelnen Schaltflächen und die Größe des Symbols S insgesamt in einer Konfigurationsphase bestimmt werden.
Alternativ zur Darstellung des Symbols S, die in 3 dargestellt ist, ist es erfindungsgemäß ebenso möglich, auf die Darstellung des Perspektivenkubus zu verzichten, so dass das Symbol S nur die sechs Schaltflächen umfasst, die interaktiv gestaltet sind und unmittelbar durch Berühren bedient bzw. aktiviert werden können.
Eine weitere Alternative besteht darin, auf die Buchstabennennungen in den Schaltflächen zu verzichten, so dass die Schaltflächen nur aus der grafischen Darstellung der Perspektive bzw. Orientierung oder Ansicht bestehen.
In einer weiteren Alternative ist es möglich, die textuellen Einblendungen nicht nur anhand von einzelnen Buchstaben vorzusehen, sondern hier einen vollständigen Fachbegriff zu verwenden (wie beispielsweise „anterior“, „posterior“ etc.). Alternativ können die textuellen Zuordnungen zu den grafischen Symbolen auch in Form einer Legende auf einem separaten Fenster auf dem Monitor M dargestellt werden.
4 zeigt das Symbol S in einem anderen Kontext. Hier ist der Kontext eine Herzuntersuchung, so dass das Symbol S andere Orientierungen umfasst. In diesem Kontext bzw. bei diesem Bildstatus wird folgende Menge von auswählbaren Perspektiven erzeugt:

– A – apikal
– M – MID-cavity
– B – basal
– VLA – vertical long axis bzw. Zweikammerblick
– HLA – horizontal long axis bzw. Vierkammerblick.

Für den Fachmann ist es selbstverständlich, dass die beiden in den 3 und 4 dargestellten Symbole S nur Beispiele sind und ein anderer medizinischer Kontext zu einem unterschiedlichen Symbol S mit unterschiedlich auswählbaren Perspektiven führt.
Im Folgenden sei eine erfindungsgemäße Steuerungseinheit 10 unter Bezugnahme auf 1 näher erläutert. Die Steuerungseinheit 10 kann als Grafikprozessor in einer Grafikkarte 1 implementiert sein. Die Grafikkarte 1 kann noch weitere Module umfassen und ist einem Computer 100 zugeordnet. Der Computer 100 interagiert mit einem Monitor M, auf dem die Bilddaten BD zur Anzeige gebracht werden sollen.
Die Steuerungseinheit 10 umfasst eine Erfassungseinheit 20, einen Speicher MEM, eine Berechnungseinheit 30, eine Symboleinheit 40 und eine Rendering-Einheit 50.
Die Erfassungseinheit 20 dient als Schnittstelle zum Computersystem und insbesondere zum Erfassen, Laden oder Bereitstellen des Bilddatensatzes BD. Die Erfassungseinheit 20 ist üblicherweise nur eine Schnittstelle zu anderen medizintechnischen Modulen und dient zum Einlesen oder Bereitstellen der Bilddaten. Vorzugsweise ist die Steuerungseinheit 10 und das Verfahren somit auch unabhängig von bildgebenden Modalitäten einsetzbar und kann als reines Visualisierungsverfahren für Bilddaten verwendet werden. In einer alternativen Ausführungsform der Erfindung kann die Erfassungseinheit 20 kann auch eine bildgebende Modalität sein. Des Weiteren dient die Erfassungseinheit 20 zum Erfassen des Bildstatus‘, der dem Bilddatensatz BD eineindeutig zugeordnet ist. Der Bildstatus kennzeichnet somit einen Kontext der Bilddaten BD und gibt an, um welche Untersuchung, um welche Modalität, um welche anatomische Region es sich bei den Bilddaten BD handelt. Der Bildstatus bzw. die Festlegung der Parameter, die für den Bildstatus erfasst werden, wird in einer Konfigurationsphase bestimmt.
In dem Speicher MEM sind Regeln abgelegt, um eine Menge von auswählbaren Perspektiven in Abhängigkeit von dem erfassten Bildstatus der Erfassungseinheit 20 zu bestimmen. Neben dem Bildstatus 20 kann auch noch eine aktuelle IST-Perspektive des bereits gerenderten Bildes berücksichtigt werden, falls bereits ein Bild auf dem Monitor M dargestellt worden ist. Falls es sich um eine initiale Bilddarstellung handelt, wird nur der Bildstatus berücksichtigt.
Die Berechnungseinheit 30 dient dazu, die Menge von auswählbaren Perspektiven Kontext-abhängig zu berechnen. Dabei werden insbesondere der Bildstatus und/oder die IST-Perspektive berücksichtigt.
Die Symboleinheit 40 dient dazu, das interaktive, vorzugsweise bildhafte, Symbol S zu erzeugen. Das Symbol S dient zur grafischen Repräsentation der berechneten Menge von auswählbaren Perspektiven. Dabei umfasst das Symbol S unterschiedliche interaktive Schaltflächen, wobei jeweils eine Schaltfläche einer auswählbaren Perspektive zugeordnet ist. Die auswählbaren Perspektiven sind Kontext-abhängig und anwendungsspezifisch, so dass sie für den jeweiligen Anwendungsfall der Bilddaten BD dynamisch und jeweils aktualisiert erzeugt werden. Auf den einzelnen Schaltflächen des Symbols S können Benutzerinteraktionen in Form von Perspektivensteuerungssignalen erfasst werden. Dabei kann beispielsweise erfasst werden, auf welche Schaltfläche des Symbols S der Benutzer klickt oder welche Schaltfläche er auf einem Touchscreen direkt berührt. Dies wird durch die Symboleinheit 40 ausgeführt. Das Perspektivensteuerungssignal signalisiert damit, welche SOLL-Perspektive bei dem anschließenden Rendern der Bilddaten verwendet werden soll. Dieses Perspektivensteuerungssignal wird an die Rendering-Einheit 50 weitergegeben.
In einer alternativen Ausführungsform der Erfindung kann es auch vorgesehen sein, den Wiedererkennungseffekt für das Symbol S zu erhöhen und es immer gleich zu gestalten, damit der Nutzer sich nicht umgewöhnen muss. Dann werden die Schaltflächen zwar dynamisch ausgewählt und/oder erzeugt, aber die Darstellung der Schaltflächen bestimmt sich nach einem übereinstimmenden Grundschema. Dies kann beispielsweise damit erreicht werden, dass die Schaltflächen und/oder die sonstigen Elemente des Symbols S (z.B. Icons und/oder Textfelder) aus einer vorkonfigurierten Menge ausgewählt werden. Ebenso ist es möglich, das Symbol S selbst nach einem übereinstimmenden Grundschema aufzubauen, damit der Nutzer sich nicht neu umgewöhnen muss.
Die Rendering-Einheit 50 dient dazu, den Bilddatensatz BD in der bestimmten SOLL-Perspektive zu rendern. Dabei basiert die SOLL-Perspektive auf dem erfassten Perspektivensteuerungssignal der Symboleinheit 40. An dieser Stelle sei ausdrücklich darauf hingewiesen, dass die SOLL-Perspektive auch mit der IST-Perspektive übereinstimmen kann, so dass in diesem Fall faktisch kein Perspektivenwechsel durchgeführt wird.
Zusammenfassend lässt sich die vorliegende Erfindung als Steuerungsverfahren beschreiben, das zur Bestimmung von Orientierungen bzw. Perspektiven beim Rendern des Bilddatensatzes BD in einer ausgewählten SOLL-Perspektive angewendet wird. Dabei wird insbesondere der Kontext der Bilddaten BD über den erfassten Bildstatus berücksichtigt. Je nachdem, welcher Bildstatus-Kontext für die Bilddaten BD vorliegt, werden unterschiedliche Perspektiven zur Auswahl auf der Benutzeroberfläche UI angeboten. Die Auswahl der Perspektiven erfolgt durch das Aktivieren von Schaltflächen eines dynamisch erzeugten interaktiven Symbols S. Die Schaltflächen des Symbols S repräsentieren auf bildhafte Weise die auswählbaren Perspektiven. Dies kann in Form einer beispielhaften bildlichen Darstellung der jeweiligen Perspektive repräsentiert sein. Eine Einblendung von textuellen Perspektivenbestimmungen ist möglich, jedoch nicht zwingend erforderlich. Mit anderen Worten kann die jeweilige Perspektive, in der die Bilddaten BD dargestellt werden sollen (SOLL-Perspektive) ausschließlich durch eine bildliche Darstellung gekennzeichnet und ausgewählt werden.
Das Verfahren kann grundsätzlich beim Rendern von Bilddaten BD verwendet werden. Alternativ kann es auch als Perspektivenwechsel angewendet werden. Im letzteren Fall ist das Verfahren als sogenannter orientation changer ausgebildet, der dazu dient, die Bilddarstellung in einer IST-Perspektive in die Bilddarstellung in einer SOLL-Perspektive zu transformieren. Dabei wird der Kontext bzw. der Bildstatus der Bilddaten BD berücksichtigt.
Abschließend sei darauf hingewiesen, dass die vorstehende Beschreibung der Erfindung mit den Ausführungsbeispielen grundsätzlich nicht einschränkend im Hinblick auf eine bestimmte physikalische Realisierung der Erfindung zu verstehen ist. So ist es für einen Fachmann insbesondere offensichtlich, dass die Erfindung grundsätzlich nicht auf bestimmte Arten von medizinischen Bildern BD beschränkt ist, sondern ebenso auch für andere bildgebende Anlagen verwendet werden kann. Darüber hinaus ist es auch nicht zwingend notwendig, auf bestimmte Monitor-Technologie (Monitor und herkömmliche Eingabegeräte oder berührungssensitiver Touch Screen) zurückzugreifen. Des Weiteren sind neben dem DICOM-Format auch noch andere Datenformate verarbeitbar. Beispielsweise können hier auch proprietäre Protokolle zur Bildakquisition bzw. -speicherung verwendet werden. Darüber hinaus kann die Erfindung teilweise oder vollständig in Software und/oder in Hardware implementiert sein. Darüber hinaus kann das erfindungsgemäße Verfahren bzw. die Steuerungseinheit auch auf mehrere physikalische Produkte, umfassend Computerprogrammprodukte, verteilt realisiert werden.

Claims

Steuerungseinheit (10) zur Bestimmung von Perspektiven beim Rendern eines Bilddatensatzes (BD) in einer SOLL-Perspektive zur Darstellung auf einem Anzeigegerät (M), mit: – Einer Erfassungseinheit (20), die zum Erfassen des Bilddatensatzes (BD) und eines dem Bilddatensatz (BD) zugeordneten Bildstatus bestimmt ist – Einem Speicher (MEM), in dem Regeln abgelegt sind, um eine Menge von auswählbaren Perspektiven in Abhängigkeit von dem erfassten Bildstatus und – falls vorhanden – von einer IST-Perspektive eines bereits gerenderten Bildes zu bestimmen – Einer Berechnungseinheit (30), die dazu bestimmt ist, die Menge von auswählbaren Perspektiven basierend auf dem Speicherzugriff zu berechnen – Einer Symboleinheit (40), die dazu bestimmt ist, ein interaktives Symbol (S) zur grafischen Repräsentation der berechneten Menge von auswählbaren Perspektiven dynamisch zu erzeugen und dies auf einer Benutzeroberfläche (UI) zur Auswahl einer SOLL-Perspektive einzublenden und zumindest ein Perspektivensteuerungssignal auf dem eingeblendeten, interaktiven Symbol (S) zur Bestimmung der SOLL-Perspektive zu erfassen – Rendering-Einheit (50), die dazu bestimmt ist, den Bilddatensatz (BD) in der bestimmten SOLL-Perspektive, basierend auf dem erfassten Perspektivensteuerungssignal zu rendern.
Steuerungseinheit (10) nach Anspruch 1, wobei die Steuerungseinheit (10) als Prozessoreinheit, insbesondere als Grafikprozessor, in einer Grafikkarte (1) implementiert ist.
Steuerungsverfahren zur Bestimmung von Perspektiven beim Rendern eines Bilddatensatzes (BD) in einer SOLL-Perspektive zur Darstellung auf einem Anzeigegerät (M), mit folgenden Verfahrensschritten: – Erfassen (A) des Bilddatensatzes (BD) und eines dem Bilddatensatz (BD) zugeordneten Bildstatus – Zugriff (B) auf einen Speicher (MEM), in dem Regeln abgelegt sind, um eine Menge von auswählbaren Perspektiven in Abhängigkeit von dem erfassten Bildstatus und – falls vorhanden – von einer IST-Perspektive eines bereits gerenderten Bildes zu bestimmen – Berechnen (C) der Menge von auswählbaren Perspektiven basierend auf dem Speicherzugriff – Dynamisches Erzeugen (D) eines interaktiven Symbols (S) zur grafischen Repräsentation der berechneten Menge von auswählbaren Perspektiven – Einblenden (E) des interaktiven Symbols (S) auf einer Benutzeroberfläche (UI) zur Auswahl einer SOLL-Perspektive aus der mit dem Symbol (S) repräsentierten berechneten Menge von auswählbaren Perspektiven – Erfassen (F) eines Perspektivensteuerungssignals auf dem eingeblendeten, interaktiven Symbol (S) zur Bestimmung der SOLL-Perspektive und – Rendern (G) des Bilddatensatzes (BD) in der bestimmten SOLL-Perspektive, basierend auf dem erfassten Perspektivensteuerungssignal.
Steuerungsverfahren nach Anspruch 3, wobei das Verfahren zum Steuern und Ausführen eines Perspektivenwechsels bei einem bereits dargestellten Bild angewendet wird, wobei der gerenderte Bilddatensatz (BD) auf dem Anzeigegerät (M) in einer IST-Perspektive bereitgestellt wird.
Steuerungsverfahren nach einem der vorstehenden Verfahrensansprüche, wobei das Symbol (S) eine grafische und/oder textuelle Kurzdarstellung der jeweiligen Perspektiven, insbesondere der Menge von auswählbaren Perspektiven, umfasst.
Steuerungsverfahren nach einem der vorstehenden Verfahrensansprüche, wobei das Symbol (S) derart auf der Benutzeroberfläche (UI) eingeblendet wird, dass es einen bereits dargestellten Bilddatensatz (BD) in der IST-Perspektive überlagert.
Steuerungsverfahren nach einem der vorstehenden Verfahrensansprüche, wobei das Perspektivensteuerungssignal durch eine einzelne benutzerseitige Aktion gesteuert wird, insbesondere durch zumindest einen Mausclick oder durch zumindest eine Eingabe auf einer Eingabeeinrichtung.
Steuerungsverfahren nach einem der vorstehenden Verfahrensansprüche, wobei der Bildstatus automatisch zumindest aus Metadaten zu den Bilddaten erfasst wird und/oder zumindest Daten umfasst in Bezug auf Modalität, Art der Untersuchung, Organ, Befundung, Position und/oder Kontext der Bilddaten, so dass aus den Bildstatusdaten automatisch abgeleitet werden kann, welche Perspektiven bei der nachfolgenden Darstellung möglich, sinnvoll und/oder relevant sind.
Steuerungsverfahren nach einem der vorstehenden Verfahrensansprüche, wobei das interaktive, grafische Symbol (S) zusätzlich einen auswählbaren Rendermodus umfasst, der bei dem Rendern des Bilddatensatzes (BD) in der SOLL-Perspektive berücksichtigt wird.
Computerprogrammprodukt, wobei das Computerprogrammprodukt ein Computerprogramm umfasst, das auf einem Datenträger oder auf einem Speicher eines Computers gespeichert ist und das von dem Computer lesbare Befehle umfasst, die zur Ausführung des Verfahrens nach dem vorstehenden Verfahrensanspruch bestimmt sind, wenn die Befehle auf dem Computer ausgeführt werden.