System zur Erstellung und zum Betrieb von Softwareapplikatio ^¬ nen

5

Die Erfindung bezieht sich auf ein System zur Erstellung von Softwareapplikationen sowie zum Betrieb dieser Softwareapplikationen auf einer Mehrzahl von unterschiedlichen Geräten. Das System findet hierbei insbesondere Anwendung zur Erstel ^¬ lt] lung und zum Betrieb von Softwareapplikationen zur Verarbeitung von medizinischen Daten, insbesondere zur Anzeige und Bearbeitung von medizinischen Bilddaten.

Medizinische Arbeitsabläufe (Workflows) werden in zunehmendem 15 Maße unter Beteiligung einer Vielzahl von (Datenverarbei- tungs- ) Geräten, z.B. computergestützten bildgebenden Modalitäten wie Computertomographen oder Magnetresonanztomographen sowie spezialisierten Computersystemen durchgeführt. Um diese komplexen Arbeitsabläufe zu unterstützen, haben sich eine 20 Vielzahl von spezialisierten ( Software- ) Applikationen mit

teils überlappendem, teils sich ergänzendem Funktionsumfang herausgebildet .

Zusätzlich zu den klassischen, stationären Datenverarbei- 25 tungsgeräten wie z.B. Befundungsstationen werden in der medizinischen Praxis in zunehmendem Umfang auch mobile Kleingeräte wie Smartphones oder Tablet-Computer eingesetzt, was zu einer weiteren Diversifizierung der bereitzustellenden Applikationen und Applikationsvarianten führt.

30

Diese Umstände führen dazu, dass ein Benutzer im Zuge der Abarbeitung eines medizinischen Arbeitsablaufs häufig die Ap ^¬ plikation und/oder das Gerät wechselt. Typischerweise ist ein solcher Applikations- oder Gerätewechsel allerdings mit einem 35 merklichen Verlust an Effizienz (und somit Bearbeitungszeit) verbunden, zumal der Benutzer nach einem solchen Wechsel in aller Regel nicht unmittelbar an dem Punkt fortfahren kann, an dem er den Arbeitsablauf zuvor verlassen hatte. Vielmehr müssen stets die mit dem Arbeitsablauf verknüpften Daten erneut gesucht und geladen werden. Weiterhin müssen in der Regel die Einstellungen der jeweiligen Applikation erneut auf die Bedürfnisse des jeweiligen Benutzers und des zu bearbei- tenden Arbeitsablaufs eingestellt werden. Zudem besteht bei Applikations- und Gerätewechseln stets eine gewisse Gefahr, dass Arbeitsergebnisse verloren gehen, weil sie nicht ord ^¬ nungsgemäß abgespeichert werden und/oder nicht rechtzeitig oder nicht korrekt an der neuen Applikation bzw. dem neuen Gerät verfügbar sind.

Ein weiteres Problem, das ebenfalls zu Effizienzverlusten in medizinischen Arbeitsabläufen führt, besteht darin, dass die verschiedenen, in einem Arbeitsablauf verwendeten Applikatio- nen und Geräte regelmäßig unterschiedliche Bedienmethoden fordern und ein unterschiedliches Bedienverhalten (also eine unterschiedliche Reaktion auf vergleichbare Benutzerinterak ^¬ tionen) zeigen. Verschiedene Applikationen weisen somit regelmäßig ein unterschiedliches „Look & Feel" auf. Der Benut- zer muss daher regelmäßig unterschiedliche Applikationen

(auch gleichnamige Applikationen an unterschiedlichen Geräten) verschieden bedienen, was einen hohen Lernaufwand kostet und Bedienfehler provoziert. Eine Ursache für die vorstehend beschriebenen Probleme be ^¬ steht darin, dass Applikationen und Applikationsvarianten weitegehend unabhängig voneinander erstellt werden müssen, da die speziellen Anforderungen für die verschiedenen medizinischen Aufgaben, aber auch die verschiedenen Formfaktoren der verwendeten Geräte einer stärkeren Integration medizinischer Software-Lösungen im Wege stehen.

Der Formfaktor wird hierbei insbesondere geprägt durch die an einem Gerät verfügbare Bildschirmfläche und -auflösung, die bei den eingesetzten Geräten - Workstations mit mehreren

Bildschirmen auf der einen Seite und Smartphones auf der anderen Seite - extrem verschieden ist und daher unterschiedli- che Lösungen bei der Gestaltung von Applikationen und deren Benutzeroberflächen erfordert.

Moderne medizinische Applikation sind in der Regel mehr- schichtig aufgebaut und somit horizontal gegliedert. So ist bei einer solchen Applikation die Präsentationslogik, die die Benutzeroberfläche (UI) definiert, von der sogenannten Ge ^¬ schäftslogik (GL), d.h. der auf eigentliche Aufgabe der Applikation gerichteten Logik, getrennt.

Ein etabliertes Paradigma zur Gestaltung von Applikationen mit graphischer Benutzeroberfläche ist desweiteren das soge ^¬ nannte MVVM(Model View ViewModel ) -Konzept . Gemäß diesem Kon ^¬ zept wird der „View", also die graphischen Elemente der Be- nutzeroberfläche, von der Funktion der Benutzeroberfläche, der auch als „ViewModel" bezeichneten UI-Logik, getrennt. Diese wiederum ist getrennt von dem „Model", d.h. der Datenzugriffsschicht für die Nutzdaten, die einem Benutzer ange ^¬ zeigt und bearbeitet werden. Das ViewModel stellt somit einen Mittler zwischen dem „View" und dem „Model" dar.

Die vorstehend beschriebenen Paradigma erleichtern zwar allgemein die - insbesondere hochgradig arbeitsteilige - Erstel ^¬ lung von Applikationen, bieten aber dennoch keine befriedi- genden Lösungen für das vorstehend skizzierte Dilemma, dass einerseits eine einfache Bedienung und Erstellung der viel ^¬ fältigen medizinischen Applikationen und Applikationsvarianten ermöglicht werden soll (was herkömmlicherweise nur über eine möglichst starke Vereinheitlichung der verschiedenen Ap- plikationen und Applikationsvarianten zu erzielen ist) , dass aber andererseits eine individuelle Anpassung dieser Applika ^¬ tionen und Applikationsvarianten an den jeweiligen Einsatzzweck und die verwendeten Geräte sicherzustellen ist (was herkömmlicherweise eine Diversifizierung der Applikationen und Applikationsvarianten bedingt und somit die Applikations ^¬ bedienung und -erstellung erschwert) . Der Erfindung liegt die Aufgabe zugrunde, dieses Problem zu lösen .

Diese Aufgabe wird erfindungsgemäß gelöst durch ein System zur Erstellung von Softwareapplikationen, insbesondere zur Verarbeitung von medizinischen Daten, sowie zum Betrieb dieser Softwareapplikationen auf einer Mehrzahl von unterschiedlichen Geräten. Als zentrales Element stellt das System eine Anzahl von abge ^¬ grenzten Softwarestrukturen (also mindestens eine solche Softwarestruktur, vorzugsweise aber mehrere) zur Verfügung, wobei jeder dieser Softwarestrukturen eine bestimmte Funktion zugeordnet ist. Diese Softwarestrukturen sind daher nachfol- gend auch als „Funktionseinheiten" oder - im Sinne einer kurzen und prägnanten Bezeichnung - als „Spikes" bezeichnet.

Jeder dieser Spikes ist hierbei mehrfach in verschiedenen Softwareapplikationen, optional aber auch mehrfach in ein und derselben Softwareapplikation instanziierbar . Als „Instanz" eines Spikes wird hierbei eine Ausprägung dieses Spikes be ^¬ zeichnet, die Teil einer bestimmten Applikation ist und auf einem bestimmten Gerät abläuft und an diese Applikationen sowie dieses Gerät angepasst ist.

