Nothing Special   »   [go: up one dir, main page]

DE102006051447A1 - Verfahren und System zum Generieren einer Benutzeroberfläche - Google Patents

Verfahren und System zum Generieren einer Benutzeroberfläche Download PDF

Info

Publication number
DE102006051447A1
DE102006051447A1 DE102006051447A DE102006051447A DE102006051447A1 DE 102006051447 A1 DE102006051447 A1 DE 102006051447A1 DE 102006051447 A DE102006051447 A DE 102006051447A DE 102006051447 A DE102006051447 A DE 102006051447A DE 102006051447 A1 DE102006051447 A1 DE 102006051447A1
Authority
DE
Germany
Prior art keywords
controls
application
user interface
relevant
layout
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102006051447A
Other languages
English (en)
Inventor
Steffen Dr. List
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens Healthcare GmbH
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE102006051447A priority Critical patent/DE102006051447A1/de
Priority to US11/930,463 priority patent/US8086965B2/en
Publication of DE102006051447A1 publication Critical patent/DE102006051447A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • AHUMAN NECESSITIES
    • A61MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61BDIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00Measuring for diagnostic purposes; Identification of persons
    • A61B5/05Detecting, measuring or recording for diagnosis by means of electric currents or magnetic fields; Measuring using microwaves or radio waves 
    • A61B5/055Detecting, measuring or recording for diagnosis by means of electric currents or magnetic fields; Measuring using microwaves or radio waves  involving electronic [EMR] or nuclear [NMR] magnetic resonance, e.g. magnetic resonance imaging
    • AHUMAN NECESSITIES
    • A61MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61BDIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00Measuring for diagnostic purposes; Identification of persons
    • A61B5/74Details of notification to user or communication with user or patient ; user input means
    • A61B5/742Details of notification to user or communication with user or patient ; user input means using visual displays
    • A61B5/7435Displaying user selection data, e.g. icons in a graphical user interface
    • AHUMAN NECESSITIES
    • A61MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61BDIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00Measuring for diagnostic purposes; Identification of persons
    • A61B5/74Details of notification to user or communication with user or patient ; user input means
    • A61B5/7475User input or interface means, e.g. keyboard, pointing device, joystick
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/38Creation or generation of source code for implementing user interfaces
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01RMEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R33/00Arrangements or instruments for measuring magnetic variables
    • G01R33/20Arrangements or instruments for measuring magnetic variables involving magnetic resonance
    • G01R33/44Arrangements or instruments for measuring magnetic variables involving magnetic resonance using nuclear magnetic resonance [NMR]
    • G01R33/48NMR imaging systems
    • G01R33/54Signal processing systems, e.g. using pulse sequences ; Generation or control of pulse sequences; Operator console
    • G01R33/546Interface between the MR system and the user, e.g. for controlling the operation of the MR system or for the design of pulse sequences

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Pathology (AREA)
  • Biomedical Technology (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Medical Informatics (AREA)
  • Molecular Biology (AREA)
  • Surgery (AREA)
  • Animal Behavior & Ethology (AREA)
  • Biophysics (AREA)
  • Public Health (AREA)
  • Veterinary Medicine (AREA)
  • Human Computer Interaction (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • High Energy & Nuclear Physics (AREA)
  • Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
  • Radiology & Medical Imaging (AREA)
  • Signal Processing (AREA)
  • Condensed Matter Physics & Semiconductors (AREA)
  • User Interface Of Digital Computer (AREA)
  • Magnetic Resonance Imaging Apparatus (AREA)

Abstract

Die Erfindung betrifft ein Verfahren, ein System, ein Speichermedium und ein Computerprogrammprodukt zum Generieren einer Benutzeroberfläche (BO) für eine medizinische Applikation, die auf einem Magnetresonanz-Tomographen ausgeführt werden soll, wobei nur die Parameter und/oder Parameter-Karten als Steuerelemente (S) bei dem Generieren der Benutzerobefläche (BO) berücksichtigt werden, die zur Steuerung der jeweiligen Applikation relevant sind. Dafür werden die relevanten Steuerelemente (S) erfasst und einzeln oder in Gruppen sortiert nach konfigurierbaren Positionierungskriterien auf einem Bildschirm dargestellt.

Description

  • Die vorliegende Erfindung liegt auf den Gebieten der Datenverarbeitung und der Medizintechnik und betrifft insbesondere ein Verfahren, ein System, ein Speichermedium, ein Computerprogramm und ein Computerprogrammprodukt zum Gestalten von Benutzeroberflächen für komplexe medizin-technische Geräte, wie z. B Magnetresonanz-Tomographen etc.
  • Hintergrund der vorliegenden Erfindung ist darin zu sehen, dass zur Steuerung eines solchen komplexen Magnetresonanz-Tomographen eine Vielzahl von Einstellungen und Konfigurationen notwendig sind, die abhängig von der jeweiligen Applikation unterschiedliche Benutzereingaben erfordern. Vergegenwärtigt man sich die Vielzahl von möglichen Applikationen für ein Magnetresonanz-Gerät (z. B. Sequenztechniken, Post-Processing-Applikationen etc.), die jeweils unterschiedliche Benutzereingaben als Steuerelemente für die Applikation erfordern (wie z. B. Zeitangaben, Details für die Post-Processing-Schritte, Obergrenzen und Untergrenzen etc.), so wird deutlich, dass viele Parameter auf der Benutzeroberfläche dargestellt werden müssen. Die bisherige Darstellung kann nachteiligerweise sehr unübersichtlich sein, da auch solche Parameter dargestellt wurden, die für die jeweilige Applikation gar nicht von Bedeutung waren. Die bisherige Bedienoberfläche für die Darstellung von MR-Mess- oder Nachbearbeitungs-Parametern aus dem Stand der Technik ist im Wesentlichen statisch und besteht hauptsächlich aus einer Obermenge aller grundsätzlich zur Verfügung stehenden Parameter in Bezug auf das MR-Gerät. Wie von anderen Systemen aus dem Stand der Technik bekannt, war es auch hier vorgesehen, die jeweiligen Parameter auf so genannten Parameterkarten anzuzeigen. In Zusammenhang mit einem MR-Gerät mussten somit mehrere hundert Parameter, die teilweise auf über 25 Parameterkarten verteilt waren, angezeigt werden. Eine Navigation unter den angezeigten Parametern war deshalb ein sehr zeitintensiver und fehleranfälliger Prozess und führte insgesamt zu einer sehr umständlichen Bedienung. Jede Applikation, die in Zusammenhang mit dem MR-Gerät ausgeführt werden soll, erfordert unterschiedliche Parametersätze. Nachteiligerweise war es bei den bisherigen Systemen aus dem Stand der Technik nicht möglich, die Bedienoberfläche an die jeweilige Applikation anzupassen und nur die Parameter in ergonomisch sinnvoller Anordnung anzuzeigen, die für die jeweilige Applikation relevant waren. Beispielsweise erfordert eine spezielle Applikation, wie die Angiographie, nur wenige, spezielle Parametereingaben als Steuerbefehle des Benutzers, die aber auf vielen verschiedenen Karten verstreut liegen. Von daher können die meisten anderen Parameter auf diesen Parameterkarten für diesen speziellen Fall außer Acht gelassen werden.
  • Aufgabe der vorliegenden Erfindung ist es deshalb, einen Weg aufzuzeigen, um eine Benutzeroberfläche zur Steuerung von Applikationen für ein komplexes medizin-technisches Gerät, insbesondere für einen Magnetresonanz-Tomographen, zu verbessern, insbesondere dynamisch und flexibel auf die jeweilige Applikation abzustellen und hinsichtlich Platzbedarf auf dem Bildschirm zu optimieren.
  • Diese Aufgabe wird durch die beiliegenden Hauptansprüche gelöst, insbesondere durch ein Verfahren zum Generieren einer Benutzeroberfläche für jeweils zumindest eine medizinische Applikation aus einer Menge von Applikationen zur Steuerung eines medizinischen Gerätes, durch ein entsprechendes System, durch ein Speichermedium und durch ein entsprechendes Computerprogrammprodukt.
  • Im Folgenden wird die Erfindung anhand der verfahrensgemäßen Lösung beschrieben. Hierbei erwähnte Vorteile, Merkmale oder alternative Ausführungsformen sind ebenso auch auf die anderen beanspruchten Gegenstände zu übertragen, insbesondere auf das System und das Speichermedium, sowie auf das Produkt. Mit anderen Worten können auch die vorstehend genannten beanspruchten Gegenstände mit Merkmalen weitergebildet sein, die in Zusammenhang mit dem Verfahren beschrieben und/oder beansprucht worden sind und umgekehrt.
  • Die vorstehende Aufgabe wird insbesondere durch ein Verfahren zum Generieren einer Benutzeroberfläche für jeweils zumindest eine medizinische Applikation aus einer Menge von unterschiedlichen Applikationen für ein medizinisches Gerät bzw. zur Steuerung des Gerätes gelöst, mit folgenden Verfahrensschritten:
    • – Bestimmen der Applikation, für die die Benutzeroberfläche generiert werden soll,
    • – Erfassen von Steuerelementen, die zur Steuerung der bestimmten Applikation relevant sind,
    • – Positionieren der relevanten Steuerelemente und/oder von in Steuergruppen zusammengefassten relevanten Steuerelementen nach konfigurierbaren Positionierungskriterien auf einem Bildschirm, so dass sich ein optimales Layout für die Steuerelemente ergibt, insbesondere in Hinblick auf einen Platzbedarf.
  • Im Folgenden werden die Begrifflichkeiten, die im Rahmen dieser Erfindung verwendet werden, kurz erläutert.
  • Bei der Benutzeroberfläche handelt es sich um eine übliche Bedienoberfläche (user interface), die im Rahmen von Datenverarbeitungsanlagen eingesetzt ist. Sie ist üblicherweise grafisch und umfasst Steuerelemente zum Steuern der jeweiligen Applikation, wie Icons, Karten bzw. Folder, die über geeignetes Computerzubehör, wie z. B. über eine Tastatur oder über eine Maus aktiviert werden können.
  • Die Beschreibung der vorliegenden Erfindung bezieht sich hauptsächlich auf einen Magnetresonanz-Tomographen als medizinisches Gerät. Es sind hier jedoch auch Röntgen-Geräte, Computer-Tomographen oder andere bildgebende medizin-technische Geräte denkbar, auf denen Applikationen ausgeführt werden sollen.
  • Bei den Steuerelementen handelt es sich um Elemente auf der Benutzeroberfläche, die unter anderem zum Steuern der Applikation bestimmt sind. Sie setzen eine Benutzereingabe (über Tastatur, Maus oder sonstige Mittel) um in Steuersignale für die jeweilige Applikation.
  • Um ein leichteres Handling für den Benutzer zu ermöglichen, können einzelne Steuerelemente zu Steuergruppen zusammengefasst werden. Diese werden dann auf strukturierte bzw. zusammengefasste Weise auf der Benutzeroberfläche dargestellt. Handelt es sich beispielsweise bei den Steuerelementen um Parameter-Eingabemöglichkeiten oder um sonstige textuelle Steuerelemente, so kann eine Steuergruppe in einer Gruppe von mehreren Steuerelementen bestehen, die als Folder, Ordner, bzw. Karteikarte auf der Benutzeroberfläche angezeigt wird. Das Strukturieren der Steuerelemente kann nach vorkonfigurierbaren Strukturierungskriterien erfolgen. In der Regel werden die Steuerelemente in einer Karte zusammengefasst, die inhaltlich einen Zusammenhang aufweisen. Darüber hinaus ist es möglich, auch zeitliche Zusammenhänge zu erfassen und solche Steuerelemente zusammen zu gruppieren, die vom Anwender in aufeinander folgenden Schritten aktiviert werden müssen. Dies führt zu einer leichteren und effizienteren Handhabung der Applikation.
  • Wie vorstehend bereits ausgeführt ist eine Steuergruppe vorzugsweise in Form einer Karte, eines Ordners bzw. eines entsprechenden Folders ausgebildet. Hier sind mehrere Steuerelemente zusammengefasst, die inhaltlich in Bezug zueinander stehen.
  • Das Positionieren der Steuerelemente und/oder der Steuergruppen bezieht sich auf eine optimierte Lagebestimmung auf dem Bildschirm. Dies erfolgt üblicherweise ebenfalls nach konfigurierbaren Positionierungskriterien. Die Positionierungskriterien sind vorzugsweise in Hinblick auf Platz- und/oder Bedienauf wand optimiert. In alternativen Ausführungsformen kön nen jedoch hier auch weitere Positionierungskriterien angewendet werden. Dies stellt einen wesentlichen Vorteil im Vergleich zu den bisherigen Verfahren aus dem Stand der Technik dar, da bisher keine Auswahl von relevanten Steuerelementen getroffen werden konnte, so dass der Benutzer mit einer Vielzahl von Steuerelementen konfrontiert war, und somit Bedienung und Navigation unter diesen Elementen nur schwer und zeitaufwendig ausgeführt werden konnten.
  • In der bevorzugten Ausführungsform können die Strukturierungskriterien und/oder die Positionierungskriterien vorkonfigurierbar sein.
  • In einer bevorzugten Ausführungsform der Erfindung handelt es sich bei den Steuerelementen um eine grafische Repräsentation für eine Parameter-Eingabe. Dies kann insbesondere in Form von textuellen Eingaben, Eingaben mittels Tastatur und/oder Maus oder sonstigem Zubehör erfolgen. Die Parameter-Eingaben dienen vorzugsweise zur Steuerung eines Applikationsprozesses (Post-Processing, Einstellungen bei einer Angiographie, Steuerung eines Magnetresonanz-Tomographen etc.). Üblicherweise werden die Steuerelemente durch eine entsprechende Benutzereingabe eines Benutzers aktiviert. Alternativ ist es jedoch auch möglich, die Steuerelemente zu aktivieren, indem Daten über eine Schnittstelle aus anderen Modulen ausgelesen und über eine Entscheidungsinstanz zur Ansteuerung verwendet werden.
  • Ein wesentlicher Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass nur die Steuerelemente und/oder die Steuergruppen auf der Benutzeroberfläche dargestellt werden, die für die jeweilige Applikation relevant sind. Damit entsteht der wesentliche Vorteil, dass der Benutzer nicht mit Steuerelementen konfrontiert wird, die bei der entsprechenden Applikation ohne Belang sind.
  • In einer weiteren, bevorzugten Ausführungsform der Erfindung ist es vorgesehen, dass einer für jeweils zumindest eine Ap plikation generierte Benutzeroberfläche eine Referenz zugeordnet wird, mittels der die Benutzeroberfläche zu einem späteren Zeitpunkt, insbesondere bei Ausführung der Applikation, abrufbar und/oder ausführbar ist. Die Zuordnung erfolgt in der Regel über einen Namen und ist eindeutig. Mit anderen Worten kann eine generierte Benutzeroberfläche eindeutig über einen ihr zugeordneten Namen ausgewählt bzw. bestimmt werden. Dieser Vorgang wird auch als ASSIGN-Prozedur bezeichnet. Üblicherweise sind alle generierten Benutzeroberflächen und die ihnen jeweils zugeordneten Namen in einer entsprechenden Datenstruktur abgelegt. Damit kann der Benutzer einen Überblick erhalten, welche Benutzeroberflächen grundsätzlich auswählbar sind. Darüber hinaus ist es möglich, dass für eine Applikation jeweils eine bestimmte generierte Benutzeroberfläche aus einer Menge von Benutzeroberflächen ausgewählt wird. Auch hier kann der Benutzer aus vorkonfigurierbaren Namen auswählen. Sobald der Benutzer eine Benutzeroberfläche zur Anwendung ausgewählt hat, wird diese aktiviert und auf dem Bildschirm dargestellt. Dieser Vorgang wird auch als USE-Prozedur bezeichnet. Ein wesentlicher Vorteil ist darin zu sehen, dass mit dieser Lösung eine hohe Flexibilität erreicht werden kann, indem zum Einen mehrere Benutzeroberflächen auswählbar sind, die optimal auf die jeweilige Anwendung bzw. Applikation ausgelegt sind und indem zum Anderen der Zeitpunkt zur Aktivierung einer Benutzeroberfläche beliebig vom Anwender bestimmt werden kann.
  • Grundsätzlich ist es zwar auch möglich, dass für jeweils eine Anwendung bzw. Applikation auch nur eine Benutzeroberfläche generiert wird, wie dies im Stand der Technik bekannt ist, erfindungsgemäß können jedoch auch für mehrere Applikationen mehrere Benutzeroberflächen generiert werden. Dies ist insbesondere im medizin-technischen Umfeld von Bedeutung, da ein Magnetresonanz-Gerät eine sehr komplexe Steuerung erfordert, die auf unterschiedlichsten Applikationen aufsetzt. Darüber hinaus können die jeweiligen Applikationen in einem unterschiedlichen medizinischen Kontext und von unterschiedlichen Personen angewendet werden. Je nach Kontext bzw. Person kön nen andere Steuerelemente bzw. Parameter notwendig werden, so dass es sinnvoll ist, für ein- und dieselbe Applikation auch mehrere Benutzeroberflächen zu generieren. Damit entsteht eine n:n-Beziehung zwischen generierbaren Benutzeroberflächen einerseits und zugehörigen Applikationen andererseits. Dies schafft weitere Freiheitsgrade bei der Steuerung des medizinischen Gerätes.
  • In einer vorteilhaften Weiterbildung der Erfindung ist es vorgesehen, dass das Verfahren auf eine bestehende Benutzeroberfläche aufsetzt und die dargestellten Steuerelemente und/oder die dargestellten Steuergruppen verändert, insbesondere erweitert oder einschränkt. Dies bringt den Vorteil, dass der Benutzer beim Generieren einer neuen Benutzeroberfläche nicht unnötigerweise bereits bestehende Steuerelemente nochmals neu konfigurieren muss, sondern bereits auf vordefinierten Elementen aufsetzen kann. Dies bringt einen deutlichen Zeitvorteil beim Erstellen von Benutzeroberflächen. Darüber hinaus ist ein zusätzlicher Sicherheitsaspekt darin zu sehen, dass der Benutzer auf notwendige Steuerelemente für die jeweilige Applikation aufmerksam gemacht wird und diese somit beim Generieren der Benutzeroberfläche nicht in Vergessenheit geraten können.
  • In einigen Spezialfällen kann es jedoch sinnvoll sein, eine völlig neue Benutzeroberfläche zu generieren und nicht auf bereits existierenden Oberflächen aufzusetzen. In diesem Fall werden die Steuerelemente erfasst, die zur Steuerung der jeweiligen Applikation notwendig sind. Diese werden dann so strukturiert bzw. positioniert, dass sich insgesamt ein optimales Layout der Benutzeroberfläche ergibt. Eine völlige Neukonfiguration – wie vorstehend erläutert – ist beispielsweise dann sinnvoll, wenn eine neue Applikation in das System integriert werden soll.
  • Ein wichtiger Aspekt der erfindungsgemäßen Lösung ist darin zu sehen, dass ein Wechsel zwischen unterschiedlichen Benutzeroberflächen für ein- und dieselbe Applikation auch zur Laufzeit möglich ist. Damit können vorteilhafterweise Szenarien abgedeckt werden, die beispielsweise einen Benutzerwechsel betreffen oder einen sonstigen Wechsel im Kontext der Applikationsausführung. Vorteilhafterweise muss bei einem Wechsel die Applikation nicht nochmals erneut gestartet werden, was insgesamt die Performance des Systems erhöht.
  • In der Regel ist es vorgesehen, dass die Steuerelemente hierarchisch strukturiert sind und Sub-Steuerelemente umfassen, insbesondere Sub-Karten. Dabei ist die Anzahl der Hierarchie-Ebenen nicht begrenzt. Die Gruppierung bzw. Strukturierung der relevanten Steuerelemente wird vorzugsweise so ausgeführt, dass eine möglichst leichte und schnelle Handhabung des Benutzers mittels der generierten Benutzeroberfläche möglich ist. Im Gegensatz zu bisherigen Verfahren aus dem Stand der Technik entsteht damit der Vorteil, dass der Benutzer nur innerhalb der relevanten Steuermittel navigieren muss, wobei die Navigation dadurch erleichtert wird, dass die Steuerelemente für die Ausführung bzw. Bedienung optimal angeordnet sind.
  • In einer vorteilhaften Weiterbildung der Erfindung ist es vorgesehen, dass das Erfassen von relevanten Steuerelementen (also von Steuerelementen, die zur Steuerung für die jeweilige Applikation notwendig sind) automatisch erfolgt, indem die jeweilige Applikation bestimmt wird und daraufhin ein Zugriff auf eine Speicherstruktur ausgeführt wird, in der zu jeder Applikation jeweils alle relevanten Steuerelemente abgelegt sind. In der vorstehend beschriebenen Ausführungsform erfolgt also das Erfassen der relevanten Steuerelemente vollautomatisch. Es ist jedoch ebenso möglich, hier auch manuelle bzw. halbautomatische Erfassungsvorgänge vorzusehen, die darauf abzielen, dass der Benutzer bei der Auswahl von relevanten Steuerelementen über eine – beispielsweise menüartig dargestellte – Vorauswahl unterstützt wird.
  • Grundsätzlich ist es vorgesehen, dass alle oder ausgewählte Verfahrensschritte automatisch ausgeführt werden. Insbesonde re soll das Positionieren der Steuerelemente auf dem Bildschirm automatisch so ausgeführt werden, dass sich ein optimiertes Layout ergibt. Der Benutzer hat bei dem Generieren der Benutzeroberfläche hier die Möglichkeit, in den Positionierungsvorgang direkt einzugreifen, er muss dies jedoch nicht zwingend tun.
  • In einer weiteren vorteilhaften Ausbildung der Erfindung ist es vorgesehen, dass das erfindungsgemäße Verfahren zusätzlich folgenden Verfahrensschritt umfasst:
    • – Darstellen der generierten Benutzeroberfläche mit den als relevant ausgewählten Steuerelementen zur Steuerung der Applikation.
  • Damit erhält der Benutzer unmittelbar eine Kontrollmöglichkeit über die automatisch generierte Benutzeroberfläche, da diese unmittelbar angezeigt wird. Sollten sich hier Inkonsistenzen ergeben, so ist es möglich, das Verfahren nochmals mit veränderten Rahmenbedingungen ausführen zu lassen und den Vorgang (Zuordnung der generierten Oberfläche zu der Applikation) dann abzuspeichern.
  • Mit der erfindungsgemäßen Lösung ergeben sich eine Reihe von Vorteilen. Ein wesentlicher Aspekt in diesem Zusammenhang ist darin zu sehen, dass erfindungsgemäß eine für jeden Anwendungsfall maßgeschneiderte Benutzeroberfläche geschaffen werden kann, deren Bedienung wesentlich ergonomischer, schneller und einfacher ist, da nur die jeweils relevanten Parameter (z. B. Mess- und/oder Nachverarbeitungs-Parameter) angezeigt werden. Da das Layout in Hinblick auf die relevanten Parameter optimiert ist und die Parameter in der Regel häufig auf eine einzige Parameter-Karte passen, sind keine Kartenwechsel notwendig. Damit entstehen die Vorteile, dass die Handhabung für den Benutzer leichter wird und, dass eine Einarbeitungszeit für unerfahrene Benutzer verringert werden kann, da sie nur mit den jeweils relevanten Parametern konfrontiert sind. Insgesamt kann der Bildschirmplatz für die Darstellung der Steuerelemente minimiert werden.
  • In Hinblick auf Standardanwendungen kann es sinnvoll sein, dass automatisch generierte Standard-Benutzeroberflächen eingesetzt werden können. Diese werden sozusagen als Default-Benutzeroberfläche verwendet. Zum Generieren einer Default-Benutzeroberfläche werden Standard-Parameter verwendet. Es ist dann einstellbar, wie lange diese Default-Benutzeroberfläche zum Einsatz kommt (ob sie nur temporär verwendet wird und dann beispielsweise von einer spezifischen Oberfläche ersetzt wird).
  • Das Erfassen von relevanten Steuerelementen kann – wie vorstehend bereits erläutert – entweder automatisch oder manuell erfolgen. Entweder werden bestimmte Datensätze eingelesen, die eine Aufzählung von relevanten Steuerelementen für eine jeweilige Applikation umfassen, oder der Benutzer gibt über eine geeignete Schnittstelle die relevanten Steuerelemente manuell ein. Im medizinischen Bereich gibt es in der Regel einen Satz von Parametern, der für die jeweilige Applikation von Bedeutung ist. Dies wird auch als "Protokoll" bezeichnet und betrifft sozusagen eine Vorschrift für die Ausführung der jeweiligen Applikation (welche Einstellungen für jeden einzelnen Parameter nun getroffen werden müssen). Ein Vorteil der erfindungsgemäßen Lösung ist nun darin zu sehen, dass das Erfassen von Steuerelementen zentral und/oder protokollabhängig erfolgen kann. Somit können beispielsweise protokoll-spezifische Benutzeroberflächen die jeweils zentral definierten Benutzeroberflächen ersetzen.
  • Eine weitere Aufgabenlösung besteht in einem System zum Generieren einer Benutzeroberfläche für jeweils zumindest eine medizinische Applikation aus einer Menge von Applikationen für ein medizinisches Gerät, insbesondere für einen Magnetresonanz-Tomographen, mit:
    • – zumindest einem Applikations-Bestimmungsmodul, das zum Bestimmen der Applikation ausgebildet ist, für die die jeweilige Benutzeroberfläche generiert werden soll,
    • – zumindest einem Erfassungsmodul, das zum Erfassen von Steuerelementen bestimmt ist, die für die vom Bestimmungsmodul bestimmte Applikation relevant sind,
    • – zumindest einem Positionierungsmodul, das dazu bestimmt ist, die relevanten Steuerelemente und/oder in Steuergruppen zusammengefasste relevante Steuerelemente nach konfigurierbaren Positionierungskriterien auf einem Bildschirm so darzustellen, so dass sich ein optimales Layout ergibt, wobei die positionierten Steuerelemente jeweils Schnittstellen zur Applikation umfassen.
  • Weitere Aufgabenlösungen bestehen in einem Speichermedium das zur Speicherung des vorstehend beschriebenen, computerimplementierten Verfahrens bestimmt ist und von einem Computer lesbar ist und in einem Computerprogrammprodukt gemäß den beiliegenden Hauptansprüchen.
  • Weitere vorteilhafte Ausführungsformen ergeben sich aus den Unteransprüchen.
  • In der folgenden 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 übersichtsartige Darstellung zum Generieren einer Benutzeroberfläche anhand unterschiedlicher Protokolle und anhand unterschiedlicher Layout-Daten,
  • 2 eine beispielhafte Darstellung für ein Ersetzen von Layout-Daten von einzelnen Protokollen,
  • 3 eine beispielhafte Darstellung von unterschiedlichen Layouts für ein- und dieselbe Benutzeroberfläche und
  • 4 eine beispielhafte Darstellung von einer erfindungsgemäß neu generierten Benutzeroberfläche mit mehreren Karten und Sub-Karten (dargestellt auf der unteren Seitenhälfte), basierend auf einer beste henden Benutzeroberfläche (dargestellt auf der oberen Seitenhälfte).
  • Das erfindungsgemäße Verfahren zielt darauf ab, eine Benutzeroberfläche BO in Abhängigkeit von der jeweiligen Applikation automatisch zu generieren.
  • Dazu wird in einem ersten Schritt die Applikation bestimmt, für die die Benutzeroberfläche BO generiert werden soll. Daran anschließend werden – vorzugsweise automatisch – so genannte Steuerelemente S erfasst. Bei den Steuerelementen handelt es sich im Wesentlichen um Parameter-Eingabeoptionen, die als Elemente auf der Benutzeroberfläche BO dargestellt werden. Dies können entweder (wie aus den Figuren ersichtlich) Felder für eine textuelle oder numerische Eingabe sein, Auswahlmöglichkeiten aus einer Menüdarstellung oder sonstige Steuerelemente, die über eine Benutzereingabe aktiviert werden können, beispielsweise über Tastatur, Maus oder sonstige Geräte. Gemäß einer vorteilhaften Weiterbildung der Erfindung ist es vorgesehen, die jeweiligen Steuerelemente S zu strukturieren, gruppieren bzw. zu Steuergruppen zusammen zu fassen. Bei einer Steuergruppe handelt es sich üblicherweise um eine so genannte Parameter-Karte (auch Folder bzw. Ordner genannt).
  • Erfindungsgemäß werden nun die Steuerelemente aus einer Menge von grundsätzlich möglichen Steuerelementen S ausgewählt, die für die jeweils bestimmte Applikation relevant sind. Daraufhin erfolgt ein automatisches Positionieren der relevanten Steuerelemente auf einem Bildschirm nach konfigurierbaren Positionierungskriterien, so dass ein optimales Bildschirm-Layout erhalten wird. Die Positionierungskriterien sind vorzugsweise im Hinblick auf Platzbedarf und/oder Bedienaufwand optimiert und ausgelegt. In diesem Merkmal ist ein wesentlicher Vorteil der erfindungsgemäßen Lösung zu sehen, da nur die relevanten Steuerelemente S auf dem Bildschirm dargestellt werden, wobei die Steuerelemente S bzw. die jeweiligen Steuergruppen darüber hinaus so positioniert sind, dass ein optimales Layout erhalten werden kann. Der Anwender wird nur mit den notwendigen Parameter-Abfrageoptionen konfrontiert, die des Weiteren so positioniert sind, dass eine möglichst ergonomische Eingabe möglich wird.
  • In 1 ist übersichtsartig dargestellt, wie die Verschaltung einzelner erfindungsgemäße Module zum automatischen optimierten Layouten einer Benutzeroberfläche BO erfolgt. Auf der linken Seite sind unterschiedliche Protokolle dargestellt (Protokoll 1, 2, N, ...), die eine Angabe in Bezug auf die Parameter und das diesbezügliche Layout umfassen. Das Verfahren greift vorzugsweise auf eine Datenbank zu, in der Layout-Daten zentral abgelegt sind. Hier sind neben den benutzerspezifischen Oberflächen BO auch Default-Benutzeroberflächen gespeichert. Aufgrund der jeweiligen Zuordnung wird erfindungsgemäß automatisch eine Benutzeroberfläche BO generiert, die in 1 auf der rechten Seite der Figur dargestellt ist. In diesem Fall werden die Steuerelemente S (Parameter Par_a, Par_b, Par_c und Par_d) dargestellt. Die Positionierung der Steuerelemente S erfolgt vorzugsweise so, das ein minimaler Platzbedarf auf dem Bildschirm verbraucht ist. Ergebnis des Verfahrens ist also eine sichtbare Benutzeroberfläche BO, die unterschiedliche Parameter-Kartenstapel umfasst, wie es in den rechten drei Kästen in 1 dargestellt ist. 1 zeigt somit einen so genannten USE-Modus, in dem ein Anwender ein spezifisches Layout bestimmt (z.B: durch Angabe eines Layout-Namens), das dann für alle offenen Protokolle bzw. Applikationen als Layout erscheint. Alternativ können zu zentral abgelegten Layout-Daten auch benutzerspezifische Daten beim Generieren der Benutzeroberfläche BO verwendet werden, wie es ebenfalls in 1 angedeutet ist durch den mittigen unteren Kasten. Hier können benutzerspezifische Datensätze abgelegt und/oder verwaltet werden („User Layout 1").
  • In einer nicht dargestellten Ausführungsform kann der USE-Modus auch über einen geeigneten Deaktivierungsmodus (beispielsweise eine vordefinierte Taste oder Tastenkombination) deaktiviert bzw. abgeschaltet werden. Dann werden wieder die Layout-Informationen jedes einzelnen Protokolls benutzt. Dann könnte prinzipiell – und falls gewünscht – die jeweils generierte Benutzeroberfläche BO für jedes Protokoll unterschiedlich aussehen.
  • Zur Laufzeit kann der Benutzer die Benutzeroberfläche BO auswählen, die für die Applikation geeignet ist. Dies erfolgt in der Regel dadurch, dass der Benutzer den jeweiligen Layout-Namen (in 1 beispielsweise mit Layout 1, Layout 2, Layout 3, ..., Default-Layout bezeichnet) in einem zentralen Verzeichnis angibt bzw. auswählt. Dann wird das von ihm ausgewählte Layout zum Generieren der Benutzeroberfläche BO verwendet. Dies betrifft den bereits erwähnten USE-Modus der erfindungsgemäßen Lösung. Dabei wird das vom Benutzer ausgewählte Layout verwendet, während die Informationen im Protokoll zum Erstellen der Benutzeroberfläche BO ignoriert werden. Die Protokoll-Informationen werden jedoch nicht verändert. Ergebnis ist, dass bei allen geöffneten Protokollen das vom Benutzer spezifizierte Layout erscheint.
  • In einer alternativen Weiterbildung der Erfindung kann es vorgesehen sein, neue Layout-Daten an ein bestimmtes Protokoll zu binden. Die Steuerelemente S, insbesondere die Parameter werden dann an zumindest ein ausgewähltes Layout gebunden. Die bisherigen protokoll-spezifischen Layout-Daten werden in diesem Fall ignoriert und nicht mehr verwendet, sondern durch das neu ausgewählte Layout ersetzt. Somit kann eine erhöhte Flexibilität erreicht werden, indem eine dynamische Zuordnung von Benutzeroberflächen-Varianten zu den Applikationen möglich wird. Soll ein bestimmtes Layout an eine bestimmte Applikation geknüpft werden bzw. dieser zugeordnet werden, so ist es einstellbar, in welchem Umfang diese Zuordnung erfolgen soll. Es ist beispielsweise möglich, diese Zuordnung mit einem zeitlich eingeschränkten Kontext (z. B. nur temporär) oder in einem strukturell eingeschränkten Kontext (z. B. nur für bestimmte Krankenhausabteilungen) oder entsprechend nur in einem funktional eingeschränkten Kontext (nur für spezifische Applikationen) vorzusehen. Damit kann der Umfang des Geltungsbereiches einer erfindungsgemäß generierten Benutzeroberfläche BO variabel eingestellt werden.
  • Es ist auch möglich, vordefinierte Default-Layouts zu verwenden, die bei Auslieferung des jeweiligen Produktes voreingestellt sind. Dies verbessert die Einarbeitungszeit bei einem neuen Produkt und kann als Sonderfall die bisher gewohnte Benutzeroberfläche aus alten Softwareversionen simulieren.
  • In 2 ist nochmals das erfindungsgemäße Ersetzen von bisher eingestellten Layout-Daten durch neue Layout-Daten dargestellt. Wie in 2 angedeutet, wird aus zentral abgelegten Layout-Daten (Layout 1, Layout 2, Layout 3, Default-Layout) ein spezifisches Layout ausgewählt und einem oder mehreren Protokollen (in 2 den Protokollen 2 und 3) zugeordnet ("Assign Layout MyUI2"). Dies führt dazu, dass das Protokoll 2, für das bisher das Layout 2 galt und das Protokoll 3, für das bisher das Layout 3 galt, ersetzt werden durch das Layout "MyUI2".
  • Wie vorstehend erwähnt, handelt es sich bei den Steuerelementen S um Parameter-Eingabeoptionen, die in der Regel numerische Parametertypen (z. B. long, double), textuelle Typen (z. B. String), sowie Parameter vom Typ "Bool", "Array", "Container-Parametertypen" umfassen. In alternativen Ausführungsformen sind andere grafische Repräsentationen der Parameter-Eingabeoptionen denkbar, wie etwa icon-basierte Eingabeoptionen.
  • Ein wesentliches Konzept der vorliegenden Erfindung ist darin zu sehen, dass nur Grundinformationen in Hinblick auf die relevanten Steuerelemente S, insbesondere Parameter und Parameter-Karten, veränderlich und speicherbar sind. Die grafischen Details der Anzeige auf dem Bildschirm bleiben jedoch weiterhin der Implementierung der entsprechenden UI-Komponente vorbehalten. Damit kann erreicht werden, dass das grafische "Look-and-feel" der Benutzeroberfläche für eine bestimmte Software-Version konstant bleibt und nicht modifiziert werden kann, damit sich der Benutzer zur Laufzeit der jeweiligen Applikation nicht umgewöhnen muss. Modifizierbar und speicherbar sind erfindungsgemäß nur die für eine jeweilige Applikation als relevant ausgewählten Steuerelemente S. Somit werden also nur die Parameter bzw. die Parameter-Karten angezeigt, die für die Applikation auch notwendig sind, um den Anwender nicht mit unnötigen Zusatzinformationen und Auswahlmöglichkeiten zu belasten.
  • In einer vorteilhaften Weiterbildung der Erfindung ist es einstellbar, in welcher Art und Weise die Steuerelemente S auf der Benutzeroberfläche BO angezeigt werden sollen. Beispielsweise können einige Steuerelemente S in Form eines Schalters (als Boolscher Parameter), textuell oder rein grafisch repräsentiert werden. Die jeweilige grafische Repräsentation der Steuerelemente S ist konfigurierbar und vom Benutzer einstellbar.
  • Wird die Karten-Repräsentation für die Steuerelemente S gewählt, mit entsprechenden Sub-Karten und Sub-Sub-Karten, so können die Namen der jeweils untergeordneten Karten als überschriftsartige Kartenreiter am oberen Ende der Karte angeordnet sein.
  • In 3 sind zwei alternative Ausführungen einer Benutzeroberfläche BO, BO' am Beispiel eines Schalter-Parameters dargestellt. Auf der linken Seite ist die Benutzeroberfläche BO dargestellt, die auf einem klassischen, textuellen Layout basiert und auf der rechten Seite ist die Benutzeroberfläche BO' dargestellt, die auf einer icon-basierten Repräsentation basiert. Damit auch zur Laufzeit ein Wechsel zwischen den vorstehend erläuterten unterschiedlichen Designs für eine Benutzeroberfläche BO möglich ist, ist auch für eine Karte als Ganzes eine Darstellungsoption vorgesehen.
  • In der bevorzugten Ausführungsform umfasst das erfindungsgemäße Verfahren drei unterschiedliche Modi:
    • – einen DEFINE-Modus,
    • – einen USE-Modus und
    • – einen ASSIGN-Modus.
  • Der DEFINE-Modus dient zum interaktiven Erzeugen bzw. Generieren einer Benutzeroberfläche BO, der USE-Modus wendet diese generierte Benutzeroberfläche an und stellt sie auf dem Bildschirm dar und der ASSIGN-Modus dient zum Zuordnen und Speichern von einem oder mehreren Layout(s) zu einem oder mehreren Protokollen. Für die jeweiligen Modi sind Aktivierungs- und Deaktivierungs-Mechanismen vorgesehen, um die jeweiligen Modi zu aktivieren bzw. zu deaktivieren. Im DEFINE-Modus können die Parameter, die auf der neuen Karte erscheinen sollen, durch Selektieren auf einer bisherigen Karte ausgewählt werden. Darüber hinaus ist es möglich, die jeweils selektierten Parameter auf der neu zu erstellenden Karte zu verschieben bzw. diese wieder zu entfernen.
  • In dem vorstehend beschriebenen Fall wird ein bestehendes Layout herangezogen, um darauf basierend ein neues Layout zu erstellen. Alternativ ist es auch möglich, kein altes bisheriges Layout zu verwenden, sondern das neue Layout durch die explizite Angabe der Parameter manuell zu generieren. Üblicherweise ist es erfindungsgemäß vorgesehen, dass bei einer Neupositionierung eines Steuerelementes S, die ein anderes Steuerelement S' überdeckt, automatisch eine Verschiebung der jeweiligen Steuerelemente S, S' in Bezug aufeinander ausgeführt wird, so dass keine Überlappungen bzw. Überlagerungen erzeugt werden. Dies erfolgt vorzugsweise automatisch.
  • In einer einfachen Ausführungsform der Erfindung ist es vorgesehen, dass die neu zu generierende Benutzeroberfläche BO auf Basis der bisherigen Benutzeroberfläche generiert wird. Mit anderen Worten werden üblicherweise aus der Menge der bisherigen Steuerelemente S und/oder bisherigen Steuergruppen nur die relevanten ausgewählt. Die nicht-relevanten Steuerelemente S werden nicht auf der Benutzeroberfläche BO angezeigt. Dabei bleiben aber die bisherigen Reihenfolgen der Steuerelemente S und/oder der Steuergruppen erhalten. Aus dem Ausgangs-Layout können somit nur einzelne Parameter und/oder Parameter-Gruppen gelöscht werden. Dies hat den Vorteil, dass der Benutzer sich nicht grundsätzlich umzugewöhnen braucht.
  • Grundsätzlich kann ein neu definiertes Layout auch zu einem späteren Zeitpunkt modifiziert werden, indem wieder in den DEFINE-Modus zurückgekehrt wird.
  • Im USE-Modus wird ein vorher definiertes Layout zur Steuerung der aktuell sichtbaren Karten ausgewählt. Dies erfolgt üblicherweise über die Angabe eines dem Layout zugeordneten Namens. Daraufhin erfolgt eine Darstellung entsprechend des ausgewählten Layouts. Wird der USE-Modus deaktiviert, so werden die aktuellen Parameter bzw. Parameter-Karten wieder durch die Layout-Daten gesteuert, die in dem jeweiligen Protokoll abgelegt sind.
  • Durch den ASSIGN-Modus wird es möglich, ein bestimmtes Layout einem oder mehreren Protokollen fest zuzuordnen. Dazu ist es lediglich notwendig, den Namen des jeweiligen Layouts aus einer Liste von möglichen Layouts in dem ASSIGN-Modus auszuwählen. Die Zuordnung erfolgt automatisch. Dieses ausgewählte Layout ersetzt dann die bisherigen Layouts für alle selektierten Protokolle und wird zur Steuerung der Benutzeroberfläche BO verwendet.
  • In 4 ist gezeigt, wie basierend auf einer bereits bestehenden Oberfläche BO (oben dargestellt) eine neue Oberfläche BO' (unten dargestellt) mit einem neuen Steuerelement S generiert werden soll. Solange der DEFINE-Modus aktiv ist, erscheint, wie bei der oberen, bestehenden Oberfläche BO gezeigt, diese neue Subkarte zusätzlich zu den bisher verwendeten Karten. Die neue Karte kann, wie die anderen auch, aufgeklappt werden, um Details zu ändern. Ebenso ist es möglich, die Steuerelemente S unverändert auf die neue Karte zu übernehmen. Die entsprechenden Daten werden dann automatisch auf die neue Karte bzw. Oberfläche BO' übertragen. Wie auf der unteren, neuen Karte in 4 gezeigt, ist es zusätzlich möglich, die jeweils selektierten Steuerelemente S (Parameter) zu verschieben oder wieder von dieser Karte zu entferenen.
  • In 4 ist für eine Sub-Karte beispielhaft dargestellt, wie ein neues Steuerelement S im DEFINE-Modus automatisch so verschoben wird, dass keine Überdeckung mit anderen Steuerelementen S erfolgt. Dabei sind ein Verschieben und ein Löschen einzelner Parameter möglich. In der Sub-Karte (Sub Card 1) kann der neue Parameter "TE...(ms)" verschoben oder gelöscht werden.
  • 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. Für einen einschlägigen Fachmann ist es insbesondere offensichtlich, dass die Erfindung teilweise oder vollständig in Soft- und/oder Hardware und/oder auf mehrere physikalische Produkte – dabei insbesondere auch Computerprogrammprodukte – verteilt realisiert werden kann.

Claims (14)

  1. Verfahren zum Generieren einer Benutzeroberfläche (BO) für jeweils zumindest eine medizinische Applikation aus einer Menge von Applikationen für ein medizinisches Gerät, mit folgenden Verfahrensschritten: – Bestimmen der Applikation, für die die Benutzeroberfläche (BO) generiert werden soll, – Erfassen von Steuerelementen (S), die zur Steuerung der bestimmten Applikation relevant sind, – Positionieren der relevanten Steuerelemente (S) und/oder von in Steuergruppen zusammengefassten relevanten Steuerelementen nach konfigurierbaren Positionierungskriterien auf einem Bildschirm.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Steuerelemente (S) grafische Repräsentationen für eine Parameter-Eingabe sind.
  3. Verfahren nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass die Steuergruppe in Form einer Karte ausgebildet ist.
  4. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass einer für eine Applikation generierten Benutzeroberfläche (BO) eine Referenz zugeordnet wird, mittels der diese zu einem späteren Zeitpunkt, insbesondere bei Ausführung der jeweiligen Applikation, abrufbar und/oder ausführbar ist.
  5. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für eine Menge von Applikationen eine Benutzeroberfläche (BO) generiert wird.
  6. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren auf einer bereits existierenden Benutzeroberfläche (BO) aufsetzt, diese simuliert und/oder diese hinsichtlich der existierenden Steuerelemente (S) verändert, insbesondere existierende Steuerelemente (S) verschiebt, löscht und/oder neue Steuerelemente (S) hinzufügt und somit eine neue Benutzeroberfläche (BO') generiert.
  7. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass auch zur Laufzeit der Applikation ein Wechsel zwischen unterschiedlichen Benutzeroberflächen (BO) für die Applikation möglich ist.
  8. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Steuerelemente (S) hierarchisch strukturiert sind und Sub-Steuerelemente umfassen, insbesondere Sub-Karten.
  9. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Erfassen von relevanten Steuerelementen (S) automatisch oder halbautomatisch ausgeführt wird.
  10. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren zusätzlich folgenden Verfahrensschritt umfasst: – Darstellung der generierten Benutzeroberfläche (BO) mit den als relevant ausgewählten Steuerelementen (S) zur Steuerung der Applikation.
  11. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren zusätzlich folgenden Verfahrensschritt umfasst: – Gruppieren von mehreren relevanten Steuerelementen (S) zu einer Steuergruppe nach konfigurierbaren Strukturierungskriterien.
  12. System zum Generieren einer Benutzeroberfläche (BO) für jeweils zumindest eine medizinische Applikation aus einer Menge von Applikationen für ein medizinisches Gerät, mit: – einem Applikations-Bestimmungsmodul, das dazu ausgelegt ist, die Applikation zu bestimmen, für die die Benutzeroberfläche (BO) generiert werden soll, – einem Erfassungsmodul, das dazu bestimmt ist, die Steuerelemente zu erfassen, die zur Steuerung der vom Applikations-Bestimmungsmodul bestimmten Applikation relevant sind, wobei die jeweiligen Steuerelemente (S) eine Schnittstelle zur Applikation umfassen, – einem Positionierungsmodul, das dazu ausgebildet ist, die relevanten Steuerelemente (S) und/oder in Steuergruppen zusammengefasste relevante Steuerelemente (S) nach konfigurierbaren Positionierungskriterien auf einem Bildschirm so zu positionieren, dass ein optimiertes, insbesondere platzoptimiertes Layout erzielt wird.
  13. Speichermedium, das zur Speicherung eines Verfahrens gemäß zumindest einem der Ansprüche 1 bis 11 bestimmt ist und von einem Computer lesbar ist.
  14. Computerprogrammprodukt, welches direkt in einen Speicher eines Computers ladbar ist, mit Programm-Code-Mitteln, um alle Schritte eines Verfahrens nach zumindest einem der Verfahrensansprüche 1 bis 11 auszuführen, wenn das Programm in dem Computer ausgeführt wird.
DE102006051447A 2006-10-31 2006-10-31 Verfahren und System zum Generieren einer Benutzeroberfläche Withdrawn DE102006051447A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102006051447A DE102006051447A1 (de) 2006-10-31 2006-10-31 Verfahren und System zum Generieren einer Benutzeroberfläche
US11/930,463 US8086965B2 (en) 2006-10-31 2007-10-31 Method and system for generation of a user interface

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102006051447A DE102006051447A1 (de) 2006-10-31 2006-10-31 Verfahren und System zum Generieren einer Benutzeroberfläche

Publications (1)

Publication Number Publication Date
DE102006051447A1 true DE102006051447A1 (de) 2008-05-08

Family

ID=39264711

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102006051447A Withdrawn DE102006051447A1 (de) 2006-10-31 2006-10-31 Verfahren und System zum Generieren einer Benutzeroberfläche

Country Status (2)

Country Link
US (1) US8086965B2 (de)
DE (1) DE102006051447A1 (de)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4870601B2 (ja) * 2007-03-17 2012-02-08 株式会社リコー 画面データ生成装置、画像処理装置、画面データ生成方法及びプログラム
US20120053422A1 (en) * 2010-08-24 2012-03-01 General Electric Company Method, Device and Computer Program Product for Monitoring Patients Receiving Care
DE102013226332A1 (de) * 2013-12-18 2015-06-18 Siemens Aktiengesellschaft Verfahren zur Bearbeitung eines insbesondere medizinischen Bilddatensatzes
KR101788742B1 (ko) * 2015-12-28 2017-10-20 삼성전자주식회사 자기 공명 영상 촬영을 위한 파라미터 정보 출력 방법 및 장치
US11856671B1 (en) 2016-11-28 2023-12-26 Smart Power Partners LLC Multi-element lighting apparatus and a method of implementing a multi-element lighting
US12093004B1 (en) 2017-04-01 2024-09-17 Smart Power Partners LLC In-wall power adapter and method of implementing an in-wall power adapter
US12027968B2 (en) 2017-04-01 2024-07-02 John J. King Power adapters and methods of implementing a power adapter
US10418813B1 (en) 2017-04-01 2019-09-17 Smart Power Partners LLC Modular power adapters and methods of implementing modular power adapters
US10996645B1 (en) 2017-04-01 2021-05-04 Smart Power Partners LLC Modular power adapters and methods of implementing modular power adapters
US20180349153A1 (en) * 2017-06-06 2018-12-06 International Business Machines Corporation Migration between different user interfaces of software programs
CN108538379A (zh) * 2017-12-29 2018-09-14 上海联影医疗科技有限公司 磁共振参数卡中参数的处理方法及磁共振参数卡界面
US11231730B1 (en) 2019-06-30 2022-01-25 Smart Power Power LLC Control attachment for a power adapter configured to control power applied to a load
US11990712B1 (en) 2019-06-30 2024-05-21 Smart Power Partners LLC Control attachment for a power adapter and method of implementing a control attachment
US12066848B1 (en) 2019-06-30 2024-08-20 Smart Power Partners LLC In-wall power adaper adapted to receive a control attachment and method of implementing a power adapter
US11201444B1 (en) 2019-06-30 2021-12-14 Smart Power Partners LLC Power adapter having contact elements in a recess and method of controlling a power adapter
US12045071B1 (en) 2019-06-30 2024-07-23 Smart Power Partners LLC In-wall power adapter having an outlet
US10965068B1 (en) 2019-06-30 2021-03-30 Smart Power Partners LLC In-wall power adapter having an outlet and method of controlling an in-wall power adapter
US11043768B1 (en) 2019-06-30 2021-06-22 Smart Power Partners LLC Power adapter configured to provide power to a load and method of implementing a power adapter
US10917956B1 (en) 2019-06-30 2021-02-09 Smart Power Partners LLC Control attachment configured to provide power to a load and method of configuring a control attachment
US11264769B1 (en) 2019-06-30 2022-03-01 Smart Power Partners LLC Power adapter having contact elements in a recess and method of controlling a power adapter
US10938168B2 (en) 2019-06-30 2021-03-02 Smart Power Partners LLC In-wall power adapter and method of controlling the application of power to a load
DE102021202958B4 (de) * 2021-03-25 2023-12-28 Siemens Healthcare Gmbh Verfahren zum Betrieb einer Magnetresonanzeinrichtung, Magnetresonanzeinrichtung, Computerprogramm und elektronisch lesbarer Datenträger

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5596702A (en) * 1993-04-16 1997-01-21 International Business Machines Corporation Method and system for dynamically sharing user interface displays among a plurality of application program
DE69718230T2 (de) * 1996-04-09 2003-09-25 Ibm Mobile Datenverarbeitung mit orts-/bewegungsempfindlicher Benutzerschnittstelle

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040015079A1 (en) * 1999-06-22 2004-01-22 Teratech Corporation Ultrasound probe with integrated electronics
WO2002086797A1 (en) * 2001-03-06 2002-10-31 The John Hopkins University School Of Medicine Simulation method for designing customized medical devices
US20020184055A1 (en) * 2001-05-29 2002-12-05 Morteza Naghavi System and method for healthcare specific operating system
US7275235B2 (en) 2001-08-29 2007-09-25 Molinari Alfred A Graphical application development system for test, measurement and process control applications
DE10225316A1 (de) 2002-06-06 2003-12-18 Philips Intellectual Property Verfahren zur Optimierung der Darstellung von mittels Bedienelemente frei platzier-und skalierbaren Objekten einer Benutzeroberfläche auf einem Bildschirm
US8745541B2 (en) * 2003-03-25 2014-06-03 Microsoft Corporation Architecture for controlling a computer using hand gestures
US20060010011A1 (en) * 2004-02-10 2006-01-12 James Ullom Dynamic medical data acquisition
US20070232866A1 (en) * 2004-03-31 2007-10-04 Neptec Design Group Ltd. Medical Patient Monitoring and Data Input Systems, Methods and User Interfaces
WO2005119505A2 (en) * 2004-06-04 2005-12-15 Stereotaxis, Inc. User interface for remote control of medical devices

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5596702A (en) * 1993-04-16 1997-01-21 International Business Machines Corporation Method and system for dynamically sharing user interface displays among a plurality of application program
DE69718230T2 (de) * 1996-04-09 2003-09-25 Ibm Mobile Datenverarbeitung mit orts-/bewegungsempfindlicher Benutzerschnittstelle

Also Published As

Publication number Publication date
US20080104533A1 (en) 2008-05-01
US8086965B2 (en) 2011-12-27

Similar Documents

Publication Publication Date Title
DE102006051447A1 (de) Verfahren und System zum Generieren einer Benutzeroberfläche
DE69735628T2 (de) Verfahren und system zum auswählen eines informationssatzes in einem informationsverarbeitungssystem und lokale station in einem solchen system
DE69626620T2 (de) Datenverarbeitung in Systemen, die eine visuelle Darstellung einer physischen Umgebung zeigen
DE68919503T2 (de) Methode und System zur Darstellung einer Benutzeroberfläche auf einem Computerbildschirm.
DE10351351B4 (de) Verfahren und System zur dynamischen Generierung von User Interfaces
DE69327948T2 (de) Bereich-layout in einer Sicht auf einem grafischen Anzeigeschirm
DE68915847T2 (de) Tastatur-Umbelegung.
DE10353846A1 (de) Verfahren zur Vorbereitung von für die Durchführung von medizinischen oder chirurgischen Eingriffen bestimmten Geräten
DE10009297A1 (de) Dynamisches Hilfesystem für eine Datenverarbeitungseinrichtung, insbesondere für eine Internet- oder Desktopanwendung
DE19629093C2 (de) Medizinische Therapie- und/oder Diagnoseanlage
DE102008017846A1 (de) Verfahren und Benutzerschnittstelle für die grafische Darstellung von medizinischen Daten
DE602005002906T2 (de) Methode und Vorrichtung zur Beschreibung von Haushaltselektronik unter Verwendung von separaten Aufgaben- und Gerätebeschreibungen
DE102013203831A1 (de) Verfahren und System für ein Master-Seiten-basiertes integriertes Editieren und eine dynamische Layout-Aktivierung
DE69930352T2 (de) Verfahren und Vorrichtung zur Animierung von Videospezialeffekten
DE69622338T2 (de) Verfahren und system zum einbetten von teilen eines dokuments und zum synchronisieren einer vielzahl der ansichten dieser teile
DE60032403T2 (de) Speziell adaptierte Wiedergabe und Darstellung von Datenbankinformationen
DE102010042999A1 (de) Verfahren zur Bereitstellung eines Bedienmenüs für ein Feldgerät der Prozessautomatisierungstechnik
WO2008148238A1 (de) Fernbedienung eines browser-programms
DE68926119T2 (de) Verfahren zur anzeige oder zum speichern von beziehungsänderungen zwischen objekten in einem datenverarbeitungssystem
DE102008017831A1 (de) Verfahren und Benutzerschnittstelle zur Erzeugung und Darstellung medizinischer Untersuchungsergebnisse
DE102009011643A1 (de) Verfahren und Programmprodukt für ein Erstellen von medizinischen Befunden anhand von medizinischen Bilddaten
DE102009010908A1 (de) Verfahren und Anordnung zur Steuerung des Einfügens von Registerblättern in einen Druckauftrag sowie ein entsprechendes Computerprogramm und ein entsprechendes computerlesbares Speichermedium
DE102007052813B3 (de) Verfahren und System zur Datenverarbeitung in einer Multi-Monitor-Umgebung
DE102020132332A1 (de) Verfahren zur Steuerung eines cloudbasierten landwirtschaftlichen Datenbanksystems
DE3588007T2 (de) Verwaltungssystem für relationale datenbank.

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8120 Willingness to grant licences paragraph 23
R084 Declaration of willingness to licence

Effective date: 20110304

R081 Change of applicant/patentee

Owner name: SIEMENS HEALTHCARE GMBH, DE

Free format text: FORMER OWNER: SIEMENS AKTIENGESELLSCHAFT, 80333 MUENCHEN, DE

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee