DE102014207726B4

DE102014207726B4 - Effizientes Zugriffsverfahren auf in einer Cloud gespeicherte Bilddaten

Info

Publication number: DE102014207726B4
Application number: DE102014207726.5A
Authority: DE
Inventors: Karlheinz Dorn
Original assignee: Siemens Healthcare GmbH
Current assignee: Siemens Healthineers Ag De
Priority date: 2014-04-24
Filing date: 2014-04-24
Publication date: 2023-07-20
Anticipated expiration: 2034-04-25
Also published as: US11252102B2; US20150312168A1; DE102014207726A1

Abstract

Von einem Device (1) ausgeführtes Zugriffsverfahren auf in einer Cloud (3) gespeicherte Bilddaten (7, 8),- wobei das Device (1) eine Zugriffsanforderung (ZA) auf die Bilddaten (7, 8) an die Cloud (3) übermittelt,- wobei das Device (1) von der Cloud (3) einen Zugriffspfad (ZP) auf die Bilddaten (7, 8) entgegennimmt,- wobei das Device (1) anhand des Zugriffspfades (ZP) prüft, ob die Bilddaten (7, 8) in einem ersten Datenformat oder in einem zweiten Datenformat vorliegen,- wobei das Device (1) in dem Fall, dass die Bilddaten (7, 8) in dem ersten Datenformat vorliegen,-- die Bilddaten (7) über den Zugriffspfad (ZP) aus der Cloud (3) ausliest,-- die Bilddaten (7) innerhalb des Devices (1) in das zweite Datenformat konvertiert,-- die in das zweite Datenformat konvertierten Bilddaten (8) in die Cloud (3) einspeichert,-- den Zugriffspfad (ZP) gemäß einer vorbestimmten Modifikationsvorschrift modifiziert, so dass anhand des Zugriffspfades (ZP) erkennbar ist, dass die Bilddaten (8) in der Cloud (3) im zweiten Datenformat gespeichert sind, und-- den modifizierten Zugriffspfad (ZP) in die Cloud (3) einspeichert,- wobei das Device (1) in dem Fall, dass die Bilddaten (8) in dem zweiten Datenformat vorliegen,-- entweder stets über den Zugriffspfad (ZP) die Bilddaten (8) in dem zweiten Datenformat aus der Cloud (3) ausliest-- oder prüft, ob ihr von einem Benutzer (9) ein Sonderbefehl (S) vorgegeben ist, und in Abhängigkeit von dem Sonderbefehl (S)--- entweder über den Zugriffspfad (ZP) die Bilddaten (8) in dem zweiten Datenformat aus der Cloud (3) ausliest--- oder den Zugriffspfad (ZP) anhand der Modifikationsvorschrift remodifiziert und über den remodifizierten Zugriffspfad (ZP) die Bilddaten (7) in dem ersten Datenformat aus der Cloud (3) ausliest, dadurch gekennzeichnet, dass das Device (1) in dem Fall, dass es die in das zweite Datenformat konvertierten Bilddaten (8) und den modifizierten Zugriffspfad (ZP) in die Cloud (3) einspeichert,- die von dem Device (1) in die Cloud (3) eingespeicherten Bilddaten (8) in dem zweiten Datenformat aus der Cloud (3) ausliest,- die in dem zweiten Datenformat aus der Cloud (3) ausgelesenen Bilddaten (8) auf Identität mit den von dem Device (1) zuvor konvertierten Bilddaten (8) überprüft,- im Falle der Identität die in der Cloud (3) im ersten Datenformat gespeicherten Bilddaten (7) löscht und- im Falle der Nichtidentität eine Fehlerreaktion ausführt.

Description

Die vorliegende Erfindung betrifft ein von einem Device ausgeführtes Zugriffsverfahren auf in einer Cloud gespeicherte Bilddaten.
Die vorliegende Erfindung betrifft weiterhin maschinenlesbarem Programmcode für ein Device, wobei der Programmcode Steuerbefehle aufweist, deren Ausführung bewirkt, dass das Device ein derartiges Zugriffsverfahren ausführt.
Die vorliegende Erfindung betrifft weiterhin ein mit derartigem Programmcode programmiertes Device.
Das DICOM-Format ist ein standardisiertes, herstellerneutrales Datenformat in der medizinbezogenen Datenverarbeitung. Insbesondere zwei- oder dreidimensionale medizinische Bilddaten werden oftmals im DICOM-Format generiert und gespeichert. Die DICOM-Dateien definieren ein eigenes Format, das mit einem variabel langen Headerbereich für Meta-Daten beginnt und mit einem ebenso variablen Datenbereich für die Pixeldaten endet Dies gilt unabhängig davon, mittels welcher Modalität die Bilder generiert werden. Beispiele derartiger Modalitäten sind Magnetresonanzanlagen, Computertomographen, C-Bogen-Röntgenanlagen, Ultraschallscanner und mehr.
Im Stand der Technik werden die generierten Bilder mehr oder minder lokal gespeichert, beispielsweise über ein Intranet in einem innerhalb eines Krankenhauses angeordneten PACS (= picture archiving and communication system). Für die Datenübertragung wird oftmals auch ein für DICOM eigens definiertes Protokoll verwendet.
In jüngerer Zeit werden Daten mehr und mehr in globale Systeme ausgelagert, beispielsweise in eine sogenannte Cloud. Eine derartige Auslagerung ist auch für DICOM-Daten möglich. In diesem Fall müssen die entsprechenden Bilddaten jedoch jedes Mal, wenn sie von einem Benutzer benötigt werden, aus der Cloud in das Device des Benutzers geladen werden. Das DICOM-Protokoll selbst und seine Verwendung sind nicht für ein Zusammenwirken mit einer Cloud optimiert.
DICOM-Bilddaten sind oftmals sehr umfangreich. Das Laden derartiger Bilddaten belastet daher die Kommunikationsverbindung zwischen dem Device des Benutzers und der Cloud in erheblichem Umfang. Dies gilt insbesondere dann, wenn von dem Device aus der Cloud ganze Sequenzen von Bilddaten abgerufen werden und über ein Sichtgerät an den Benutzer ausgegeben werden, beispielsweise in einer mehrfach wiederholten Schleife (sogenannte Cine-Loop).
Aus der Druckschrift US 2012 / 0 254 368 A1 ist eine Relaisvorrichtung bekannt, wobei die Relaisvorrichtung zur Kommunikation mit einem Service-Provider und einem Service-Cooperating-Systeme, wobei das Service-Cooperating-System ein MFP (z.B. Drucker) umfasst. Die Relaisvorrichtung ist ausgebildet, eine Datenanforderung des Service-Cooperating-Systems an den Service-Provider zu vermitteln und zu managen, wobei wenn nötig eine Dateikonvertierung durch die Relaisvorrichtung initiiert wird.
In der Druckschrift US 2013 / 0 036 135 A1 sind Systeme und Verfahren zum effizienten Speichern von Informationen offenbart. Beispielsweise können Kopien von Dateien geringerer Qualität lokal gespeichert werden und Originalversionen von Dateien höherer Qualität können im Internet gespeichert werden. Das lokale Speichern einer Version einer Datei mit geringerer Qualität oder niedrigerer Auflösung kann die lokalen Speicheranforderungen reduzieren.
Aus dem Dokument US 2012 / 0 084 350 A1 ist ein reines Webbrowser-basiertes medizinisches Bildgebungssystem bekannt, das keine Installation von Anwendungssoftware oder Browser-Plug-Ins erfordert und funktioniert wie herkömmliche vollwertige PACS (Picture Archiving and Communication Systems). Darüber hinaus verteilt das System die Rechenaufgaben der Bildwiedergabe zwischen Browser und Servern, von der vollständigen serverseitigen Wiedergabe bis zur vollständigen clientseitigen Wiedergabe und allem dazwischen.
In der Druckschrift US 2011/0214 041 A1 wird ein Verfahren zum Übertragen mehrerer medizinischer Bilddatensätze von einer ersten Recheneinrichtung zu einer zweiten Recheneinrichtung offenbart, wobei die zweite Recheneinrichtung nach erfolgter Übertragung eine Übermittlungsbestätigung an die erste Recheneinrichtung sendet. In zumindest einer Ausführungsform wird vor dem Übertragen der Bilddatensätze eine erste Prüfsumme über alle Bilddatensätze ermittelt und mit den Bilddatensätzen versendet.
Die Aufgabe der vorliegenden Erfindung besteht darin, Möglichkeiten zu schaffen, mittels derer auf einfache und zuverlässige Weise der Zugriff auf die in der Cloud gespeicherten Bilddaten vereinfacht werden kann.
Die Aufgabe wird durch ein Zugriffsverfahren mit den Merkmalen des Anspruchs 1 gelöst. Vorteilhafte Ausgestaltungen des erfindungsgemäßen Zugriffsverfahrens sind Gegenstand der abhängigen Ansprüche 2 bis 7.
Erfindungsgemäß wird ein Zugriffsverfahren geschaffen, bei dem

- das Device eine Zugriffsanforderung auf die Bilddaten an die Cloud übermittelt,
- das Device von der Cloud einen Zugriffspfad auf die Bilddaten entgegennimmt,
- das Device anhand des Zugriffspfades prüft, ob die Bilddaten in einem ersten Datenformat oder in einem zweiten Datenformat vorliegen,
- das Device in dem Fall, dass die Bilddaten in dem ersten Datenformat vorliegen,
- -- die Bilddaten über den Zugriffspfad aus der Cloud ausliest,
- -- die Bilddaten innerhalb des Devices in das zweite Datenformat konvertiert,
- -- die in das zweite Datenformat konvertierten Bilddaten in die Cloud einspeichert,
- -- den Zugriffspfad gemäß einer vorbestimmten Modifikationsvorschrift modifiziert, so dass anhand des Zugriffspfades erkennbar ist, dass die Bilddaten in der Cloud im zweiten Datenformat gespeichert sind, und
- -- den modifizierten Zugriffspfad in die Cloud einspeichert,
- das Device in dem Fall, dass die Bilddaten in dem zweiten Datenformat vorliegen,
- -- entweder stets über den Zugriffspfad die Bilddaten in dem zweiten Datenformat aus der Cloud ausliest
- -- oder prüft, ob ihr von einem Benutzer ein Sonderbefehl vorgegeben ist, und in Abhängigkeit von dem Sonderbefehl
  - --- entweder über den Zugriffspfad die Bilddaten in dem zweiten Datenformat aus der Cloud ausliest
  - --- oder den Zugriffspfad anhand der Modifikationsvorschrift remodifiziert und über den remodifizierten Zugriffspfad die Bilddaten in dem ersten Datenformat aus der Cloud ausliest.

Die Bilddaten werden durch die erfindungsgemäße Vorgehensweise somit zwar umformatiert. Die örtliche Bildauflösung (Länge und Breite in Pixeln oder Länge und Breite und Tiefe in Voxeln) bleiben jedoch erhalten. Auch weitere für die Interpretation der Bilddaten relevante Daten wie beispielsweise die Pixel- bzw. Voxelgröße und die Zentrierung bleiben erhalten. Die Kodierung der Bilddaten wird jedoch von dem ersten Datenformat in das zweite Datenformat konvertiert. Hiermit kann - nicht aber muss - auch eine Reduzierung der Datentiefe (beispielsweise nur noch 8 Bit statt zuvor 16 Bit) verbunden sein. Je nach beteiligten Datenformaten kann durch die erfindungsgemäße Vorgehensweise eine Datenreduzierung um den Faktor 10 und mehr erreicht werden, beispielsweise eine Datenreduzierung um den Faktor 20.
Die Zugriffsanforderung kann beispielsweise eine URL (= universal ressource locator) sein. In Reaktion auf die Vorgabe der URL kann beispielsweise von der Cloud als Zugriffspfad eine andere URL zurück geliefert werden. Auch andere Ausgestaltungen sind jedoch möglich.
Wenn mittels der erfindungsgemäßen Vorgehensweise erstmals die Bilddaten aus der Cloud abgerufen werden (diese also noch und ausschließlich im ersten Datenformat vorliegen), ist die Ausführung der erfindungsgemäßen Vorgehensweise mit einem gewissen Mehraufwand verbunden. Denn es müssen nicht nur die Bilddaten im ersten Datenformat aus der Cloud ausgelesen werden. Es müssen vielmehr zusätzlich auch die Bilddaten in das zweite Datenformat konvertiert und in die Cloud eingespeichert werden. Der entsprechende Aufwand kann jedoch in aller Regel im Hintergrund ausgeführt werden, ohne dass der Benutzer dies merkt. Bei jedem weiteren Abruf der Bilddaten hingegen - unabhängig davon, ob die Daten mittels desselben Devices abgerufen werden oder mittels eines anderen Devices, das die erfindungsgemäße Vorgehensweise realisiert, abgerufen werden - ergibt sich die durch die erfindungsgemäße Vorgehensweise bewirkte Verringerung des Kommunikationsaufwands.
Das zweite Datenformat kann verlustbehaftet sein. Dies ist in aller Regel jedoch für eine medizinische Vorbefundung von untergeordneter Bedeutung. Denn bei Bedarf - d.h. durch Vorgabe des entsprechenden Sonderbefehls - stehen auch die Bilddaten im ersten Datenformat, das heißt mit ihrem vollen Informationsgehalt, zur Verfügung.
Aufgrund der Änderung des Datenformats ist auch eine Modifikation des Zugriffspfades erforderlich. Die Modifikation umfasst in der Regel zumindest eine Modifikation des Dateityps von einer das erste Datenformat charakterisierenden Extension in eine das zweite Datenformat charakterisierende Extension.
Der eigentliche Name des Zugriffspfades bleibt jedoch vorzugsweise 1:1 erhalten. Alternativ zu einer Erhaltung 1:1 kann die Modifikation des Zugriffspfades eine Änderung eines - und vorzugsweise auch nur eines einzigen - Ordners, in dem die Bilddaten gespeichert sind, umfassen. Diese letztgenannte Ausgestaltung ist insbesondere dann von Vorteil, wenn die Bilddaten mehrerer Bilder eine Gruppe oder Sequenz bilden. Denn dann können die entsprechenden Bilder der jeweiligen Gruppe oder Sequenz in der Cloud im ersten Datenformat in einem ersten Ordner und im zweiten Datenformat in einem zweiten Ordner gespeichert werden, wobei die Bilddaten selbst - mit Ausnahme der Extension - identische Namen aufweisen und die Ordner, in denen die Bilder im ersten Datenformat und im zweiten Datenformat in der Cloud gespeichert sind, sich nur durch ein oder zwei alphanumerische Zeichen unterscheiden.
Es ist möglich, dass das erfindungsgemäße Zugriffsverfahren nur von Devices ausgeführt wird, welche lesend auf die in der Cloud gespeicherten Bilddaten zugreifen. Es ist jedoch auch möglich, dass das erfindungsgemäße Zugriffsverfahren von einem Device ausgeführt wird, das die Bilddaten in dem ersten Datenformat in die Cloud einspeichert. Beispiele derartiger Devices sind Rechner, die mit bildgebenden Modalitäten verbunden sind und die von den bildgebenden Modalitäten erfassten Daten übernehmen. In einem derartigen Fall ist es also so, dass das Device vor dem Übermitteln einer Zugriffsanforderung auf die Bilddaten an die Cloud die Bilddaten in dem ersten Datenformat und einen Zugriffspfad auf die Bilddaten in die Cloud einspeichert. Das Device, welches die Bilddaten in dem ersten Datenformat in die Cloud einspeichert, sorgt also selbst zugleich auch dafür, dass die Bilddaten auch in dem zweiten Datenformat in die Cloud eingespeichert werden.
In aller Regel müssen die ursprünglichen Bilddaten, d.h. die im ersten Datenformat gespeicherten Bilddaten, erhalten bleiben. Es ist möglich, dass diese Speicherung in der Cloud erfolgt. Alternativ ist es möglich, dass diese Speicherung außerhalb der Cloud erfolgt. Erfindungsgemäß ist es vorgesehen, dass das Device in dem Fall, dass es die in das zweite Datenformat konvertierten Bilddaten und den modifizierten Zugriffspfad in die Cloud einspeichert,

- die von dem Device in die Cloud eingespeicherten Bilddaten in dem zweiten Datenformat aus der Cloud ausliest,
- die in dem zweiten Datenformat aus der Cloud ausgelesenen Bilddaten auf Identität mit den von dem Device zuvor konvertierten Bilddaten überprüft,
- im Falle der Identität die in der Cloud im ersten Datenformat gespeicherten Bilddaten löscht und
- im Falle der Nichtidentität eine Fehlerreaktion ausführt.

Die Fehlerreaktion kann beispielsweise darin bestehen, dass ein erneuter Versuch zum Speichern der Bilddaten im zweiten Datenformat in der Cloud vorgenommen wird, die vorstehend erläuterte Vorgehensweise also wiederholt wird. Alternativ oder zusätzlich ist es möglich, eine Fehlermeldung an den Benutzer auszugeben.
Durch das Löschen der im ersten Datenformat gespeicherten Bilddaten kann beispielsweise erreicht werden, dass persönliche Daten, die im ersten Datenformat in den Bilddaten vorhanden sind, in den im zweiten Datenformat gespeicherten Bilddaten nicht mehr enthalten sind.
In einer bevorzugten Ausgestaltung wird das Zugriffsverfahren eingebettet in einen Web-Browser ausgeführt. Dies bietet folgenden Vorteil:

Wenn die Bilddaten bereits im zweiten Datenformat vorliegen - dies gilt auch dann, wenn die Bilddaten unmittelbar zuvor mittels dieses Devices in die Cloud eingespeichert wurden -, werden die Bilddaten beim Auslesen aus der Cloud in einem für den Web-Browser reservierten temporären Pufferspeicher des Devices zwischengespeichert. Dies ist bei Web-Browsern allgemeine Praxis. Wenn in einem derartigen Fall die Bilddaten wiederholt beispielsweise über ein Sichtgerät an einen Benutzer ausgegeben werden sollen, werden die Bilddaten daher beim allerersten Auslesen, wenn sie also lediglich im ersten Datenformat vorliegen, im ersten Datenformat aus der Cloud ausgelesen und im zweiten Datenformat in die Cloud eingespeichert. Beim zweiten Auslesen, wenn sie also bereits im zweiten Datenformat vorliegen, werden die Bilddaten im zweiten Datenformat aus der Cloud ausgelesen und im temporären Pufferspeicher des Web-Browsers zwischengespeichert. Für jede weitere Ausgabe an den Benutzer ist in einem derartigen Fall überhaupt kein Zugriff des Web-Browsers über das Datennetz erforderlich. Denn die Bilddaten im zweiten Datenformat sind in diesem Fall bereits im temporären Pufferspeicher des Web-Browsers gespeichert. Besonders vorteilhaft ist dies, wenn - wie allgemein üblich - für die Nutzung der Cloud ein Entgelt zu entrichten ist. Denn in diesem Fall muss der Benutzer des Devices maximal zweimal auf die Cloud zugreifen. Ab dem dritten Zugriff sind die Bilddaten im temporären Pufferspeicher des Web-Browsers gespeichert.

Die Datenformate können nach Bedarf bestimmt sein. Das erste Datenformat kann insbesondere das DICOM-Format sein. Das zweite Datenformat kann beispielsweise das JPEG-Format oder das PNG-Format sein. Alle drei Datenformate sind Fachleuten allgemein bekannt.
Die Aufgabe wird weiterhin durch maschinenlesbaren Programmcode für ein Device gelöst, wobei der Programmcode Steuerbefehle aufweist, deren Ausführung bewirkt, dass das Device ein erfindungsgemäßes Zugriffsverfahren ausführt. Der Programmcode kann insbesondere auf einem Speichermedium gespeichert sein.
Die Aufgabe wird weiterhin durch ein mit erfindungsgemäßem Programmcode programmiertes Device gelöst.
Die oben beschriebenen Eigenschaften, Merkmale und Vorteile dieser Erfindung sowie die Art und Weise, wie diese erreicht werden, werden klarer und deutlicher verständlich im Zusammenhang mit der folgenden Beschreibung der Ausführungsbeispiele, die in Verbindung mit den Zeichnungen näher erläutert werden. Hierbei zeigen in schematischer Darstellung:

1 ein Device und eine Cloud,
2 ein Ablaufdiagramm,
3 Zugriffspfade,
4 ein Ablaufdiagramm,
5 ein Ablaufdiagramm,
6 Zugriffspfade,
7 ein Ablaufdiagramm und
8 ein Ablaufdiagramm.

Gemäß 1 ist ein Device 1 über das Internet 2 mit einer Cloud 3 verbunden. Das Device 1 kann beispielsweise ein Tablet, ein PC, ein Smartphone usw. sein. Das Device 1 kann auch eine bildgebende medizintechnische Modalität sein oder mit einer derartigen Modalität verbunden sein. Das Device 1 ist mit einem maschinenlesbaren Programmcode 4 programmiert. Der maschinenlesbare Programmcode 4 kann dem Device 1 auf prinzipiell beliebige Weise zugeführt werden. Insbesondere kann der maschinenlesbare Programmcode 4 entsprechend der Darstellung in 1 auf einem Speichermedium 5 gespeichert sein. Das Speichermedium 5 kann seinerseits ebenfalls beliebiger Natur sein. Die Darstellung in 1, in der das Speichermedium 5 als USB-Memorystick dargestellt ist, ist rein beispielhaft. Der maschinenlesbare Programmcode 4 weist Steuerbefehle 6 auf, die von dem Device 1 ausführbar sind. Die Ausführung der Steuerbefehle 6 bewirkt, dass das Device 1 ein Zugriffsverfahren auf in der Cloud 3 gespeicherte Bilddaten 7, 8 ausführt. Das Zugriffsverfahren wird nachstehend in Verbindung mit den weiteren FIG näher erläutert.
Gemäß 2 übermittelt das Device 1 im Rahmen des erfindungsgemäßen Zugriffsverfahrens in einem Schritt S1 eine Zugriffsanforderung ZA auf die Bilddaten 7, 8 an die Cloud 3. Die Zugriffsanforderung ZA kann beispielsweise eine URL sein. Sie kann beispielsweise eine Person, ein Datum und eine Körperregion der Person spezifizieren.
In einem Schritt S2 nimmt das Device 1 von der Cloud 3 einen Zugriffspfad ZP auf die Bilddaten 7, 8 entgegen. Der Zugriffspfad ZP enthält (unter anderem) die Information, ob die Bilddaten 7, 8 in einem ersten Datenformat (Bilddaten 7) oder in einem zweiten Datenformat (Bilddaten 8) vorliegen. Der Zugriffspfad ZP kann beispielsweise eine URL sein.
In einem Schritt S3 prüft das Device 1 anhand des Zugriffspfades ZP, ob die Bilddaten 7, 8 im ersten Datenformat oder im zweiten Datenformat vorliegen. In Abhängigkeit von der Prüfung des Schrittes S3 werden weitere Maßnahmen ergriffen.
Die vorliegende Erfindung wird nachfolgend aus Gründen der besseren Anschaulichkeit unter der Annahme erläutert, dass es sich bei dem ersten Datenformat um das DICOM-Format und bei dem zweiten Datenformat um das JPEG-Format handelt. Diese Ausgestaltung stellt einen häufigen Anwendungsfall dar. Wenn nachfolgend somit vom DICOM-Format die Rede ist, ist stets das erste Datenformat in seiner Allgemeinheit gemeint, nicht speziell das DICOM-Format. In analoger Weise ist, wenn nachfolgend vom JPEG-Format die Rede ist, stets das zweite Datenformat in seiner Allgemeinheit gemeint, nicht speziell das JPEG-Format. Insbesondere könnte es sich bei dem zweiten Datenformat beispielsweise alternativ um das PNG-Format handeln.
Wenn die Bilddaten 7, 8 im DICOM-Format vorliegen, geht das Device 1 zu Schritten S4 bis S10 über. Im Schritt S4 liest das Device 1 die Bilddaten 7 über den Zugriffspfad ZP aus der Cloud 3 aus. Das Auslesen erfolgt im DICOM-Format.
Im Schritt S5 führt das Device 1 ein sogenanntes Rendering der ausgelesenen Bilddaten 7 durch, ermittelt also ein zugehöriges Bild B. Im Schritt S6 gibt das Device 1 das gerenderte Bild B an einen Benutzer 9 des Devices 1 aus. Die Schritte S5 und S6 sind - soweit es das erfindungsgemäße Zugriffsverfahren betrifft - als solche nicht zwingend erforderlich. Sie sind jedoch üblicherweise vorhanden.
Im Schritt S7 konvertiert das Device 1 die Bilddaten 7 innerhalb des Devices 1 in das JPEG-Format. Das Device 1 generiert somit die Bilddaten 8 (JPEG-Format). Im Schritt S8 speichert das Device 1 die Bilddaten 8 in die Cloud 3 ein. Das Einspeichern erfolgt unter derjenigen Adresse, auf die mittels der Zugriffsanforderung ZA zugegriffen wird.
Im Schritt S9 modifiziert das Device 1 den Zugriffspfad ZP. Die Modifikation erfolgt gemäß einer vorbestimmten Modifikationsvorschrift, und zwar so, dass anhand des modifizierten Zugriffspfades ZP erkennbar ist, dass die Bilddaten 8 in der Cloud 3 im JPEG-Format gespeichert sind. Im Schritt S10 speichert das Device 1 den modifizierten Zugriffspfad ZP in die Cloud 3 ein.
Die im DICOM-Format vorliegenden Bilddaten 7 bestehen aus einem Header und aus den eigentlichen Nutzdaten. Ebenso bestehen die im JPEG-Format vorliegenden Bilddaten 8 aus einem Header und den eigentlichen Nutzdaten. Der Header der DICOM-Bilddaten 7 enthält unter anderem Daten über das Bild B als solches wie beispielsweise dessen Länge, dessen Breite, im Falle eines dreidimensionalen Bildes B dessen Tiefe, dessen Pixel- oder Voxelgröße, dessen Zentrierung und dergleichen mehr. Der Header enthält weiterhin Daten beispielsweise über die Person, von der die Bilddaten 7 stammen, die also in den Bilddaten 7 dargestellt ist, wann und wo die Bilddaten erfasst wurden und dergleichen mehr (persönliche medizinische Daten). Zur Konvertierung der Bilddaten 7 in die Bilddaten 8 verwendet das Device 1 zwar die Daten über das Bild B als solches. Die JPEG-Bilddaten 8 zeigen also ein Bild B, welches beispielsweise die gleiche Länge und die gleiche Breite, gegebenenfalls auch Tiefe, und auch die gleiche Pixel- oder Voxelgröße aufweist wie die DICOM-Bilddaten 7. Die anderen Daten, also die persönlichen medizinischen Daten, werden vorzugsweise nicht in die JPEG-Bilddaten 8 übernommen.
Wenn die Bilddaten 7, 8 hingegen im JPEG-Format vorliegen, geht das Device 1 zu einem Schritt S11 über. Im Schritt S11 prüft das Device 1, ob ihm vom Benutzer 9 ein Sonderbefehl S vorgegeben ist. Wenn dies der Fall ist, liest das Device 1 - unabhängig davon, ob die Bilddaten 7, 8 in der Cloud 3 im JPEG-Format vorliegen oder nicht - stets die DICOM-Bilddaten 7 aus der Cloud 3 aus. Das Device 1 geht daher zu einem Schritt S12 über. Im Schritt S12 führt das Device 1 anhand der Modifikationsvorschrift eine Remodifikation des Zugriffspfades ZP durch. Das Device 1 ermittelt also im Schritt S12 denjenigen Zugriffspfad ZP, über den auf die DICOM-Bilddaten 7 zugegriffen werden kann. Sodann liest das Device 1 über den remodifizierten Zugriffspfad ZP die Bilddaten 7 aus der Cloud 3 aus. Am einfachsten kann dies dadurch realisiert werden, dass das Device 1 entsprechend der Darstellung in 2, ausgehend vom Schritt S12, zum Schritt S4 übergeht.
Wenn dem Device 1 hingegen vom Benutzer 9 der Sonderbefehl S nicht vorgegeben ist, geht das Device 1 zu Schritten S13 bis S15 über. Im Schritt S13 liest das Device 1 über den Zugriffspfad ZP die JPEG-Bilddaten 8 aus der Cloud 3 aus. Im Schritt S14 führt das Device 1 - analog zum Schritt S5 - ein sogenanntes Rendering der ausgelesenen Bilddaten 8 durch, ermittelt also ein zugehöriges Bild B. Im Schritt S15 gibt das Device 1 das gerenderte Bild B an den Benutzer 9 des Devices 1 aus. Die Schritte S14 und S15 sind - soweit es das erfindungsgemäße Zugriffsverfahren betrifft - analog zu den Schritten S5 und S6 als solche nicht zwingend erforderlich. Sie sind jedoch üblicherweise vorhanden.
Alternativ ist es möglich, dass die Schritte S11 und S12 entfallen. In diesem Fall geht das Device 1 nach der Prüfung des Schrittes S3 gegebenenfalls direkt zum Schritt S13 über.
3 zeigt beispielhaft zwei Zugriffspfade ZP. Oben in 3 ist ein Zugriffspfad ZP dargestellt, der im Rahmen des Schrittes S2 übermittelt wird, wenn die Zugriffsanforderung ZA des Schrittes S1 eine Anforderung für ein einzelnes Bild B ist und die Bilddaten 7 im DICOM-Format vorliegen. Unten in 3 ist der korrespondierende Zugriffspfad ZP dargestellt, der im Rahmen des Schrittes S2 übermittelt wird, wenn die Zugriffsanforderung ZA des Schrittes S1 eine Anforderung für ein einzelnes Bild B ist und die Bilddaten 7 im JPEG-Format vorliegen. Ersichtlich sind die Zugriffspfade ZP weitgehend identisch. Sie unterscheiden sich lediglich in der Extension, welche für das Datenformat verwendet wird, nämlich DCM für das DICOM-Format und JPG für das JPEG-Format. Aus 3 ist daher ohne weiteres erkennbar, dass das Device 1 im Rahmen des Schrittes S3 lediglich die Extension prüfen muss, im Rahmen des Schrittes S9 lediglich die Extension von DCM in JPG abändern muss und im Rahmen des Schrittes S12 lediglich die Extension von JPG in DCM abändern muss. Weitere Änderungen sind im Falle einer Anforderung einzelner Bilddaten 7, 8 prinzipiell nicht erforderlich.
In den Anhängen 1 und 2 sind rein beispielhaft die konkreten Zugriffspfade ZP im Detail dargestellt. Die in den Anhängen 1 und 2 dargestellten Zugriffspfade ZP sind im XML-Format abgefasst. Anhang 1 zeigt den Zugriffspfad ZP auf die DICOM-Bilddaten 7, Anhang 2 den Zugriffspfad ZP auf die korrespondierenden JPEG-Bilddaten 8.
Es ist möglich, dass die Bilddaten 7, 8 nicht nur ein einzelnes Bild B, sondern eine Gruppe von Bildern B umfassen. In dem Fall, dass die Bilddaten 7, 8 eine Gruppe von Bildern B umfassen, ist es prinzipiell möglich, für jedes einzelne Bild B die Vorgehensweise gemäß 2 in unveränderter Form zu ergreifen. Vorzugsweise jedoch wird die Vorgehensweise von 2 in leicht modifizierter Form angewendet. Dies wird nachfolgend in Verbindung mit den 4 bis 6 näher erläutert.
Gemäß 4 ist zunächst die Abfolge der Schritte S4 bis S10 durch Schritte S21 bis S23 ergänzt. Im Schritt S21 setzt das Device 1 einen Index i auf einen Anfangswert (beispielsweise entsprechend der Darstellung in 4 auf den Wert 1). Im Schritt S22 prüft das Device 1, ob der Index i seinen Endwert erreicht hat. Je nach Ergebnis der Prüfung im Schritt S22 geht das Device 1 entweder zum Schritt S9 oder zum Schritt S23 über. Im Schritt S23 erhöht das Device 1 den Wert des Index i um 1. Gemäß 5 ist weiterhin die Abfolge der Schritte S13 bis S15 durch Schritte S26 bis S28 ergänzt. Die Schritte S26 bis S28 korrespondieren inhaltlich mit den Schritten S21 bis S23, so dass auf die diesbezüglichen Ausführungen verwiesen werden kann.
6 zeigt - bezogen auf die Modifikation gemäß den 4 und 5 - beispielhaft zwei Zugriffspfade ZP. Oben in 6 ist ein Zugriffspfad ZP dargestellt, der im Rahmen des Schrittes S2 übermittelt wird, wenn die Zugriffsanforderung ZA des Schrittes S1 eine Anforderung für mehrere Bilder B ist und die Bilddaten 7 im DICOM-Format vorliegen. Unten in 3 ist der korrespondierende Zugriffspfad ZP dargestellt, der im Rahmen des Schrittes S2 übermittelt wird, wenn die Zugriffsanforderung ZA des Schrittes S1 eine Anforderung für mehrere Bilder B ist und die Bilddaten 8 im JPEG-Format vorliegen. Ersichtlich sind die Zugriffspfade ZP weitgehend identisch. Sie unterscheiden sich zum einen in der Extension, welche für das Datenformat verwendet wird, nämlich DCM für das DICOM-Format und JPG für das JPEG-Format. Sie unterscheiden sich zum anderen im Namen eines Ordners, in dem die Bilddaten 7 bzw. 8 der einzelnen Bilder B in der Cloud 3 gespeichert sind. Vorzugsweise existieren nur diese beiden Änderungen. Weiterhin unterscheiden sich die Namen der beiden Ordner vorzugsweise lediglich in nur einem oder zwei alphanumerischen Zeichen. Beispielsweise kann der Name der beiden Ordner je nachdem, um welches Datenformat es sich handelt, die Buchstabenfolge „DCC“ oder „DZC“ enthalten und im übrigen identisch sein.
Aus 6 ist daher - analog zu 3 - auch ohne weiteres erkennbar, welche Prüfung das Device 1 im Rahmen des Schrittes S3 vornehmen muss und welche Änderungen das Device 1 im Rahmen des Schrittes S9 und des Schrittes S12 vornehmen muss.
In den Anhängen 3 und 4 sind rein beispielhaft für den zuletzt beschriebenen Fall die konkreten Zugriffspfade ZP im Detail dargestellt. Die in den Anhängen 3 und 4 dargestellten Zugriffspfade ZP sind im XML-Format abgefasst. Anhang 3 zeigt den Zugriffspfad ZP auf die DICOM-Bilddaten 7, Anhang 4 den Zugriffspfad ZP auf die korrespondierenden JPEG-Bilddaten 8. In den Anhängen 5 und 6 sind weiterhin im XML-Format die Befehlsabfolgen dargestellt, die zum sequenziellen Abrufen der einzelnen Bilder B der DICOM-Bilddaten 7 (Anhang 5) bzw. der JPEG-Bilddaten 8 (Anhang 6) erforderlich sind. Anhang 7 zeigt in HTML 5 und Javascript eine mögliche Befehlsabfolge, mittels derer die einzelnen Bilder der DICOM-Bilddaten 7 sequenziell nacheinander aus der Cloud 3 ausgelesen werden können. Anhang 8 zeigt in HTML 5 und Javascript eine mögliche Befehlsabfolge, mittels derer die JPEG-Bilder 8 generiert und in die Cloud 3 eingespeichert werden können.
Wie bereits erwähnt, kann das Device 1 beispielsweise eine bildgebende medizintechnische Modalität sein oder mit einer derartigen Modalität verbunden sein. Insbesondere in diesem Fall - aber prinzipiell nicht nur in diesem Fall - ist es möglich, dass erfindungsgemäße Zugriffsverfahren derart auszugestalten, wie dies nachstehend in Verbindung mit 7 näher erläutert wird.
Gemäß 7 sind dem Schritt S1 von 2 Schritte S31 und S32 vorgeordnet. Im Schritt S31 speichert das Device 1 die Bilddaten 7 im DICOM-Format in die Cloud 3 ein (Upload). Im Schritt S32 speichert das Device 1 weiterhin den zugehörigen Zugriffspfad ZP auf die soeben eingespeicherten Bilddaten 7 in die Cloud 3 ein. Das Einspeichern erfolgt unter derjenigen Adresse, auf die mittels der Zugriffsanforderung ZA zugegriffen wird. Aufgrund des Umstands, dass die Schritte S31 und S32 vor dem Schritt S1 ausgeführt werden, erfolgen das Einspeichern der DICOM-Bilddaten 7 und des Zugriffspfades ZP vor dem Übermitteln einer Zugriffsanforderung ZA auf die Bilddaten 7 an die Cloud 3.
Die Ausgestaltung gemäß 7 ist - analog zur Ausgestaltung gemäß 2 - sowohl bezüglich eines einzelnen Bildes B als auch bezüglich einer Gruppe von Bildern B möglich.
Alternativ oder zusätzlich zu der Ausgestaltung gemäß 7 ist es möglich, das Zugriffsverfahren gemäß 8 auszugestalten. 8 zeigt eine Ergänzung zu den Schritten S4 bis S10 von 2. Die Ergänzung wäre jedoch ohne weiteres auch realisierbar, wenn das Zugriffsverfahren gemäß den 4 und 5 ausgestaltet ist. Die Ausgestaltung gemäß 8 wird wieterhin vorzugsweise mit der Vorgehensweise von 7 kombiniert. Sie ist jedoch auch unabhängig von dieser Vorgehensweise realisierbar. Das Device 1 ist im Rahmen der Ausgestaltung gemäß 8 vorzugsweise als bildgebende medizintechnische Modalität ausgebildet oder mit einer derartigen Modalität verbunden. Prinzipiell kann das Device 1 jedoch beliebig ausgebildet sein.
Gemäß 8 werden nach den Schritten S4 bis S10 zusätzliche Schritte S41 bis S44 ausgeführt. Im Schritt S41 liest das Device 1 - analog zum Schritt S13 - die in die Cloud 3 eingespeicherten JPEG-Bilddaten 8 aus der Cloud 3 aus. Das Device 1 liest also im Schritt S41 genau diejenigen JPEG-Bilddaten 8 aus der Cloud 3 aus, die das Device 1 zuvor in die Cloud 3 eingespeichert hat. Im Schritt S42 überprüft das Device 1 die ausgelesenen JPEG-Bilddaten 8 mit den im Schritt S7 generierten JPEG-Bilddaten 8 auf Identität. Das Device 1 überprüft also, ob das Einspeichern der JPEG-Bilddaten 8 in die Cloud 3 ordnungsgemäß erfolgt ist. Wenn dies der Fall ist, löscht das Device 1 im Schritt S43 die in der Cloud 3 gespeicherten korrespondierenden DICOM-Bilddaten 7. Es sind also nach dem Löschen der DICOM-Bilddaten 7 in der Cloud 3 nur noch die JPEG-Bilddaten 8 vorhanden. Anderenfalls führt das Device 1 im Schritt S44 eine Fehlerreaktion aus. Die Fehlerreaktion kann beispielsweise darin bestehen, einen weiteren Schreibversuch in die Cloud 3 zu unternehmen. Alternativ kann eine Fehlermeldung an den Benutzer 9 ausgegeben werden.
Das Löschen der DICOM-Bilddaten 7 erfolgt vorzugsweise nur dann, wenn die DICOM-Bilddaten 7 zuvor anderweitig dauerhaft gespeichert werden. Vorzugsweise ist daher gemäß 8 zusätzlich ein Schritt S45 vorhanden, in dem eine derartige Speicherung erfolgt. Diese Speicherung kann alternativ in der Cloud 3 oder außerhalb der Cloud 3 erfolgen, beispielsweise in einem PACS.
Es ist möglich, Rechenoperationen in die Cloud 3 zu verlagern. Vorzugsweise wird die Cloud 3 jedoch im Rahmen des erfindungsgemäßen Zugriffsverfahrens ausschließlich als Speicher genutzt. Durch diese Vorgehensweise ist es insbesondere auf einfache Weise zusätzlich möglich, ein Auto-Zoom und/oder ein Zoom/Pan durchzuführen.
Das erfindungsgemäße Zugriffsverfahren kann als eigenständige Applikation ausgebildet sein. Vorzugsweise wird es jedoch eingebettet in einen Web-Browser ausgeführt. Diese Vorgehensweise ist insbesondere dann von Vorteil, wenn die JPEG-Bilddaten 8 einer Gruppe von Bildern B sequenziell und iterativ (also in einer wiederholt ausgeführten Schleife) aus der Cloud 3 abgerufen und an den Benutzer 9 ausgegeben werden.
Es ist weiterhin möglich, dass Auslesen der Bilddaten 7, 8 aus der Cloud 3 miteinander zu kombinieren. So kann beispielsweise, wenn die JPEG-Bilddaten 8 einer Gruppe von Bildern B sequenziell und iterativ aus der Cloud 3 abgerufen und an den Benutzer 9 ausgegeben werden, die Wiedergabe vom Benutzer 9 gestoppt werden, so dass dem Benutzer 9 nach dem Stoppen die Möglichkeit gegeben wird, in den Bildern B zu blättern. Wenn der Benutzer 9 ein bestimmtes Bild B oder eine bestimmte Untergruppe der Bilder B selektiert, werden die DICOM-Bilddaten 7 des selektierten Bildes B bzw. der selektierten Bilder B abgerufen und an den Benutzer 9 ausgegeben.
Durch die Dualität der Bilddaten 7, 8 - d.h. das Abspeichern unter nahezu identischen Namen und Zugriffspfaden ZP - ist es auf einfache und fehlersichere Weise möglich, miteinander korrespondierende DICOM-Bilddaten 7 und JPEG-Bilddaten 8 zu verwalten.
Zusammengefasst betrifft die vorliegende Erfindung somit folgenden Sachverhalt:

Ein Device 1 übermittelt eine Zugriffsanforderung ZA auf in einer Cloud 3 gespeicherte Bilddaten 7, 8 an die Cloud 3 und nimmt daraufhin von der Cloud 3 einen Zugriffspfad ZP auf die Bilddaten 7, 8 entgegen. Das Device 1 prüft anhand des Zugriffspfades ZP, in welchem Datenformat die Bilddaten 7, 8 vorliegen. Wenn die Bilddaten 7, 8 in einem ersten Datenformat vorliegen, liest das Device 1 die Bilddaten 7 über den Zugriffspfad ZP aus der Cloud 3 aus, konvertiert sie innerhalb des Devices 1 in das zweite Datenformat und speichert die konvertierten Bilddaten 8 in die Cloud 3 ein. Ferner modifiziert sie den Zugriffspfad ZP gemäß einer Modifikationsvorschrift, so dass anhand des Zugriffspfades ZP erkennbar ist, dass die Bilddaten 8 in der Cloud 3 im zweiten Datenformat gespeichert sind, und speichert den modifizierten Zugriffspfad ZP in die Cloud 3 ein. Wenn die Bilddaten 8 in dem zweiten Datenformat vorliegen, liest das Device 1 entweder stets über den Zugriffspfad ZP die Bilddaten 8 in dem zweiten Datenformat aus der Cloud 3 oder prüft, ob ihr von einem Benutzer 9 ein Sonderbefehl S vorgegeben ist. Im letztgenannten Fall liest das Device 1 in Abhängigkeit von dem Sonderbefehl S entweder über den Zugriffspfad ZP die Bilddaten 8 in dem zweiten Datenformat aus der Cloud 3 aus oder remodifiziert den Zugriffspfad ZP anhand der Modifikationsvorschrift und liest über den remodifizierten Zugriffspfad ZP die Bilddaten 7 in dem ersten Datenformat aus der Cloud 3 aus.

Obwohl die Erfindung im Detail durch das bevorzugte Ausführungsbeispiel näher illustriert und beschrieben wurde, so ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen.
Anhang 1

<Context>

 <PartitionKey xmlns =
 "http://schemas.datacontract.org/2004/07/Microsoft.Samples.
 WindowsPhoneCloud.StorageClient"> GER</PartitionKey>
 <RowKey xmlns =
 "http://schemas.datacontract.org/2004/07/Microsoft.Samples.
 WindowsPhoneCloud.StorageClient">13acb1e8-ca04-4527-af73-
 4 f 6ba4 92bb4d</RowKey>
 <Timestamp xmlns =
 "http://schemas.datacontract.org/2004/07/Microsoft.Samples.
 WindowsPhoneCloud.StorageClient">2012-02-
 21T10:27:07.6956173Z</Timestamp>
 <ARegion>Head</ARegion>
 <AnatomicalRegion>None</AnatomicalRegion>
 <AppHost>http://singapore.blob.core.windows.net/|</AppHost>
 <CloudBlobBaseUri>blob.core.windows.net|</CloudBlobBaseUri>
 <CloudCom-
 puteBaseUri>rdemo9.cloudapp.net </CloudComputeBaseUri>
 <CloudComputeDeployment>rdemo9 </CloudComputeDeployment>
 <CloudStorageAccount>singapore|</CloudStorageAccount>
 <CloudTableBaseUri>table.core.windows.net|</CloudTableBaseU
 ri>
 <ComputeHost>http://rdemo9.cloudapp.net/|</ComputeHost>
 <Con-
 figHost>http://singapore.blob.core.windows.net/|</ConfigHos
 t>
 <Content>Image</Content>
 <DZInstDataRel-
 Path>/mysingapore/DicomImagesDLR_Head_Single/41214342.dcm</
 DZInstDataRelPath>
 <DZMHDDataRelPath>None</DZMHDDataRelPath>
 <DZMetaDataRelPath>dicom</DZMetaDataRelPath>
 <Drive>CLOUDDRIVE_VHD vhd/myvhd1.vhd</Drive>
 <NameUC>-USECASE VRT -VOLUME SWIZZLING false -MODE Dynami-
 cLinearSampling -SHADING true</NameUC>
 <ProcedureUid>mysingapore </ProcedureUid> 




 <Server-
 Ba-
 seUri>http://singapore.blob.core.windows.net</ServerBaseUri
 >
 <StorageFormat>DICOM</StorageFormat>
 <Stor-
 age-
 Host>http://singapore.blob.core.windows.net/ </StorageHost>
 <StorageHostVol-
 umeSeries2d>http://singapore.blob.core.windows.net/mysingap
 ore/IMAGES_POPIP/Data3D/RawVolumes/VRT_AngioCarotid_279/|</
 StorageHostVolumeSeries2d>
 <StorageHostVol-
 umeSeries2dAnz>1</StorageHostVolumeSeries2dAnz>
 <StorageType>LOCAL</StorageType>
 <Thumb>http://singapore.blob.core.windows.net/mysingapore/t
 humbs/dlr.jpg</Thumb>
 </Context>

Anhang 2

<Context>

 <PartitionKey xmlns =
 "http://schemas.datacontract.org/2004/07/Microsoft.Samples.
 WindowsPhoneCloud.StorageClient"> GER</PartitionKey>
 <RowKey xmlns =
 "http://schemas.datacontract.org/2004/07/Microsoft.Samples.
 WindowsPhoneCloud.StorageClient">13acb1e8-ca04-4527-af73-
 4 f 6ba4 92bb4d</RowKey>
 <Timestamp xmlns =
 "http://schemas.datacontract.org/2004/07/Microsoft.Samples.
 WindowsPhoneCloud.StorageClient">2012-02-
 21T10:27:07.6956173Z</Timestamp>
 <ARegion>Head</ARegion>
 <AnatomicalRegion>None</AnatomicalRegion>
 <AppHost>http://singapore.blob.core.windows.net/|</AppHost>
 <CloudBlobBaseUri>blob.core.windows.net|</CloudBlobBaseUri> 




 <CloudCom-
 puteBaseUri>rdemo9.cloudapp.net </CloudComputeBaseUri>
 <CloudComputeDeployment>rdemo9 </CloudComputeDeployment>
 <CloudStorageAccount>singapore|</CloudStorageAccount>
 <CloudTableBaseUri>table.core.windows.net|</CloudTableBaseU
 ri>
 <ComputeHost>http://rdemo9.cloudapp.net/|</ComputeHost>
 <Con-
 figHost>http://singapore.blob.core.windows.net/|</ConfigHos
 t>
 <Content>Image</Content>
 <DZInstDataRel-
 Path>/mysingapore/DicomImagesDLR_Head_Single/41214342.jpg</
 DZInstDataRelPath>
 <DZMHDDataRelPath>None</DZMHDDataRelPath>
 <DZMetaDataRelPath>jpg</DZMetaDataRelPath>
 <Drive>CLOUDDRIVE_VHD vhd/myvhd1.vhd</Drive>
 <NameUC>-USECASE VRT -VOLUME SWIZZLING false -MODE Dynami-
 cLinearSampling -SHADING true</NameUC>
 <ProcedureUid>mysingapore </ProcedureUid>
 <Server-
 Ba-
 seUri>http://singapore.blob.core.windows.net</ServerBaseUri
 >
 <StorageFormat>DICOMJPEG</StorageFormat>
 <Stor-
 age-
 Host>http://singapore.blob.core.windows.net/ </StorageHost>
 <StorageHostVolumeSe-
 ries2d>http://singapore.blob.core.windows.net/mysingapore/I
 MAGES_POPIP/Data3D/RawVolumes/VRT_Angio Caro-
 tid_279/1</StorageHostVolumeSeries2d>
 <StorageHostVolumeSe-
 ries2dAnz>1</StorageHostVolumeSeries2dAnz>
 <StorageType>LOCAL</StorageType>
 <Thumb>http://singapore.blob.core.windows.net/mysingapore/t
 humbs/dlr.jpg</Thumb>
 </Context>

Anhang 3

 <Context>
 <PartitionKey xmlns =
 "http://schemas.datacontract.org/2004/07/Microsoft.Samples.
 WindowsPhoneCloud.StorageClient"> GER</PartitionKey>
 <RowKey xmlns =
 "http://schemas.datacontract.org/2004/07/Microsoft.Samples.
 WindowsPhoneCloud.StorageClient">ti16 </RowKey>
 <Timestamp xmlns =
 "http://schemas.datacontract.org/2004/07/Microsoft.Samples.
 WindowsPhoneCloud.StorageClient">2012-02-
 21T10:27:10.182866Z</Timestamp>
 <ARegion>Head</ARegion>
 <AnatomicalRegion>None</AnatomicalRegion>
 <AppHost>http://singapore.blob.core.windows.net/|</AppHost>
 <CloudBlobBaseUri>blob.core.windows.net|</CloudBlobBaseUri>
 <CloudComputeBaseU-
 ri>rdemo9.cloudapp.net </CloudComputeBaseUri>
 <CloudComputeDeployment>rdemo9 </CloudComputeDeployment>
 <CloudStorageAccount>singapore|</CloudStorageAccount>
 <CloudTableBaseUri>table.core.windows.net|</CloudTableBaseU
 ri>
 <ComputeHost>http://rdemo9.cloudapp.net/|</ComputeHost>
 <Con-
 figHost>http://singapore.blob.core.windows.net/|</ConfigHos
 t>
 <Content>image series</Content>
 <DZInstDataRel-
 Path>/mysingapore/DicomlmagesDLR_Head/dcc_output.xml</DZIns
 tDataRelPath>
 <DZMHDDataRelPath>None</DZMHDDataRelPath>
 <DZMetaDataRel-
 Path>/mysingapore/GeneratedImages/Metadata.xml</DZMetaDataR
 elPath>
 <Drive>None</Drive> 




 <NameUC>None</NameUC>
  <ProcedureUid>mysingapore|</ProcedureUid>
 <Server-
 Ba-
 seUri>Cloud=blob.core.windows.net1 TenantStorage=singapore | T
 enantCompute=rdemo9|Procedure=mysingapore|AppHost =
 http://singapore.blob.core.windows.net/|ConfigHost=http://s
 ingapore.blob.core.windows.net/ ComputeHost = http://
 rdemo9.cloudapp.net/|StorageHost =
 http://singapore.blob.core.windows.net|StorageHostVolumeSer
 ies2d = http:// singa-
 pore.blob.core.windows.net/mysingapore/IMAGES_POPIP/Data3D/
 RawVol-
 umes/ct_600/|StorageHostVolumeSeries2dAnz=600</ServerBaseUr
 i>
 <StorageFormat>DICOM</StorageFormat>
 <Stor-
 age-
 Host>http://singapore.blob.core.windows.net/ </StorageHost>
 <StorageHostVol-
 umeSeries2d>http://singapore.blob.core.windows.net/mysingap
 ore/DicomImagesDLR_Head/dcc_output_images
 / </StorageHostVolumeSeries2d>
 <StorageHostVol-
 umeSeries2dAnz>4</StorageHostVolumeSeries2dAnz>
 <StorageType>None</StorageType>
 <Thumb>http://singapore.blob.core.windows.net/mysingapore/t
 humbs/dlr.jpg</Thumb>
 </Context>

Anhang 4