Jeder Spike definiert dabei einen abgegrenzten (UI-) Bereich einer graphischen Benutzeroberfläche (GUI). Der einem Spike zugeordnete UI-Bereich ist hierbei optional auf der graphi ^¬ schen Benutzeroberfläche durch einen Rahmen, ein Fenster, ei- ne Farbfläche oder dergleichen optisch hervorgehoben. Die

Grenzen des dem Spike zugeordneten UI-Bereichs müssen allerdings im Rahmen der Erfindung nicht zwingend sichtbar markiert sein. Im Rahmen der Erfindung kann ein Spike beispielsweise eine der folgenden Funktionen bereitstellen: • ein UI-Fenster (Bildanzeige-Segment) zur Anzeige eines digitalen medizinischen Bildes,

• ein UI-Fenster, das Spezial-Funktionen zur Bearbeitung von medizinischen Bilddaten, insbesondere ein kohärentes (funktional eigenständiges) Sub-Menü eines Bildanzeige-

Segments enthält,

• ein virtuelles Schaltfeld (Control Panel) , das Einstell ^¬ regler zur Einstellung von Bildmanipulationsfunktionen oder zur Ansteuerung einer bildgebenden Modalität um- fasst,

• ein Anzeigefeld (Viewer) für Videodateien,

• ein UI-Fenster, das demographische Angaben zu einem Patienten (z.B. Name, Patienten-Identifikationsnummer, Adresse, Geburtsdatum, etc.) anzeigt,

· ein UI-Fenster, das eine Liste der geöffneten Patientenakten bzw. Studien oder eine Liste (Worklist) von zu be ^¬ arbeitende Aufgaben darstellt, oder

• ein Suchfeld. Hinsichtlich seines Aufbaus ist jeder Spike in zwei Teile ge ^¬ gliedert, nämlich:

• Einen spezifischen Teil, der für jede Instanz des Spike

(und somit für jede Applikation und/oder jedes Gerät) unterschiedlich vorgebbar ist, sowie

• einen generischen Teil, der den internen Zustand einer jeden Instanz eines Spikes in einer verallgemeinerten Form geräte- und applikationsunabhängig beschreibt. Der spezifische Teil definiert hierbei in einer Präsentati ^¬ onsschicht eine Anzahl von UI-Elementen, d.h. Elementen einer graphischen Benutzeroberfläche (GUI) mit einem vorgegebenen Satz von zugehörigen UI-Zustandsvariablen . Der spezifische Teil eines jeden Spikes gleicht insofern der Präsentations- schicht einer herkömmlichen Applikation.

Der generische Teil eines jeden Spikes ist nun dazu einge ^¬ richtet, die Werte der UI-Zustandsvariablen in eine geräte- und applikationsunabhängige Form zu transformieren und in dieser Form als Zustandsdatensatz zu exportieren. Desweiteren ist der generische Teil eines jeden Spikes auch dazu einge ^¬ richtet, einen solchen Zustandsdatensatz zu importieren und die darin enthaltenen Werte (ggf. nach Rücktransformation in die jeweils passende geräte- und applikationsspezifische Form) den UI-Zustandsvariablen der UI-Elemente des spezifischen Teils zuzuweisen. Der generische Teil eines jeden Spikes bildet somit eine Art Mittler oder Adapter, über den die verschiedenen Instanzen desselben Spikes ihren internen Zustand über Geräte- und Applikationsgrenzen hinweg austauschen können. Diese Zustands- übertragung ermöglicht es einem Benutzer, einen an einem be- stimmten Gerät und einer bestimmten Applikation begonnenen

Arbeitsablauf nach einem Geräte- und/oder Applikationswechsel ohne signifikanten Effizienz- und Zeitverlust fortzusetzen. Mithin wird durch die Zustandsübertragung das „Feel" der ursprünglichen Applikation auf ein anderes Gerät und/oder oder eine andere Applikation übertragen.

Gleichzeitig kann aber mit dem spezifischen Teil eines jeden Spikes die äußere Erscheinungsform (also der „Look") für jede Instanz an die spezifischen Gegebenheiten und Erfordernisse des jeweiligen Geräts und der jeweiligen Applikation ange- passt werden, insbesondere kann jede Instanz eines Spikes durch Adaption des spezifischen Teils an den Formfaktor des zugehörigen Geräts angepasst werden. Der Benutzer profitiert somit von den im Rahmen des Systems zur Verfügung gestellten Spikes dahingehend, dass er das ihm vertraute „Feel" eines Spikes von Gerät zu Gerät und von Ap ^¬ plikation zu Applikation „mitnehmen" kann, jeweils aber einen auf das jeweilige Gerät und die jeweilige Applikation opti- mierten „Look" erfährt.

Durch die Bereitstellung der einerseits in verschiedenen Applikationen wiederverwendbaren, andererseits aber auch an die jeweilige Applikation und das zugehörige Gerät anpassbaren Spikes wird desweiteren auch die Erstellung von Softwareapplikationen vereinfacht. Vorzugsweise ist mindestens eine der auf dem System aufbauen ^¬ den Softwareapplikationen horizontal in mehrere Schichten, nämlich zumindest eine Präsentationsschicht und eine Ge ^¬ schäftslogikschicht gegliedert. In Abgrenzung von der Präsen ^¬ tationsschicht, die die graphische Benutzeroberfläche der Ap- plikation definiert und ggf. in Abgrenzung von einer Datenhaltungsschicht, zum Beispiel einer Datenbank, beinhaltet die Geschäftslogikschicht hierbei die Geschäftslogik (GL) der Ap ^¬ plikation, d.h. die Logik, die die eigentliche Aufgabenstel ^¬ lung der Applikation und weniger die technische Implementie- rung betrifft.

In Anpassung an diese Schichtenarchitektur umfasst auch mindestens einer der Spikes zusätzlich zu der Präsentations ^¬ schicht eine Geschäftslogikschicht. Ein Spike erstreckt sich somit in der Regel über mehrere Schichten der Applikation und stellt somit in deren Architekturschema im Gegensatz zu den horizontalen Schichten eine vertikale Struktur dar.

Auch in der Ebene der Geschäftslogik ist jeder Spike - sofern er Geschäftslogik umfasst - in den spezifischen Teil und den generischen Teil gegliedert. Der spezifische Teil umfasst hierbei in der Geschäftslogikschicht mindestens eine Ge ^¬ schäftslogik-Komponente, die eine Anzahl von GL-Zustands- variablen umfasst. Entsprechend ihrer Zugehörigkeit zu dem spezifischen Teil des Spikes kann die oder jede Geschäftslo ^¬ gik-Komponente in jeder Instanz des Spikes eine unterschied ^¬ liche technische Implementierung aufweisen. Beispielsweise kann die oder jede Geschäftlogik-Komponente eines Spikes für unterschiedliche Instanzen des Spikes in verschiedenen Pro- grammiersprachen implementiert sein. Auch müssen nicht alle Geschäftslogik-Komponenten eines Spikes in jeder seiner Instanzen vorhanden sein. Vielmehr können eine oder mehrere Geschäftlogik-Komponenten des Spikes in einer Instanz des Spikes auch weggelassen sein - beispielsweise dann, wenn die hierdurch implementierten Funktionen für die Applikation oder das Gerät, für das diese Instanz bestimmt ist, irrelevant sind .

Der generische Teil des Spikes ist in Bezug auf die Ge ^¬ schäftslogikschicht dazu eingerichtet, die Werte der GL- Zustandsvariablen in eine geräte- und applikationsunabhängige Form zu transformieren und in dieser Form als Teil des Zu- Standsdatensatzes zu exportieren. Der generische Teil des Spikes ist weiterhin dazu eingerichtet, bei dem Import des Zustandsdatensatzes die darin enthaltenen Werte der GL-Zu- standsvariablen (ggf. nach Rücktransformation in die jeweils passende geräte- und applikationsspezifische Form) der oder jeder Geschäftslogik-Komponente zuzuweisen. Somit kann durch den oder jeden Spike auch der interne Zustand der gegebenenfalls vorhandenen Geschäftslogik von einer Instanz auf eine andere Instanz des Spikes übertragen werden. In bevorzugter Ausführung werden durch den oder jeden Spike nicht nur die Zustände (States) , also die Werte der UI-Zu- standsvariablen sowie ggf. der GL-Zustandsvariablen exportiert und importiert. Vielmehr wird im Zusammenhang mit dem Zustandsdatensatz auch Zugriffsinformation exportiert bzw. importiert, die die von dem Spike (genauer gesagt der expor ^¬ tierenden Instanz des Spikes) zum ExportZeitpunkt verwendeten Nutzdaten identifiziert. Als Nutzdaten werden hierbei dieje ^¬ nigen Daten bezeichnet, die von dem jeweiligen Spike und sei ^¬ ner technischen Implementierung grundsätzlich unabhängig sind, und die von dem Spike lediglich verwendet oder bearbei ^¬ tet werden. Bei Applikationen für den Einsatz im medizinischen Bereich handelt es sich bei den Nutzdaten hierbei insbesondere um die medizinischen Daten, also beispielsweise um Bilddaten, Patientendaten, Aufgabenlisten, medizinische Be- richte etc.

Grundsätzlich ist - insbesondere bei kleinen Datensätzen - im Rahmen der Erfindung denkbar, dass die exportierte bzw. im- „

y

portierte Zugriffsinformation die betreffenden Nutzdaten selbst enthält, dass also die Nutzdaten als Wert (by Value) exportiert und importiert werden. Vorzugsweise enthält die Zugriffsinformation allerdings einen Verweis auf den Spei- cherort der Nutzdaten in einem applikationsexternen Datenspeicher, anhand dessen der Spike (genauer gesagt die importierende Instanz des Spikes) die Nutzdaten nach dem Import des Zustandsdatensatzes - vorzugsweise automatisch - lädt. Somit stehen dem Benutzer nach einem Geräte- oder Applikationswechsel nicht nur der interne Zustand des jeweiligen Spikes, sondern auch die von diesem zuvor verwendeten oder bearbeitenden Nutzdaten unmittelbar zur Verfügung, ohne dass der Benutzer diese Daten durch bewusste Interaktion erneut suchen und laden muss.

Grundsätzlich ist im Rahmen der Erfindung denkbar, dass der Zustandsdatensatz unmittelbar von einer Instanz an eine andere Instanz desselben Spikes übertragen wird. Im Sinne einer einfacheren und flexibleren Handhabung der auf dem Spike- Konzept aufbauenden Applikationen umfasst das System aber abweichend hiervon einen zentralen Zustandsspeicher, in dem die exportierten Zustandsdatensätze persistent vorgehalten wer ^¬ den. Der generische Teil eines jeden Spikes ist hierbei dazu eingerichtet, den Zustandsdatensatz in diesen Zustandsspei ^¬ cher zu exportieren. Weiterhin ist der generische Teil eines jeden Spikes auch dazu eingerichtet, zum Import von Zustands- datensätzen auf diesen Zustandsspeicher zuzugreifen. Grundsätzlich kann es sich bei diesem Zustandsspeicher um einen beliebigen Datenspeicher handeln, der systemweit zugänglich ist. Insbesondere kann der Zustandsspeicher in einer servergestützten Datenbank implementiert sein. Aufgrund der weltweiten Verfügbarkeit, der nahezu beliebigen Skalierbar- keit und der hohen Datensicherheit ist der Zustandsspeicher aber vorzugsweise in einem Cloud-Storage, insbesondere dem Cloud-Storage einer sogenannten Public-Cloud (zum Beispiel dem Dienst „Windows Azure" der Firma Microsoft) implemen ^¬ tiert .

In einer besonders bevorzugten Ausgestaltungsvariante des Systems dient der generische Teil eines jeden Spikes nicht lediglich zur Sammlung und Übertragung von Zuständen und Nutzdaten. Vielmehr bildet er zusätzlich ein von geräte- und applikationsspezifischen Details abstrahiertes Modell zumindest der Präsentationsschicht des jeweiligen Spikes ab. In diesem Sinne definiert der generische Teil eines jeden Spikes in der Präsentationsschicht die UI-Zustandsvariablen sowie statische Eigenschaften der UI-Elemente in Form von abstra ^¬ hierten, geräte- und applikationsunabhängigen (UI-) Vorgabe ^¬ elementen .

Der spezifische Teil des jeweiligen Spikes bestimmt hierbei in Übereinstimmung mit den Vorgabeelementen die geräte- und/oder applikationsabhängig konkretisierten UI-Elemente. Jedes der in dem generischen Teil definierten Vorgabeelemente bildet somit ein abstrahiertes Muster oder Template, das von dem spezifischen Teil des jeweiligen Spikes mit einem passenden konkreten UI-Element ausgefüllt wird. „Passend" bedeutet in diesem Sinne, dass die UI-Zustandsvariablen des konkreten UI-Elements mit den verallgemeinerten UI-Zustandsvariablen des jeweiligen Vorgabeelements konform sein müssen, so dass der Zustand des Vorgabeelements auf den Zustand des konkreten UI-Elements „gemappt" werden kann und umgekehrt. Dabei muss jedem konkreten UI-Element ein Vorgabeelement, und jeder UI- Zustandsvariable eines jeden konkreten UI-Elements generische eine UI-Zustandsvariable des jeweiligen Vorgabeelements zuge ^¬ ordnet sein, nicht aber notwendigerweise umgekehrt. Der gene ^¬ rische Teil eines Spikes kann also grundsätzlich Vorgabeele ^¬ mente und UI-Zustandsvariablen umfassen, zu denen sich in dem spezifischen Teil desselben Spikes (insbesondere einer be- stimmten Instanz desselben Spikes) keine konkretisierte Ent ^¬ sprechung findet. Insbesondere können einzelne Instanzen ei ^¬ nes Spikes das abstrahierte UI-Modell des generischen Teils in vereinfachter Form mit einer Untermenge von konkreten UI- Elementen und/oder weniger UI-Zustandsvariablen konkretisieren .

Zum Export und Import des internen Zustands der UI-Elemente sind hierbei in jeder Instanz eines jeden Spikes die Werte der UI-Zustandsvariablen zwischen den konkreten UI-Elementen und den zugehörigen UI-Vorgabeelementen unter entsprechender Transformation reversibel übertragbar. Sofern ein Spike zusätzlich zu der Präsentationslogik auch Geschäftslogik umfasst, enthält der generische Teil dieses Spikes vorzugsweise auch für jede Geschäftslogikkomponente ein entsprechendes GL-Vorgabeelement , das die GL-Zustands- variablen der jeweiligen Geschäfslogikkomponente in abstra- hierter, nämlich geräte- und applikationsunabhängiger Form spiegelt .

Die abstrahierte Modellierung der Präsentationsschicht und ggf. der Geschäftslogikschicht eines jeden Spike durch dessen generischen Teil stellt einerseits ein effizientes und flexi ^¬ bel einsetzbares Instrument dar, um den internen Zustand ei ^¬ ner Instanz eines Spikes über Geräte- und Applikationsgrenzen hinweg auf eine andere Instanz zu übertragen. Des Weiteren ermöglicht dieses Konzept eine wesentliche Vereinfachung bei der Erstellung der Softwareapplikationen, zumal anhand der einmal festgelegten Vorgabeelemente alle Instanzen des Spikes - zumindest auf der Ebene der Präsentationsschicht - voll ^¬ ständig oder zumindest nahezu vollständig automatisch erzeugt werden können.

Um eine einfache Zustandsübertragung zu ermöglichen, tragen alle Instanzen eines Spikes innerhalb des Systems vorzugswei ^¬ se einen gemeinsamen Namen, durch den diese Instanzen eindeutig als zusammengehörig identifizierbar sind.

Der von einer Instanz eines Spikes exportierte Zustandsdaten- satz wird in dem Zustandsspeicher vorzugsweise zusammen mit dem Namen des zugehörigen Spikes sowie ferner mit mindestens einer weiteren Angabe zur Kennzeichnung eines bestimmten Arbeitsschrittes oder Projekts gespeichert. Die oder jede wei ^¬ tere Angabe ist insbesondere · der Name oder eine sonstige Identifizierung für einen

Benutzer,

• eine eindeutige Bezeichnung für die exportierende In ^¬ stanz oder ersatzweise Angaben zu dem Gerät und der Applikation, zu der diese Instanz gehört,

· eine oder mehrere Angaben zu dem medizinischen Arbeitsablauf, bei dessen Bearbeitung der Zustandsdatensatz erzeugt wurde, besondere dem Namen oder der Identifikati ^¬ onsnummer eines Patienten, die Bezeichnung des

Workflows, die Bezeichnung der bearbeiteten medizini- sehen Studie gemäß DICOM, etc.

Der Begriff „Zustandsdatensatz" ist dabei allgemein im Sinne einer Ansammlung von Daten zu verstehen, die den inneren Zustand einer Instanz eines Spikes (also die Werte der UI-Zu- standsvariablen, ggf. der GL-Zustandsvariablen sowie ggf. die verwendeten Nutzdaten) charakterisieren. Der Zustandsdaten- satz kann im Sinne der Erfindung allerdings hinsichtlich seines Formats beliebig gestaltet sein und insbesondere auch in mehrere, unabhängig exportierbare und importierbare Teilda- tensätze gegliedert sein.

Die zusammen mit dem Zustandsdatensatz in dem Zustandsspei- cher hinterlegten Angaben ermöglichen es dem Benutzer, nach einem Geräte- und/oder Applikationswechel gezielt denjenigen Zustandsdatensatz zu einem vor dem Wechsel begonnenen Ar- beitsblauf aufzufinden und zur nahtlosen Fortsetzung des Arbeitsablaufes zu importieren.

Vorzugsweise ist jeder Spike dazu eingerichtet, den internen Zustand einer jeden Instanz in vorgegebenen Intervallen automatisch - ohne Zutun des Benutzers - zur Erzeugung eines Wie ^¬ derherstellungspunktes in den Zustandsspeicher zu exportie ^¬ ren. Dies ermöglicht einerseits die konsistente Herstellung des internen Zustands einer Applikation im Falle eines

Fehlers. Andererseits ermöglicht die fortlaufend wiederholte Zustandssicherung auch eine parallele Bearbeitung ein- und desselben Arbeitsablaufs an unterschiedlichen Geräten

und/oder unterschiedlichen Applikationen.

Nachfolgend wird ein Ausführungsbeispiel der Erfindung anhand einer Zeichnung näher erläutert. Darin zeigen: FIG 1 in einem schematischen Blockschaltbild ein System, in dem mehrere Softwareapplikationen, die zur Verarbeitung medizinischer Daten eingerichtet sind, auf einer Mehrzahl von Geräten betrieben werden, in schematischer Darstellung den softwaretechnischen Aufbau des Systems mit beispielhaft vier Ap ^¬ plikationen, die auf insgesamt drei Geräten betrie ^¬ ben werden, wobei jede der Softwareapplikationen jeweils aus einer Rahmenkomponente sowie Instanzen einer Anzahl von Funktionseinheiten (Spikes) gebildet sind, und wobei Instanzen desselben Spikes dazu eingerichtet sind, ihren internen Zustand über ei ^¬ nen Zustandsspeicher auszutauschen, in Darstellung gemäß FIG 2 eine Applikation des Systems mit einem in größerem Detail dargestellten Spike, in einem Komponenten-Diagramm die Wechselwirkung zwischen verschiedenen Komponenten des Spikes, und in einem Sequenzdiagramm die Interaktion zwischen der Rahmenkomponente einer Applikation, dem Zustandsspeicher und verschiedenen Komponenten eines Spikes beim Import des zuvor von einer Instanz desselben Spikes exportierten internen Zustands. Einander entsprechende Teile und Größen sind in allen Figuren stets mit gleichen Bezugszeichen versehen.

FIG 1 zeigt in grober schematischer Vereinfachung ein System 1 zum Betrieb von ( Software- ) Applikationen 2, die der Erzeu ^¬ gung und Verarbeitung von medizinischen Daten dienen, auf mehreren Geräten. Die Geräte des Systems 1, auf denen die Ap ^¬ plikationen 2 bestimmungsgemäß betrieben werden, umfassen einerseits bildgebende, medizinische Modalitäten 3 zur Erzeu- gung von medizinischen Bilddaten sowie andererseits Benutzergeräte 4 zur Anzeige und Verarbeitung der Bilddaten sowie sonstiger medizinischer Daten.

Als Modalitäten 3 des Systems 1 sind in FIG 1 beispielhaft ein Computertomograph 5, ein C-Bogen-Gerät 6 sowie ein

Magnetresonanztomograph 7 dargestellt. Jeder dieser Modalitäten 3 ist hierbei ein Steuerrechner 8 zugeordnet, auf dem als Applikation 2 zumindest eine Steuersoftware zur Steuerung ei ^¬ ner mittels der jeweiligen Modalität 3 vorgenommenen Untersu- chung implementiert ist. Die der jeweiligen Modalität 3 zu ^¬ geordnete Steuersoftware umfasst darüber hinaus in der Regel Funktionen zur Aufbereitung und Anzeige der aufgenommenen Bilddaten . Die Benutzergeräte 4 des Systems 1 umfassen beispielsweise Workstations oder Personal-Computer 9 (kurz: PCs 9) mit jeweils angeschlossenem Bildschirm 10, aber auch moderne Mobilgeräte wie beispielsweise Tablet-Computer 11 sowie Smart- phones 12. Die hierzu auf den Benutzergeräten 4 implementier- ten Applikationen 2 umfassen beispielsweise Software zur Befundung der medizinischen Bilddaten, wobei diese Software in verschiedenen Varianten für jeweils unterschiedliche medizinische Spezialgebiete (z.B. Onkologie, Kardiologie, etc.) vorliegen kann, Software zur Erstellung von medizinischen Be- richten, Software zur Verwaltung von Patientendaten, etc..

Das System 1 umfasst desweiteren einen oder mehrere Datenspeicher 13 zur Speicherung der medizinischen Nutzdaten N (z.B. Bilddaten, Patientendaten, Worklists, etc.) sowie einen oder mehrere Server 14, die datenbankgestützte Datenverwal ^¬ tungssysteme (HIS, RIS, PACS, etc.) und andere Dienste zur Verfügung stellen.

Schließlich umfasst das System 1 einen Zustandsspeicher 15 zur persistenten Speicherung von Zustandsdatensätzen Z, die in nachfolgend näher beschriebener Weise den internen Zustand von Funktionseinheiten der Applikationen 2 beschreiben.

Der Zustandsspeicher 15 ist hierbei in dem dargestellten Beispiel des Systems 1 in einem Cloud-Storage, insbesondere ei ^¬ nem sogenannten Table-Storage 16 einer Public-Cloud 17, ein ^¬ gerichtet. Auch der Datenspeicher 13 und der oder jeder Ser- ver 14 ist bevorzugt in der Public Cloud 17 eingerichtet. Als Public Cloud 17 wird hierbei vorzugsweise der „Windows

Azure"-Dienst der Firma Microsoft genutzt. Allerdings können auch Public-Cloud-Dienste anderer Cloud-Betreiber im Rahmen der Erfindung herangezogen werden. Alternativ zu der cloud- basierten Implementierung können der Datenspeicher 13, der oder jeder Server 14 und der Zustandsspeicher 15 allerdings auch im Rahmen einer gewöhnlichen Client-Server-Lösung realisiert sein. Die Komponenten des Systems 1, also die Modalitäten 3, die

Benutzergeräte 4 und die Public Cloud 17 (mit dem Datenspei ^¬ cher 13, dem oder jedem Server 14 Und dem Zustandsspeicher 15) sind über ein (Datenübertragungs-) etz 18 datenübertragungstechnisch verbunden. Soweit das System 1 einer medizini- sehen Einrichtung, zum Beispiel einer Klinik, zugeordnet ist, ist das Netz 18 vorzugsweise durch ein drahtgebundenes und/oder drahtloses Intranet gebildet, das beispielweise als sogenanntes Local Area Network (LAN) auf Basis kabelgebunde ^¬ ner Ethernet-Technologie und/oder als kabelloses Wireless Lo- cal Area Network (WLAN) aufgebaut ist. Außerhalb abgegrenzter medizinischer Einrichtungen ist das Netz 18 durch das Internet gebildet. Insbesondere ist die Public-Cloud 17 über das Internet mit den übrigen Komponenten des Systems 1 verbunden. FIG 2 zeigt den softwaretechnischen Aufbau des Systems 1 in einer schematisch vereinfachten Übersichtsdarstellung. Gezeigt sind vier Applikationen 2, die im Einzelnen als Appli- kationen 2a-2d bezeichnet sind. Die Applikationen 2a-2d lau ^¬ fen beispielhaft auf insgesamt drei Benutzergeräten 4. So läuft die Applikation 2a auf dem PC 9 ab, während die Appli ^¬ kation 2b auf dem Tablet-Computer 11, und die Applikationen 2c und 2d auf dem Smartphone 12 ablaufen.

Jede der Applikationen 2 umfasst eine Rahmenkomponente 20. Diese Rahmenkomponente 20 ist dazu eingerichtet, weitere Kom ^¬ ponenten, die den eigentlichen Funktionsumfang und die technische Implementierung der Applikation 2 bestimmen, zu laden. Wie aus FIG 2 ersichtlich ist, sind diese weiteren Komponenten architektonisch in zwei Schichten angeordnet, nämlich einer ( Präsentations- ) Schicht 21 sowie einer (Geschäftslogik- ) Schicht 22. Zum Lesen und Schreiben der medizinischen Nutzdaten N greifen alle Applikationen 2 auf eine Datenhaltungsschicht 23 zu, die auf dem oder jeden Server 14 und somit außerhalb der Applika ^¬ tion 2 implementiert ist. Jede der Schichten 21 und 22 fußt hierbei auf einer Laufzeit ^¬ umgebung 24 sowie auf einer Programmbibliothek 25, wobei diese Komponenten der jeweiligen Applikation 2 beispielsweise aus einem Framework, d.h. einer dem Betriebssystem des jeweiligen Benutzergeräts 4 und der Applikation 2 zwischengeordne- ten Middleware, zur Verfügung gestellt werden.

Desweiteren umfasst jede der Applikationen 2 sowohl in der Präsentationsschicht 21 als auch in der Geschäftslogikschicht 22 jeweils zwei weitere Komponenten, die als Datenmodell 26 bzw. Zustandsmodell 27 bezeichnet sind, und die auf Applika ^¬ tionsebene Nutzdaten und Zustände (insbesondere Laufzeitzu ^¬ stände) definieren. _{1 η}

Die Laufzeitumgebung 24, die Programmbibliothek 25, das Datenmodell 26 und das Zustandsmodell 27 bilden somit in jeder Schicht 21,22 einer jeden Applikation 2 einen Sockel, der von seiner Struktur her für alle Schichten 21,22 und alle Appli- kationen 2 gleich ist (auch wenn die konkrete technische Implementierung der Laufzeitumgebung 24 und der Programmbibliothek 25 verschieden sein kann und in der Regel auch verschieden ist) .

Die auf diesem Sockel aufbauenden Komponenten sind nun in eine bestimmte Anzahl von Funktionseinheiten gegliedert, die nachfolgend als Spikes 28 bezeichnet sind. Jeder Spike 28 ist hierbei derart gestaltet, dass er hinsichtlich seines Funkti ^¬ onsumfangs kohärent und konsistent ist, dass er also einer ^¬ seits keine zwingende funktionale Abhängigkeit zu anderen Spikes 28 aufweist und somit - technisch gesehen - auch ein ^¬ zeln funktionsfähig ist, und dass er andererseits einen zur Erfüllung der ihm zugedachten Aufgabe sinnvollen und hinreichenden Funktionsumfang hat. Zu dem Funktionsumfang der

Spikes 28, also hinsichtlich der einem jeden Spike 28 zuge ^¬ dachten Aufgabe, wird auf die vorstehend aufgeführten Bei ^¬ spiele verwiesen.

Jedem Spike 28 ist weiterhin zwingend ein zugeordneter Be- reich einer Benutzeroberfläche (UI) der Applikation 2 zuge ^¬ ordnet. Bei einer üblichen graphischen Verkörperung der Benutzeroberfläche tritt der Spike 28 somit nach außen hin zum Beispiel in Form eines Fensters oder Rahmens oder eines Menüs in Erscheinung.

Zumal jeder Spike 28 einen Teil der Benutzeroberfläche be ^¬ reitstellt, ist er in jedem Fall in der Präsentationsschicht 21 der zugehörigen Applikation 2 angesiedelt. Im Gegensatz zu den Schichten 21 und 22 handelt es sich bei den Spikes 28 aber um vertikale Strukturen in der Architektur der jeweiligen Applikation 2. Sofern daher dem von einem Spike 28 abgedeckten Aufgabengebiet Geschäftslogik zuzurechnen ist, um- fasst dieser Spike 28 zusätzlich zu dem in der Präsentations- schicht 21 angesiedelten Teil auch einen in der Geschäftslogikschicht 22 angesiedelten Teil. Die einander zugehörigen Teile eines Spikes 28 sind entsprechend auch in der Darstel ^¬ lung gemäß FIG 2 übereinander dargestellt.

Somit umfasst die Applikation 2a fünf Spikes 28a-28e, von de ^¬ nen sich die Spikes 28a,28b,28d und 28e sowohl über die Prä ^¬ sentationsschicht 21 als auch die Geschäftslogikschicht 22 erstrecken. Abweichend hiervon hat der Spike 28c keine Ge- schäftslogik und besteht somit ausschließlich in der Präsentationsschicht 21.

Schließlich ist jeder Spike 28 mehrfach instanziierbar . Verschiedene Instanzen, d.h. Ausprägungen ein und desselben Spi- ke 28, können dabei in unterschiedlichen Applikationen 2 und/oder auf unterschiedlichen Modalitäten 3 oder Benutzergeräten 4 betrieben werden. Desweiteren können auch mehrere Instanzen ein- und desselben Spikes 28 in derselben Applikation 2 vorhanden sein.

In diesem Sinne umfassen in der beispielhaften Darstellung gemäß FIG 2 die Applikation 2b zwei weitere Instanzen des Spikes 28e,

die Applikation 2c jeweils eine weitere Instanz der Spikes 28b, 28c und 28d, und

die Applikation 2d eine weitere Instanz des Spikes 28a Die Spikes 28a-28d der auf dem PC 9 laufenden Applikation 2a sind somit für den Betrieb auf dem Smart-Phone 12 auf die zwei „schlankeren" Applikationen 2c und 2d aufgeteilt, wobei der Spike 28a isoliert in der dedizierten Applikation 2d betrieben wird.

Wie in FIG 2 lediglich grob schematisch angedeutet ist, wirken alle Instanzen ein und desselben Spikes 28 insofern zusammen, als sie ihren internen Zustand in Form des Zustands- datensatzes Z von einer Instanz auf eine andere übertragen können. Hierzu überträgt eine Instanz eines Spikes 28 (im Beispiel gemäß FIG 2 die innerhalb der Applikation 2a laufen ^¬ de Instanz des Spikes 28a) den Zustandsdatensätz Z in den Zu- Standsspeicher 15, aus dem der Zustandsdatensätz Z zu einem späteren Zeitpunkt von einer anderen Instanz (beispielsweise der innerhalb der Applikation 2d laufenden Instanz des Spikes 28a) zum Import des internen Zustands geladen werden kann. In bevorzugter Ausführung exportiert jede Instanz eines jeden Spikes 28 ihren internen Zustand - jeweils in Form eines ent ^¬ sprechenden Zustandsdatensätzes Z - nicht nur beim Schließen der zugehörigen Applikation 2 oder auf entsprechenden Benutzerbefehl, sondern auch ohne Zutun des Benutzers in regelmä- ßigen Zeitabständen (von beispielsweise 5 Minuten) in den Zu- standsspeicher 15. Auf diese Weise können die im Zustands- speicher 15 gesammelten Zustandsdatensätze Z auch zur Wiederherstellung des Zustandes einer Applikation 2 nach einem Fehler herangezogen werden.

In dem Zustandsspeicher 15 wird jeder Zustandsdatensätz Z zusammen mit dem innerhalb des Systems 1 einheitlichen und eindeuti ^¬ gen) Namen des Spikes 28,

dem Namen oder einer sonstigen Identifizierung des zum ExportZeitpunkt mit dem Spike 28 arbeitenden Benutzers, einer Angabe zu der exportierenden Instanz des Spikes 28 (oder ersatzweise einer Angabe zu der Applikation 2 und der Modalität 3 bzw. dem Benutzergerät 4, die dieser In ^¬ stanz zugeordnet sind) ,

einer Angabe zu dem mittels des Spikes 28 zum Export ^¬ zeitpunkt bearbeiteten Arbeitsablaufs (zum Beispiel durch Angabe des Patientennamens und/oder einer Nummer für die untersuchte Studie) , sowie abgespeiche Anhand dieser Angaben kann der Zustandsdatensatz Z zu einem späteren Zeitpunkt - gegebenenfalls an einer anderen Modali ^¬ tät 3 oder einem anderen Benutzergerät 4 und/oder aus einer anderen Applikation 2 - im Zustandsspeicher 15 recherchiert und importiert werden.

In FIG 3 ist der Aufbau eines Spikes 28 näher dargestellt. Danach umfasst jeder Spike 28 einen spezifischen Teil 30 sowie einen generischen Teil 31.

Der spezifische Teil 30 ist hierbei für jede Instanz des Spikes 28 spezifisch vorgebbar, so dass sich die verschiede ^¬ nen Instanzen eines Spikes 28 in diesem spezifischen Teil 30 regelmäßig unterscheiden. Der spezifische Teil 30 umfasst hierbei in der Präsentationsschicht 21 folgende Komponenten:

• Eine UI-Element-Komponente 32, die für die Benutzerober ^¬ fläche der Applikation 2 ein bestimmtes Set an konkreten UI-Elementen definiert. Die UI-Elemente umfassen hierbei in der Regel passive graphische Elemente (z.B. Rahmen,

Farbflächen, Linien, etc.), einfache Steuerelemente (z.B. Schaltflächen, virtuelle Schiebe- oder Drehregler, Check-Boxes etc.), komplexe, insbesondere erweiterbare Steuerelemente (z.B. Auswahlmenüs in verschiedener gra- phischer Ausprägung) , Texteingabefelder, sowie Ausgabefelder für Text und/oder Graphik. Ein UI-Element kann dabei auch bereits aus einer Kombination mehrerer einzelner UI-Elemente bestehen. Die UI-Element-Komponente 32 definiert dabei insbesondere statische Eigenschaften und UI-Zustandsvariablen für jedes der UI-Elemente.

• Eine UI-Layout-Komponente 33, die die Anordnung, insbe ^¬ sondere also die geometrische Verteilung der UI-Elemente auf der Benutzeroberfläche der Applikation 2 festlegt.

• Eine UI-FunctionHandler-Komponente 34, die die techni- sehe Funktion der UI-Elemente (also die UI-Logik) imple ^¬ mentiert . Sofern sich der Spike 28 in die Geschäftslogikschicht 22 hin ^¬ ein erstreckt, umfasst sein spezifischer Teil 30 hier mindes ^¬ tens eine Geschäftslogikkomponente 35, die die gegebenenfalls vorhandene Geschäftslogik des Spikes 28 implementiert.

In dem generischen Teil 30 umfasst der Spike 28 folgende Kom ^¬ ponenten (die in Abgrenzung von den Komponenten des spezifischen Teils 30 auch als „Spikelets" bezeichnet sind:

• In der Präsentationsschicht 21 sowie gegebenenfalls auch in der Geschäftslogikschicht 22 jeweils ein Meta- Spikelet 36, das allgemeine Informationen zu dem betref ^¬ fenden Spike 28 enthält, insbesondere den Namen des Spikes, eine Liste der in dem Spike enthaltenen Kompo ^¬ nenten, eine Liste der Schichten 21,22, über die sich der Spike 28 erstreckt und Information über den Funkti ^¬ onsumfang des Spikes 28, also die dem Spike zugedachte Aufgabe, zum Beispiel in Form eines oder mehrerer medi ^¬ zinischer Codes (insbesondere gemäß DICOM, SNOMED, ICD- 10 und/oder LOINC) . Die Codes können hierbei z.B. das oder jedes anatomische Anwendungsgebiet des Spike und/oder die oder jede Diagnose- oder Therapiemethode, für die der Spike anwendbar ist, spezifizieren. Das Me- ta-Spikelet 36 verhält sich hierbei wie ein gewöhnliches UI-Element, so dass es von der Rahmenkomponente 20 der Applikation 2 wie ein solches UI-Element geladen werden kann. In dem Meta-Spikelet 36 ist zudem die Funktion zum Zugriff auf den Zustandsspeicher 15 implementiert. Das Meta-Spikelet 36 kann somit zur Laufzeit der Applikation 2 Zustandsdatensätze Z in den Zustandsspeicher 15 schreiben und aus dem Zustandsspeicher 15 lesen.

• In der Präsentationsschicht 21 sowie gegebenenfalls in der Geschäftslogikschicht 22 jeweils mindestens ein Da- ten-Spikelet 37, das einen Adapter zwischen dem internen Datenmodell des jeweiligen Spike 28 und dem Datenmodell 25 der jeweils umgebenden Applikation 2 darstellt und den Spike 28 somit an die gegebenenfalls differierenden Datenmodelle 25 verschiedener Applikationen 2 anpassbar macht .

In der Präsentationsschicht 21 sowie gegebenenfalls in der Geschäftslogikschicht 22 jeweils mindestens ein Zu ^¬ stands-Spikelet 38, das die UI-Zustandsvariablen bzw. GL-Zustandsvariable in einer abstrahierten, geräte- und applikationsunabhängigen Form spiegelt. · In der Präsentationsschicht 21 mindestens ein Handler-

Spikelet 39, das applikationsspezifische und gerätespe ^¬ zifische Ereignisse verarbeitet.

Das Zustands-Spikelet 38 der Präsentationsschicht 21 defi- niert vorzugsweise zu jedem konkreten UI-Element und Layout ein abstrahiertes Ul-Vorgabeelement mit entsprechenden Zu- standsvariablen, die allerdings - im Gegensatz zu den UI- Zustandsvariablen der konkreten UI-Elemente - zwangsweise für jede Instanz des Spikes 28 gleich sind.

Beispiele für solche UI-Vorgabeelemente sind:

• Ein Vorgabeelement des Typs „Button", das eine generi- sche Schaltfläche beschreibt. Dieses Vorgabeelement hat beispielsweise die generischen UI-Zustandsvariablen

„Button_Value" , die den Schaltzustand der Schaltfläche (z.B. „Betätigt" = 1; Unbetätigt" = 0) beschreibt, sowie „Button_Dimmed_State" , der den Aktivierungszustand der Schaltfläche beschreibt (z.B. „Aktiv/Betätigbar" = 1 ; „Inaktiv/Nicht-Betätigbar" = 0). Dieses Vorgabeelement kann hierbei in verschiedenen Instanzen des Spikes 28 in der UI-Element-Komponente 32 durch Schaltflächen verschiedener graphischer Darstellung und/oder technischer Implementierung konkretisiert werden, z.B. in einer In- stanz durch eine Schaltfläche mit Text-Beschriftung und in einer anderen Instanz durch eine Schaltfläche mit ikonographischer Markierung. Ein Vorgabeelement des Typs „Slide", das einen generi- schen Einstellregler beschreibt. Dieses Vorgabeelement hat beispielsweise die generischen UI-Zustandsvariablen „Slide_Value" , die den Stellwert des Einstellreglers (z.B. in Form einer Gleitkommazahl mit Minimalwert 0 und Maximalwert 100) beschreibt, sowie „Slide_Dimmed_State" , die den Aktivierungszustand des Einstellreglers be ^¬ schreibt (z.B. „Aktiv/Betätigbar" = 1; „Inaktiv/Nicht- Betätigbar" = 0) . Dieses Vorgabeelement kann hierbei in verschiedenen Instanzen des Spikes 28 in der UI-Element- Komponente 32 durch Einstellregler verschiedener graphischer Darstellung und/oder technischer Implementierung konkretisiert werden, z.B. durch vertikale Schiebereg ^¬ ler, horizontale Schieberegler, Drehregler, etc.

Ein Vorgabeelement des Typs „SelectOneOfN" , das eine ge- nerische Einfach-Auswahl (also ein Mittel, das einem Nutzer die Auswahl genau einer Option aus mehreren zur Auswahl gestellten Optionen ermöglicht) , und das in einer Instanz des Spikes 28 z.B. durch ein Drop-Down-Menu, eine Reihe von sog. Radio-Buttons, etc. konkretisiert werden kann.

Ein Vorgabeelement des Typs „SelectMOfN" , das eine gene- rische Mehrfach-Auswahl (also ein Mittel, das einem Nut ^¬ zer die Auswahl beliebig vieler Optionen aus mehreren zur Auswahl gestellten Optionen ermöglicht) , und das in einer Instanz des Spikes 28 z.B. wiederum durch ein Drop-Down-Menu, eine Reihe von sog. Check-Boxes, etc. konkretisiert werden kann.

Ein Vorgabefeld des Typs „Textlnput", das ein generi- sches Eingabefeld für alphanumerische Zeichen charakte risiert . Etc. Zumindest zu einigen der Vorgabeelemente können optional ne ^¬ ben den dynamischen UI-Zustandsvariablen auch statische Eigenschaften, z.B. Farben, Beschriftungen, vorgegeben werden. Zusätzlich werden durch das Zustands-Spikelet 38 der Präsentationsschicht 21 auch UI-Vorgabeelemente zu Strukturen des UI-Layouts definiert. Beispiele hierfür sind:

Ein Vorgabeelement „SquareWithUIElementTypes" , das ei nen generischen rechteckigen UI-Bereich beschreibt, der mit UI-Elementen bestückbar ist. Dieses Vorgabeelement weist beispielsweise die UI-Zustandsvariable „Focus_State" auf, die beschreibt, ob der UI-Bereich im Focus des GUI ist und somit unmittelbar mit dem Be nutzer interagieren kann. Als statische Eigenschaft enthält dieses Vorgabeelement beispielsweise eine Lis te von enthaltenen UI-Vorgabeelementen sowie Angaben zu deren Anordnung. Dieses Vorgabeelement kann hierbe in verschiedenen Instanzen des Spikes 28 in der UI- Layout-Komponente 33 durch ein (auf dem GUI selbst ^¬ ständig bewegliches) Fenster, einen (auf der Benutzer Oberfläche nicht selbstständig beweglichen) Rahmen, eine Farbfläche oder eine Registerkarte (Tab) konkre ^¬ tisiert werden.

Ein Vorgabeelement ,,DIP(N,M)", das ein generisches NxM-Feld von UI-Bereichen beschreibt, und das bei ^¬ spielsweise als matrix- oder tabellenartige Anordnung der UI-Bereiche konkretisiert werden kann, aber - bei zu kleiner Bildschirmfläche des einer Instanz zugeord neten Nutzergeräts - alternativ auch als Stack von Re gisterkarten oder alternativ zueinander angezeigten Vollbilddarstellungen . Beim Export des internen Zustand eines Spikes 28 werden die UI-Zustandsvariablen der konkreten UI-Elemente und UI- Layoutstrukturen durch das Zustands-Spikelet 38 auf die gene ^¬ rischen UI-Zustandsvariablen der UI-Vorgabeelemente „gemappt" . Die hierfür nötige Transformation der UI-Zustands- variablen kann in einer reinen Wertübergabe bestehen. Beispielsweise übernimmt die generische UI-Zustandsvariable „Button_Value" den Wert „1" oder „0" unverändert aus einer korrespondierenden UI-Zustandsvariablen einer konkreten

Schaltfläche, wobei der letzteren UI-Zustandsvariablen je nach der technischen Implementierung von Instanz zu Instanz ein anderer Name zugewiesen sein kann. Die Transformation der UI-Zustandsvariablen kann allerdings auch mit einer Wertan- passung verbunden sein. Beispielsweise wird der Wert der ge ^¬ nerischen UI-Zustandsvariable „Slide_Value" bei der Transfor ^¬ mation auf den Wertebereich [0;100] dieser Zustandsvariablen normiert. Sofern der zugeordnete konkrete Einstellregler bei ^¬ spielsweise zwischen den Werten 0 und 1 verstellbar ist, wird der Wert dieses konkreten Einstellreglers also im Zuge der Transformation mit einem Faktor 100 multipliziert.

In entsprechender Weise werden ggf. durch das Zustands- Spikelet 38 der Geschäftslogikschicht 22 auch die GL-Zu- standsvariablen der oder jeder Geschäftslogikkomponente 35 auf korrespondierende generische GL-Zustandsvariablen von korrespondierenden GL-Vorgabeelemente gemappt .

Die übernommenen Werte der generischen UI-Zustandsvariablen werden anschließend als Teil des Zustandsdatensatzes von dem MetaSpikelet 36 an den Zustandsspeicher 15 übermittelt.

Beim Import des internen Zustands eines Spikes 28 werden um ^¬ gekehrt die generischen UI-Zustandsvariablen der UI- Vorgabeelemente durch das Zustands-Spikelet 38 auf die UI- Zustandsvariablen der konkreten UI-Elemente und UI-Layout- Strukturen rücktransformiert. Entsprechend werden ggf. die generischen GL-Zustandsvariablen der GL-Vorgabeelemente durch das Zustands-Spikelet 38 auf die GL-Zustandsvariablen der oder jeder Geschäftslogikkomponente 35 rücktransformiert.

Die in den Zustands-Spikelets 38 definierten UI- bzw. GL- Vorgabeelemente werden allerdings nicht nur zur Zustandsüber- „ ,

26

tragung während der Laufzeit des jeweiligen Spikes 28 verwendet, sondern bereits bei der Erstellung der Applikationen 2. Insbesondere die UI-Vorgabeelemente werden hierbei dazu ver ^¬ wendet, um die Instanzen eines Spikes 28 zumindest weitgehend automatisch zu erzeugen. Hierzu werden - beispielsweise durch einen in der Public Cloud 17 implementierten Dienst - anhand vorgegebener Auswahlregeln in Abhängigkeit der Modalität 3 bzw. des Nutzergeräts 4, für das die zu erzeugende Instanz bestimmt ist, sowie in Übereinstimmung mit den in den Zu- stands-Spikelets 38 definierten Ul-Vorgabeelementen konkrete UI-Elemente aus einer Programmbibliothek ausgewählt.

In FIG 4 ist die Interaktion zwischen der Rahmenkomponente 20 einer der Applikationen 2 sowie verschiedenen Komponenten einer in dieser Applikation 2 aufgehängten Instanz eines Spikes 28 in einer Komponentendarstellung gezeigt. Aus der Darstellung ist ersichtlich, dass die Rahmenkomponente 20 - selbst oder durch Aufruf einer Laderoutine - durch Aufrufe 40 das Meta-Spikelet 36, das Handler-Spikelet 39, das Daten-Spikelet 37, das Zustands-Spikelet 38 sowie die UI-Element-Komponente 32 lädt. Das Meta-Spikelet 36 greift hierauf (in nicht näher dargestellter Weise) auf den Zustandsspeicher 15 zu und lädt einen Zustandsdatensatz Z. Das Meta-Spikelet 36 lädt weiterhin die in dem Zustandsdatensatz Z spezifizierten Nutzdaten N.

Das Handler-Spikelet 39, das Daten-Spikelet 37 und das Zu ^¬ stands-Spikelet 38 fragen von dem Meta-Spikelet 36 jeweils in Aufrufen 41 die für die jeweilige Komponente relevante Zu- Standsinformation sowie weitere Informationen ab. Insbesondere erhält das Daten-Spikelet 37 die von dem Meta-Spikelet 36 geladenen Nutzdaten N, insbesondere die DICOM-Patienten- identifikationsnummer sowie demografische Daten zu dem Patienten, Serien, Studien und Bilder gemäß dem DICOM Standard sowie Daten zu medizinischen Befunden. Das Zustands-Spikelet 38 erhält die Werte der generischen UI-Zustandsvariablen und transformiert diese zurück in die jeweilige geräte- und app ^¬ likationsabhängige Form. Die UI-Element-Komponente 32 greift diese rücktransformierten Werte in einem Aufruf 42 von dem Zustands-Spikelet 38 ab und parametriert die konkreten UI-Elemente (zum Beispiel Schalt- flächen, Bildanzeigesegmente, Menüs und Texteingabefelder) entsprechend. Die UI-Element-Komponente 32 greift weiterhin in Aufrufen 43 und 44 auf das Daten-Spikelet 37 sowie auf das Handler-Spikelet 39 zu, um Nutzdaten N zu laden bzw. um Hand ^¬ ler aufzurufen.

Im Einzelnen ist der zeitliche Ablauf beim Start einer Applikation 2 in FIG 5 dargestellt. Danach lädt die Rahmenkompo ^¬ nente 20 in einem ersten Ereignis 50 das Meta-Spikelet 36 wie ein gewöhnliches UI-Element. Das Meta-Spikelet 36 verbindet sich hierauf mit dem Zustandsspeicher 15, um einen Zustands- datensatz Z zu laden (Ereignis 51) . In einem Ereignis 52 wendet das Meta-Spikelet 36 zunächst die geladenen Zustandsdaten auf sich selbst an. In folgenden Ereignissen 53,54 und 55 überträgt das Meta-Spikelet 36 den jeweils relevanten Teil der geladenen Zustandsinformation auf das Handler-Spikelet 39, das Daten-Spikelet 37 und das Zustands-Spikelet 38. Das Handler-Spikelet 39 wendet die geladenen Zustandsdaten - in transformierter Form - wiederum auf die UI-FunctionHandler- Komponente 34 an (Ereignis 56) . Das Zustands-Spikelet 39 wen- det entsprechend die jeweils relevante Zustandsinformation (also die Werte der UI-Zustandsvariablen) in entsprechend transformierter Form auf die UI-Layout-Komponente 33 und die UI-Element-Komponente 32 an (Ereignisse 57 und 58) . In einem letzten Ereignis 59 wählt das Zustands-Spikelet 38 in der durch den Zustandsdatensatz Z spezifizierten Weise (und somit analog zu der Instanz des Spikes 28, die den Zustandsdaten- satz Z zuvor exportiert hatte) ein UI-Element aus.

Die Erfindung wird an dem vorstehend beschriebenen Ausfüh- rungsbeispiel besonders deutlich, ist gleichwohl auf dieses aber nicht beschränkt. Vielmehr können zahlreiche weitere Ausführungsformen der Erfindung aus den Ansprüchen und der Beschreibung abgeleitet werden. _n

Bezugs zeichenliste

1 System

2,2a -d ( Software- ) Applikation

3 Modalität

4 Device

5 Computertomograph

6 C-Bogen-Gerät

7 Magnetresonanztomograph

8 Steuerrechner

9 Personalcomputer (PC)

10 Bildschirm

11 Tablet-Computer

12 Smartphone

13 Datenspeicher

14 Server

15 ZuStandsspeieher

16 Table-Storage

17 Public Cloud

18 (Datenübertragungs-) etz

20 Rahmenkomponente

21 PräsentationsSchicht

22 Geschäftslogikschicht

23 DatenhaltungsSchicht

24 Laufzeitumgebung

25 Programmbibliothek

26 Datenmodell

27 ZuStandsmode11

28,28a-e Spike

30 (spezifischer) Teil

31 (generischer) Teil

32 UI -Element-Komponente

33 UI -Layout-Komponente

34 UI-FunctionHandler-Komponente

35 Geschäftslogikkomponente

36 Meta-Spikelet

37 Daten-Spikelet

38 Zustands-Spikelet _n

39 Handler-Spikelet

40 Aufruf

41 Aufruf

42 Aufruf

43 Aufruf

44 Aufruf

50 Ereignis

51 Ereignis

52 Ereignis

53 Ereignis

54 Ereignis

55 Ereignis

56 Ereignis

57 Ereignis

58 Ereignis

59 Ereignis

N Nutzdaten

Z ZuStandsdaten