<Context>

 <PartitionKey xmlns =
 "http://schemas.datacontract.org/2004/07/Microsoft.Samples.
 WindowsPhoneCloud.StorageClient"> GER</PartitionKey> 




 <RowKey xmlns =
 "http://schemas.datacontract.org/2004/07/Microsoft.Samples.
 WindowsPhoneCloud.StorageClient">ti16 </RowKey>
 <Timestamp xmlns =
 "http://schemas.datacontract.org/2004/07/Microsoft.Samples.
 WindowsPhoneCloud.StorageClient">2012-02-
 21T10:27:10.182866Z</Timestamp>
 <ARegion>Head</ARegion>
 <AnatomicalRegion>None</AnatomicalRegion>
 <AppHost>http://singapore.blob.core.windows.net/|</AppHost>
 <CloudBlobBaseUri>blob.core.windows.net|</CloudBlobBaseUri>
 <CloudCom-
 puteBaseUri>rdemo9.cloudapp.net </CloudComputeBaseUri>
 <CloudComputeDeployment>rdemo9 </CloudComputeDeployment>
 <CloudStorageAccount>singapore|</CloudStorageAccount>
 <CloudTableBaseUri>table.core.windows.net|</CloudTableBaseU
 ri>
 <ComputeHost>http://rdemo9.cloudapp.net/|</ComputeHost>
 <Con-
 figHost>http://singapore.blob.core.windows.net/|</ConfigHos
 t>
 <Content>image series</Content>
 <DZInstDataRel-
 Path>/mysingapore/DicomlmagesDLR_Head/dzc_output.xm1</DZIns
 tDataRelPath>
 <DZMHDDataRelPath>None</DZMHDDataRelPath>
 <DZMetaDataRel-
 Path>/mysingapore/GeneratedImages/Metadata.xml</DZMetaDataR
 elPath>
 <Drive>None</Drive>
 <NameUC>None</NameUC>
 <ProcedureUid>mysingapore </ProcedureUid>
 <Server-
 Ba-
 seUri>Cloud=blob.core.windows.net1 TenantStorage=singapore | T
 enantCompute=rdemo9|Procedure=mysingapore|AppHost =
 http://singapore.blob.core.windows.net/|ConfigHost =
 http://singapore.blob.core.windows.net/|ComputeHost = 




 http://
 rdemo9.cloudapp.net/ StorageHost=http://singapore.blob.core
 .windows.net|StorageHostVolumeSeries2d = http://singapore.
 blob.core.windows.net/mysingapore/IMAGES_POPIP/Data3D/RawVo
 lumes/ct_600/IStorageHostVolumeSeries2dAnz=600</ServerBaseU
 ri>
 <StorageFormat>DICOMJPEG</StorageFormat>
 <Stor-
 age-
 Host>http://singapore.blob.core.windows.net/ </StorageHost>
 <StorageHostVol-
 umeSeries2d>http://singapore.blob.core.windows.net/mysingap
 ore/DicomImagesDLR_Head/dcc_output_images/1
 </StorageHostVolumeSeries2d>
 <StorageHostVol-
 umeSeries2dAnz>4</StorageHostVolumeSeries2dAnz>
 <StorageType>None</StorageType>
 <Thumb>http://singapore.blob.core.windows.net/mysingapore/t
 humbs/dlr.jpg</Thumb>
 </Context>

Anhang 5

 <?xml version="1.0" encoding="utf-8"?>
 <Collection MaxLevel="8" TileSize="256" Format="dcm" Nex-
 tItemId="65" ServerFormat="Default"
 xmlns="http://schemas.microsoft.com/deepzoom/2009">
 <Items>
  <I Id="0" N="0"
  Source="dcc_output_images/1.3.12.2.1107.5.8.2.485257.8350
  54.68674855.20080115074748630.dcm">
  <Size Width="512" Height="512" />
  <Viewport Width="1" X="-0" Y="-0" />
  </I>
  <I Id="1" N="1"
  Source="dcc_output_images/1.3.12.2.1107.5.8.2.485257.8350
  54.68674855.20080115074748840.dcm"> 




  <Size Width="512" Height="512" />
    <Viewport Width="1" X="-1" Y="-1" />
    <I Id="63" N="63"
    Source="dcc_output_images/1.3.12.2.1107.5.8.2.485257.83
    5054.68674855.20080115074804300.dcm">
    <Size Width="512" Height="512" />
    <Viewport Width="1" X="-1" Y="-1" />
  </I>
  <I Id="64" N="64"
  Source="dcc_output_images/1.3.12.2.1107.5.8.2.485257.8350
  54.68674855.220080115074804550.dem">
    <Size Width="512" Height="512" />
    <Viewport Width="1" X="-1" Y="-1" />
  </I>
 </Items>
 </Collection>

Anhang 6

 <?xml version="1.0" encoding="utf-8"?>
 <Collection MaxLevel="8" TileSize="256" Format="jpg" Nex-
 tItemId="65" ServerFormat="Default"
 xmlns="http://schemas.microsoft.com/deepzoom/2009">
 <Items>
  <I Id="0" N="0"
  Source="dzc_output_images/1.3.12.2.1107.5.8.2.485257.8350
  54.68674855.20080115074748630.jpg">
    <Size Width="512" Height="512" />
    <Viewport Width="1" X="-0" Y="-0" />
  </I>
  <I Id="1" N="1"
  Source="dzc_output_images/1.3.12.2.1107.5.8.2.485257.8350
  54.68674855.20080115074748840.jpg">
    <Size Width="512" Height="512" />
    <Viewport Width="1" X="-1" Y="-1" />
  </I> 




  <I Id="63" N="63"
  Source="dzc_output_images/1.3.12.2.1107.5.8.2.485257.8350
  54.68674855.20080115074804300.jpg">
    <Size Width="512" Height="512" />
    <Viewport Width="1" X="-1" Y="-1" />
  </I>
  <I Id="64" N="64"
  Source="dzc_output_images/1.3.12.2.1107.5.8.2.485257.8350
  54.68674855.220080115074804550.jpg">
    <Size Width="512" Height="512" />
    <Viewport Width="1" X="-1" Y="-1" />
  </I>
 </Items>
 </Collection>

Anhang 7

 DcmApp.prototype.load_url = function(url, index, file_count)
 {
  var xhr = new XMLHttpRequest();
  xhr.open('GET', url, true);
  xhr.responseType = 'arraybuffer';
  xhr.onload = (function(app) {
    return function(evt) {
      return app.load_arraybuffer(evt.target.response, in-
      }}dex, file_count, url);
  }) (this);
  xhr.send();
  DcmApp.prototype.load_arraybuffer = function(abuf, index,
  file_count, fileOrUrl) {
  var tcanvasuri; 




  var app = this;
  var buffer = new Uint8Array(abuf);
  parser = new DicomParser(buffer);
  var file = parser.parse_file();
  if (file == undefined) {
    app.files[index] = undefined;
  }return;
  if (file.Modality == "CT" | | file.Modality == "PT" | |
  file.Modality == "MR") {
    imageOrientation = file.ImageOrientationPatient;
    file.imageOrientationRow = imageOrientation.slice(0,3);
    file.imageOrientationColumn = imageOrienta-
    tion. slice (3, 6) ;
    app.organize _file(file);
  } else if(file.modality == "US") {
    file.RescaleIntercept = 0;
    file.RescaleSlope = 1;
    app.files[index] = file;
    app.organize_file(file);
  } else {
    file.RescaleIntercept = 0;
    file.RescaleSlope = 1;
    app.organize_file(file);
  }app.files[index] = file;
  app.curr file_idx = index;
  if (file.PixelSpacing !== undefined) {
    app.curr_series_uid = file.SOPInstanceUID;
  }app.files[index] = file;
  else {
    app.curr_series_uid = file.SeriesInstanceUID;
  }app.files = app.series[app.curr_series_uid] .files;
  if (app.externalApp == true) { 




    // do not draw in main canvas
  }
  else {
  }app.draw_image();

   ++app.files_loaded;

  if (app.externalApp == true) {
    if(app.files_loaded == 1) {
    }app.draw_image();
    fill_thumbnail(file.Columns, file.Rows,
    app.curr_series_uid, index, this, this.series,
    this.curr_series_uid, function(cid) { return new Can-
    vasPainter(cid) });
    if(app.files_upload_enabled == true && dicom_Jpegflag
    == false) {
      upload _DicomAsJpegImageWithCloudPath(fileOrUrl,
      file.Columns, file.Rows, app.curr_series_uid, index,
      app.files_loaded, file_count, this, this.series,
      this.curr_series _uid, function(cid) { return new Can-
      vasPainter(cid) });
    }
  }
  if(app.files_loaded == file_count) {
    if (file.PixelSpacing !== undefined) {
    }}}instance_number_sort(app.files);

Anhang 8

function upload_DicomAsJpegImageWithCloudPath(srcpath, w, h,

 uid, ind, loaded, totalCount, app, series, selected_uid,
 painter_factory)
 { 




 var host = "blob.core.windows.net"; // microsoft azure
 storage
 var subscription = "singapore";
 var images_container = "mysingapore";
 var config_container = "config";
 var uploads_container = "uploads";
 var images _container _path = "http://" + subscription + "."
 + host + "/" + images_container;
 var config _container _path = "http://" + subscription + "."
 + host + "/" + config_container;
 var uploads_container_path = "http://" + subscription + "."
 + host + "/" + uploads_container;
 var images_container_cert = "?sr=c&si=kalle&sig=xxx";
 var config_container_cert = "?sr=c&si=kalle&sig=yyy";
 var uploads_container_cert = "?sr=c&si=kalle&sig=zzz";
 var srcSubPath = "dcc_output_images";
 var dstSubPath = "dzc_output_images";
 var dstpath1;
 if (totalCount > 1)
  dstpath1 = srcpath.replace(srcSubPath,dstSubPath);
 else
  dstpath1 = srcpath;
 var dstpath = dstpath1.replace(".dcm",".jpg");
 var pathend = srcpath.indexOf("dcc_output_images/")
 var cloudPathScenegraphXmlFile;
 if (totalCount > 1)
  cloudPathScenegraphXmlFile = srcpath.substring(0,
  pathend) + "dzc_output.xml";
 else
  cloudPathScenegraphXmlFile = "";
 var cloudPathTweetXmlFile = dicom_tweet_url;
 var upload_canvas = document.createElement("canvas"); 




 upload_canvas.id = 'canvas_thumb_' + ind;
 upload_canvas.width = w;
 upload_canvas.height = h;
 var painters = [//function(cid) { return new GLPaint-
 er(cid); }, function(cid) { return new CanvasPainter(cid);
 }, ] ;
 for(var i in painters) {
  var painter = painters[i] (upload_canvas.id);
  try {
    break;
  } catch(e) {
 }}console.log(e);
 painter.init(upload_canvas.id);
 if (app.externalApp == true) {
 }painter.set_canvas(upload_canvas);
 painter.set_cluts(ClutManager.r('Plain'), ClutManag-
 er.g('Plain'), ClutManager.b('Plain'));
 painter.set_file(series[uid].files[0]);
 var retv = getWindowingValuesFromDcmFile(app, se-
 ries[uid].files[0]);
 wl = retv[0];
 ww = retv[1];
 painter.set_windowing(wl, ww);
 painter.draw_image(); // draw thumbnail of image into can-
 vas
 if (app.externalApp == true) {
  var dataUrl = upload_canvas.toDataURL("image/jpeg");
  // 1) save as jpeg file
  saveAnyDataUriTypeIntoCloudPathWithCert(dataUrl, "Di-
  comJpg", "jpg", images_container_cert, dstpath, upload-
  DicomAsJpgDone);
  if(loaded == totalCount) {
    var str = dicom_dcc_output_xml; 




    str = str.replace(/\b(dicom)\b/g, "jpg");
    str = str.replace(/\b(.dcm)\b/g, ".jpg");
    str = str.replace(/\b(dcc_output_images)\b/g,
    "dzc_output_images") ;
    var dststr = str;
    var retpath;
    if (totalCount > 1)
      retpath = saveAnyXmlFileIntoCloudPathWithCert(dststr,
      images_container_cert, cloudPathScenegraphXmlFile);
      //
      // 2) upload into config container the modified tweet
      file for DICOMJPEG
      //
      str = dicom_tweet_xml;
      if (totalCount > 1)
        str = str.replace(/\b(dcc_output_images)\b/g,
        "dzc_output_images");
      else
        str = str.replace(/\b(.dcm)\b/g, ".jpg");
        str = str.replace(/\b(DICOM)\b/g, "DICOMJPEG");
        //
        // Attention:
        // replace the path to jpeg, because if we want
        read in pure DICOM later on we use the dcc_xxx
        //
        dststr = str;
        retpath = saveAnyXmlFileIntoCloud-
        PathWithCertCb(dststr, config_container_cert,
        cloudPathTweetXmlFile, uploadTweetAsXmlDone,
    }}dststr); // replace tweet file
    }
    /* callback for DICOMJPEG Tweet xml file upload has been done
    */
    function uploadTweetAsXmlDone (result, par) {
 if (result == true) { 




  if (par != null) {
  //
  // 3) restart the app in same window with same url (but
  modified tweet content (DICOMJPEG))
  //
    doReloadInSameWindow() ;
  }
 }
 else {
  // handle error here
  alert ("upload tweet error occured: uri=" + par + " not
 } successfully done!");
 }
 /* callback for DICOMJPEG image upload has been done */
 function uploadDicomAsJpgDone (result, par) {
   if (result == true) {
        if (par != null) {
             //alert("upload of uri=" + par + " successful-
             ly done!");
        }
   }
   else {
        // handle error here
        alert("upload error occured: uri=" + par + " not
        successfully done!");
   }
   }

Bezugszeichenliste

1: Device
2: Internet
3: Cloud
4: Programmcode
5: Speichermedium
6: Steuerbefehle
7: Bilddaten
8: Bilddaten
9: Benutzer
B: Bild
i: Index
S: Sonderbefehl
S1 bis S45: Schritte
ZA: Zugriffsanforderung
ZP: Zugriffspfad

Claims

Von einem Device (1) ausgeführtes Zugriffsverfahren auf in einer Cloud (3) gespeicherte Bilddaten (7, 8), - wobei das Device (1) eine Zugriffsanforderung (ZA) auf die Bilddaten (7, 8) an die Cloud (3) übermittelt, - wobei das Device (1) von der Cloud (3) einen Zugriffspfad (ZP) auf die Bilddaten (7, 8) entgegennimmt, - wobei das Device (1) anhand des Zugriffspfades (ZP) prüft, ob die Bilddaten (7, 8) in einem ersten Datenformat oder in einem zweiten Datenformat vorliegen, - wobei das Device (1) in dem Fall, dass die Bilddaten (7, 8) in dem ersten Datenformat vorliegen, -- die Bilddaten (7) über den Zugriffspfad (ZP) aus der Cloud (3) ausliest, -- die Bilddaten (7) innerhalb des Devices (1) in das zweite Datenformat konvertiert, -- die in das zweite Datenformat konvertierten Bilddaten (8) in die Cloud (3) einspeichert, -- den Zugriffspfad (ZP) gemäß einer vorbestimmten Modifikationsvorschrift modifiziert, so dass anhand des Zugriffspfades (ZP) erkennbar ist, dass die Bilddaten (8) in der Cloud (3) im zweiten Datenformat gespeichert sind, und -- den modifizierten Zugriffspfad (ZP) in die Cloud (3) einspeichert, - wobei das Device (1) in dem Fall, dass die Bilddaten (8) in dem zweiten Datenformat vorliegen, -- entweder stets über den Zugriffspfad (ZP) die Bilddaten (8) in dem zweiten Datenformat aus der Cloud (3) ausliest -- oder prüft, ob ihr von einem Benutzer (9) ein Sonderbefehl (S) vorgegeben ist, und in Abhängigkeit von dem Sonderbefehl (S) --- entweder über den Zugriffspfad (ZP) die Bilddaten (8) in dem zweiten Datenformat aus der Cloud (3) ausliest --- oder den Zugriffspfad (ZP) anhand der Modifikationsvorschrift remodifiziert und über den remodifizierten Zugriffspfad (ZP) die Bilddaten (7) in dem ersten Datenformat aus der Cloud (3) ausliest, dadurch gekennzeichnet, dass das Device (1) in dem Fall, dass es die in das zweite Datenformat konvertierten Bilddaten (8) und den modifizierten Zugriffspfad (ZP) in die Cloud (3) einspeichert, - die von dem Device (1) in die Cloud (3) eingespeicherten Bilddaten (8) in dem zweiten Datenformat aus der Cloud (3) ausliest, - die in dem zweiten Datenformat aus der Cloud (3) ausgelesenen Bilddaten (8) auf Identität mit den von dem Device (1) zuvor konvertierten Bilddaten (8) überprüft, - im Falle der Identität die in der Cloud (3) im ersten Datenformat gespeicherten Bilddaten (7) löscht und - im Falle der Nichtidentität eine Fehlerreaktion ausführt.
Zugriffsverfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Modifikation des Zugriffspfades (ZP) eine Änderung eines Ordners, in dem die Bilddaten (7, 8) in der Cloud (3) gespeichert sind, und/oder eine Modifikation des Dateityps von einer das erste Datenformat charakterisierenden Extension in eine das zweite Datenformat charakterisierende Extension umfasst.
Zugriffsverfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Device (1) vor dem Übermitteln einer Zugriffsanforderung (ZA) auf die Bilddaten (7, 8) an die Cloud (3) die Bilddaten (7) in dem ersten Datenformat und einen Zugriffspfad (ZP) auf die Bilddaten (7) in die Cloud (3) einspeichert.
Zugriffsverfahren nach einem der obigen Ansprüche, dadurch gekennzeichnet, dass das Zugriffsverfahren eingebettet in einen Web-Browser ausgeführt wird.
Zugriffsverfahren nach einem der obigen Ansprüche, dadurch gekennzeichnet, dass das erste Datenformat das DICOM-Format ist und dass das zweite Datenformat das JPEG-Format oder das PNG-Format ist.
Maschinenlesbarer Programmcode für ein Device (1), wobei der Programmcode Steuerbefehle (6) aufweist, deren Ausführung bewirkt, dass das Device (1) ein Zugriffsverfahren nach einem der obigen Ansprüche ausführt.
Programmcode nach Anspruch 6, dadurch gekennzeichnet, dass der Programmcode auf einem Speichermedium (5) gespeichert ist.
Mit Programmcode (4) nach Anspruch 6 programmiertes Device.