DE112020001670T5

DE112020001670T5 - Universeller Webdienst für Dicom-Objekte

Info

Publication number: DE112020001670T5
Application number: DE112020001670.6T
Authority: DE
Inventors: Gary Kibble; Peter Jakes
Original assignee: Fujifilm Medical Systems USA Inc
Current assignee: Fujifilm Healthcare Americas Corp
Priority date: 2019-03-29
Filing date: 2020-02-28
Publication date: 2022-01-13
Also published as: JP2022528096A; US20200312440A1; JP7474270B2; GB2596760A8; WO2020205117A1; CA3131986A1; EP3948883A1; GB2596760A; MX2021011772A; US10854328B2; GB202114835D0; ES2933518A1; EP3948883A4; AU2020253711A1

Abstract

Es werden ein universeller Dienst für Objekte (z.B. DICOM-Objekte) und ein Verfahren zur Verarbeitung derselben beschrieben. In einer Ausführungsform umfasst das Verfahren: Empfangen einer Webdienstanforderung von einem entfernten Webclient für ein oder mehrere DICOM-Objekte (Digital Imaging and Communications in Medicine) an einer Webdienstmaschine; Erzeugen einer DIMSE-Anforderung (DICOM Message Service Element) aus der Webdienstanforderung, wobei das Erzeugen der DIMSE-Dienstanforderung das Parsen einer modifizierten Basis-URL umfasst, die Informationen für eine DIMSE-Dienstanforderung enthält, wobei die modifizierte URL mit einem Standard konform ist, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert; Senden der DIMSE-Dienstanforderung an einen Server; Empfangen einer Antwort auf die DIMSE-Dienstanforderung von dem Server; Neuformatieren der Antwort, so dass sie mit dem Standard übereinstimmt, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert; und Zurücksenden der neu formatierten Antwort an den entfernten Web-Client.

Description

BEREICH DER ERFINDUNG
Ausführungsformen der vorliegenden Erfindung beziehen sich auf das Gebiet des Abrufs, der Abfrage und der Speicherung medizinischer Bilder; insbesondere beziehen sich Ausführungsformen der vorliegenden Erfindung auf die Verarbeitung von Web-Service-Anfragen im Zusammenhang mit DICOM-Objekten (Digital Imaging and Communications in Medicine).
HINTERGRUND
Ärzte und anderes medizinisches Personal prüfen häufig alle relevanten klinischen Informationen eines Patienten, wenn sie medizinische Entscheidungen treffen. Die klinischen Informationen sind in der Regel in Gesundheitsstudien und strukturierten Berichten enthalten. Diese enthalten oft Informationen über die Krankengeschichte eines Patienten, Diagnoseberichte aus verschiedenen Bereichen, Bilder und andere klinische Daten in elektronischem Format.
Die medizinischen Bilder und Bildgebungsberichte werden häufig als DICOM-Objekte gespeichert. Die medizinischen Studien werden in der Regel als Reaktion auf einen Arzt erstellt, der eine Untersuchung für seinen Patienten anordnet. Die Untersuchung wird durchgeführt, und die erzeugte Studie wird häufig an ein Bildarchivierungs- und Kommunikationssystem (PACS) gesendet.
Im Jahr 2003 veröffentlichte die National Electrical Manufacturers Association (NEMA) einen Webservice-Standard für den Zugriff auf und die Darstellung von DICOM-Objekten (z. B. Bilder, medizinische Bildgebungsberichte). Genauer gesagt, bietet der Standard einen Mechanismus für den Zugriff auf ein DICOM-Objekt über das HTTP/HTTPS-Protokoll. Der NEMA DICOM Web Service Standard wird von vielen Anbietern unterstützt. WADO-RS bietet beispielsweise die Möglichkeit, ein oder mehrere DICOM-Objekte über das Internet herunterzuladen, QIDO-RS bietet die Möglichkeit, DICOM-Objekte über das Internet abzufragen, STOW-RS bietet die Möglichkeit, DICOM-Objekte zur Fernspeicherung über das Internet zu senden, und WADO-URI, eine ältere Version von WADO-RS, bietet die Möglichkeit, ein einzelnes DICOM-Objekt pro Internetanfrage herunterzuladen. Die aktuelle Version des Standards ist zu finden unter:

http://dicom.nema.org/medical/dicom/current/output/chtml/part18/PS3.18.html

Als die NEMA die Norm für Webdienste für DICOM veröffentlichte, wurde erwartet, dass jeder PACS-Anbieter seine eigene Implementierung der in der Norm spezifizierten Webdienste entwickelt, um den Internetzugang zu seinem PACS zu ermöglichen. Der Standard hat sich sehr bewährt, aber für einen DICOM-Client (Service Class User oder SCU), der WADO-RS/QIDO-RS als einzige Kommunikationsschnittstelle nutzen möchte, wird es einige PACS geben, auf die nicht zugegriffen werden kann, weil der Hersteller sie nicht unterstützt, weil es keine standardisierte WADO-RS/QIDO-RS-Implementierung gibt oder weil benutzerdefinierte Web-Authentifizierungsanforderungen bestehen.
Anbieter, die diese Webdienste unterstützen, bieten nur Zugang zu ihren eigenen anbieterspezifischen PACS. So muss z. B. das AGFA® WADO-RS verwendet werden, um von einem AGFA® PACS herunterzuladen, und das FUJIFILM WADO-RS muss verwendet werden, um vom Synapse® PACS herunterzuladen. Es gibt keine Anbieter mit einem WADO-RS/QIDO-RS, das auf jedes DICOM-PACS zugreifen kann.
ZUSAMMENFASSUNG DER ERFINDUNG
Es werden ein universeller Webdienst für Objekte (z.B. DICOM-Objekte) und ein Verfahren zur Verarbeitung derselben beschrieben. In einer Ausführungsform umfasst das Verfahren: Empfangen einer Webdienstanforderung von einem entfernten Webclient für ein oder mehrere DICOM-Objekte (Digital Imaging and Communications in Medicine) an einer Webdienstmaschine; Erzeugen einer DIMSE-Anforderung (DICOM Message Service Element) aus der Webdienstanforderung, wobei das Erzeugen der DIMSE-Dienstanforderung das Parsen einer modifizierten Basis-URL umfasst, die Informationen für eine DIMSE-Dienstanforderung enthält, wobei die modifizierte URL mit einem Standard konform ist, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert; Senden der DIMSE-Dienstanforderung an einen Server; Empfangen einer Antwort auf die DIMSE-Dienstanforderung von dem Server; Neuformatieren der Antwort, so dass sie mit dem Standard übereinstimmt, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert; und Zurücksenden der neu formatierten Antwort an den entfernten Web-Client.
In einer anderen Ausführungsform umfasst ein medizinisches Bildverwaltungssystem eine Netzwerkschnittstelle, um mit einem oder mehreren Clients und einem oder mehreren entfernten Servern zu kommunizieren, und eine Zugriffsmaschine mit Schaltkreisen, um einen ersten Satz von Anforderungen von dem einen oder den mehreren Clients zu empfangen, die an den einen oder die mehreren entfernten Server gerichtet sind, und um einen zweiten Satz von Anforderungen an die entfernten Server als Reaktion auf den ersten Satz von Anforderungen auszugeben, wobei der zweite Satz von Anforderungen entweder eine DICOM-Webdienstanforderung oder eine DIMSE-Anforderung ist.
Figurenliste
Die vorliegende Erfindung wird aus der nachstehenden detaillierten Beschreibung und den beigefügten Zeichnungen verschiedener Ausführungsformen der Erfindung, die jedoch nicht als Beschränkung der Erfindung auf die spezifischen Ausführungsformen zu verstehen sind, sondern lediglich der Erläuterung und dem Verständnis dienen, besser verständlich.

1 zeigt eine beispielhafte medizinische Informationssystemumgebung, mit der Ausführungsformen der vorliegenden Erfindung implementiert werden können.
2 zeigt ein Beispiel für eine Computersystemarchitektur für den Zugriff auf DICOM-Objekte.
3: Blockdiagramm eines Teils einer Ausführungsform eines medizinischen Bildverwaltungssystems zur Bearbeitung von Webdienstanfragen.
Die 4A-4C veranschaulichen Beispiele für die Umwandlung von Webdienstanforderungen in DIMSE-Dienstanforderungen.
5 ist ein Flussdiagramm einer Ausführungsform eines Prozesses zur Bearbeitung einer QIDO-RS-Webdienstanfrage.
6 ist ein Flussdiagramm einer Ausführungsform eines Prozesses zur Bearbeitung einer WADO-RS-Webdienstanfrage.
7 ist ein Flussdiagramm einer Ausführungsform eines Prozesses zur Bearbeitung einer WADO-RS-Webdienstanfrage.
8 ist ein Flussdiagramm einer Ausführungsform eines Prozesses zur Bearbeitung einer STOW-RS-Webdienstanfrage.
9 ist ein Flussdiagramm einer Ausführungsform eines Prozesses zur Verarbeitung einer Webdienstanfrage.
10 zeigt ein Beispiel für eine logische Darstellung eines medizinischen Bildgebungs- und Informationsmanagementsystems.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche Details aufgeführt, um die vorliegende Erfindung näher zu erläutern. Dem Fachmann wird jedoch klar sein, dass die vorliegende Erfindung auch ohne diese spezifischen Details ausgeführt werden kann. In anderen Fällen werden bekannte Strukturen und Vorrichtungen in Form von Blockdiagrammen und nicht im Detail dargestellt, um die vorliegende Erfindung nicht zu verdecken.
Ausführungsformen der vorliegenden Erfindung betreffen Systeme und Verfahren für den Zugriff auf DICOM-Objekte. Die DICOM-Objekte können in einem PACS, VNA oder einem anderen Server gespeichert sein. In einer Ausführungsform sind die DICOM-Objekte Teil von Gesundheitsstudien. In einer Ausführungsform wird der Zugriff über eine einzige, universelle DICOM-Webschnittstelle bereitgestellt. In einer Ausführungsform ist die universelle DICOM-Webschnittstelle NEMA-konform und kann auf jedes DICOM-PACS oder jeden Server zugreifen, der einen DICOM-Client (z. B. den Application Entity Title (AeTitle oder AET) des Service Class Users (SCU)) autorisiert. Die hier offenbarten Ausführungsformen bieten einen oder mehrere der folgenden Vorteile. So ermöglichen sie beispielsweise eine einzige Client/SCU-Internet-Authentifizierung, unabhängig davon, welches PACS eines Anbieters verwendet wird, bieten eine konsistente DICOM-Webdienste-Implementierung unabhängig vom PACS des Anbieters, erfordern nicht, dass der Client/SCU das DICOM-Protokoll C-FIND/C-MOVE/C-GET/C-STORE unterstützt, und ermöglichen den Internet-Zugang zu PACS-Anbietern, die noch keine DICOM-Webdienste unterstützen. In diesem Dokument wird der Begriff SCU verwendet, um einen Client zu beschreiben, einschließlich, aber nicht beschränkt auf einen DIMSE-Nachrichten-Client (TCP) oder einen Web-Client. Nach der kurzen Beschreibung eines Überblicks über die vorliegende Erfindung werden Ausführungsformen der Erfindung unter Bezugnahme auf die 1-10 erörtert.
Der Gegenstand der Ausführungsformen der vorliegenden Erfindung wird hierin genau beschrieben, um die gesetzlichen Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch den Anwendungsbereich dieses Patents nicht einschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden könnte, um verschiedene Schritte oder Kombinationen von Schritten, die den in diesem Dokument beschriebenen ähnlich sind, in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien zu umfassen.
Nach der kurzen Beschreibung von Ausführungsformen der vorliegenden Erfindung wird im Folgenden eine beispielhafte Betriebsumgebung beschrieben, die sich für die Umsetzung von Ausführungsformen der vorliegenden Erfindung eignet.
Unter Bezugnahme auf die Zeichnungen im Allgemeinen und zunächst auf 1 im Besonderen wird eine medizinische Informationsverarbeitungssystemumgebung, mit der Ausführungsformen der vorliegenden Erfindung implementiert werden können, dargestellt und allgemein mit dem Bezugszeichen 120 bezeichnet. Der Fachmann wird verstehen, dass die dargestellte medizinische Informationsverarbeitungssystemumgebung 120 lediglich ein Beispiel für eine geeignete Computerumgebung ist und keine Einschränkung des Anwendungsbereichs oder der Funktionalität der Erfindung darstellen soll. Auch sollte die medizinische Informationsverarbeitungssystemumgebung 120 nicht so interpretiert werden, dass eine Abhängigkeit oder Anforderung in Bezug auf eine einzelne Komponente oder eine Kombination von Komponenten besteht, die darin dargestellt sind.
Ausführungsformen der vorliegenden Erfindung können mit zahlreichen Allgemein- bzw. Allzweck- oder Spezial-Computersystemumgebungen oder -konfigurationen betrieben werden. Beispiele für bekannte Computersysteme, -umgebungen und/oder - konfigurationen, die für die Verwendung mit der vorliegenden Erfindung geeignet sein können, sind beispielsweise Personalcomputer, Servercomputer, Handheld- oder Laptop-Geräte, Multiprozessorsysteme, mikroprozessorbasierte Systeme, programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputer, Großrechner, verteilte Computerumgebungen, die eines der oben genannten Systeme oder Geräte enthalten, und dergleichen.
Ausführungsformen der vorliegenden Erfindung können im allgemeinen Kontext von computerausführbaren Anweisungen, wie z. B. Programmmodulen, beschrieben werden, die von einem Computer ausgeführt werden. Im Allgemeinen umfassen Programmmodule Routinen, Programme, Objekte, Komponenten und Datenstrukturen, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren, sind aber nicht darauf beschränkt. Die vorliegende Erfindung kann auch in verteilten Computerumgebungen angewandt werden, in denen Aufgaben von entfernten Verarbeitungsgeräten ausgeführt werden, die über ein Kommunikationsnetz verbunden sind. In einer verteilten Datenverarbeitungsumgebung können sich Programmmodule in Verbindung mit lokalen und/oder entfernten Computerspeichermedien befinden, zu denen, nur als Beispiel, Speichermedien gehören.
Wie in dargestellt, umfasst die beispielhafte medizinische Informationsverarbeitungssystemumgebung 120 ein Mehrzweck-Rechengerät in Form eines Kontroll- bzw. Steuerservers 122. Zu den Komponenten des Steuerservers 122 können unter anderem eine Verarbeitungseinheit, ein interner Systemspeicher und ein geeigneter Systembus zur Verbindung verschiedener Systemkomponenten, einschließlich des persistenten Speichers 124, mit dem Steuerserver 122 gehören. Bei dem Systembus kann es sich um verschiedene Arten von Busstrukturen handeln, einschließlich eines Speicherbusses oder Speichercontrollers, eines Peripheriebusses und eines lokalen Busses, wobei eine beliebige Busarchitektur verwendet werden kann. Zu diesen Architekturen gehören beispielsweise der ISA-Bus (Industry Standard Architecture), der MCA-Bus (Micro Channel Architecture), der EISA-Bus (Enhanced ISA), der lokale VESA-Bus (Video Electronic Standards Association) und der PCI-Bus (Peripheral Component Interconnect), auch als Mezzanine-Bus bekannt.
Der Steuerserver 122 enthält in der Regel Daten, die in einer Vielzahl von computerlesbaren Medien gespeichert sind, z. B. im Permanentspeicher 124, oder hat Zugriff darauf. Bei den computerlesbaren Medien kann es sich um jedes verfügbare Medium handeln, auf das der Server 122 zugreifen kann, einschließlich flüchtiger und nichtflüchtiger Medien sowie entfernbarer und nicht entfernbarer Medien. Als Beispiel und ohne Einschränkung können computerlesbare Medien Computerspeichermedien umfassen. Computerspeichermedien können ohne Einschränkung flüchtige und nichtflüchtige Medien sowie entfernbare und nicht entfernbare Medien umfassen, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen implementiert sind, wie beispielsweise computerlesbare Anweisungen, Datenstrukturen, Programmmodule, Datenbanken, formatierte Dateien, Registrierungsschlüssel oder andere Daten. In diesem Zusammenhang können Computerspeichermedien RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVDs) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium umfassen, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf das der Steuerserver 122 zugreifen kann. Zu den Kommunikationsmedien gehören beispielsweise verdrahtete Medien, wie ein verdrahtetes Netzwerk oder eine Direktverbindung, und drahtlose Medien, wie akustische, RF-, Infrarot- und andere drahtlose Medien, ohne Einschränkung. Kombinationen der oben genannten Medien können ebenfalls in den Bereich der computerlesbaren Medien fallen.
Die oben erörterten und in dargestellten Computerspeichermedien, einschließlich des persistenten Speichers 124, dienen der Speicherung von computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen und anderen Daten für den Steuerserver 122. Der Steuerserver 122 kann in einem Computernetzwerk 126 mit logischen Verbindungen zu einem oder mehreren entfernten Computern 128 betrieben werden. Entfernte Computer 128 können sich an einer Vielzahl von Orten in einer medizinischen oder Forschungsumgebung befinden, z. B. in klinischen Laboratorien (z. B. molekulardiagnostischen Laboratorien), Krankenhäusern und anderen stationären Einrichtungen, veterinärmedizinischen Umgebungen, ambulanten Einrichtungen, medizinischen Abrechnungs- und Finanzbüros, Krankenhausverwaltungseinrichtungen, Umgebungen für die häusliche Pflege und Arztpraxen. Zu den Klinikern gehören unter anderem der behandelnde Arzt oder die behandelnden Ärzte, Spezialisten wie Intensivmediziner, Chirurgen, Radiologen, Kardiologen und Onkologen, Notfallsanitäter, Arzthelfer, Krankenschwestern, Krankenpflegehelfer, Apotheker, Diätassistenten, Mikrobiologen, Laborexperten, Labortechniker, Radiologietechniker, Forscher, Tierärzte, Studenten und dergleichen. Entfernte Computer 128 können sich auch in nichttraditionellen medizinischen Versorgungsumgebungen befinden, so dass die gesamte Gesundheitsversorgung in das Netzwerk integriert werden kann. Bei den entfernten Computern 128 kann es sich um PCs, Server, Router, Netzwerk-PCs, Peer-Geräte, persönliche digitale Assistenten, andere gemeinsame Netzwerkknoten oder Ähnliches handeln, und sie können einige oder alle der oben in Bezug auf den Kontrollserver 122 beschriebenen Elemente enthalten. Beispielsweise und ohne Einschränkung könnte sich der Steuerserver 122 auf den entfernten Computern 128 als lokale Software ohne Netzwerk 126 befinden.
Zu den beispielhaften Computernetzwerken 126 können unter anderem lokale Netzwerke (LANs) und/oder Weitverkehrsnetzwerke bzw. Wide-Area-Netzwerke (WANs) gehören. Solche Netzwerkumgebungen sind in Büros, unternehmensweiten Computernetzwerken, Intranets und im Internet üblich. Beim Einsatz in einer WAN-Netzwerkumgebung kann der Steuerserver 122 ein Modem oder andere Mittel zur Herstellung der Kommunikation über das WAN, z. B. das Internet, enthalten. In einer vernetzten Umgebung können Programmmodule oder Teile davon in Verbindung mit dem Steuerserver 122, dem persistenten Speicher 124 oder einem der entfernten Computer 128 gespeichert werden. Beispielsweise können sich verschiedene Anwendungsprogramme im Speicher eines oder mehrerer entfernter Computer 128 befinden, ohne dass dies eine Einschränkung darstellt. Fachleute wissen, dass die gezeigten Netzwerkverbindungen beispielhaft sind und andere Mittel zur Herstellung einer Kommunikationsverbindung zwischen den Computern (z. B. dem Steuerserver 122 und den entfernten Computern 128) verwendet werden können.
Im Betrieb kann ein Kliniker Befehle und Informationen in den Steuerungsserver 122 eingeben oder die Befehle und Informationen über einen oder mehrere entfernte Computer 128 durch Eingabegeräte wie eine Tastatur, ein Zeigegerät (allgemein als Maus bezeichnet), einen Trackball oder ein Touchpad an den Steuerungsserver 122 übermitteln. Andere Eingabegeräte können unter anderem Mikrofone, Scanner oder Ähnliches sein. Befehle und Informationen können auch direkt von einem entfernten Gerät des Gesundheitswesens an den Kontroll-Server 122 gesendet werden. Neben einem Monitor können der Steuerserver 122 und/oder die entfernten Computer 128 auch andere periphere Ausgabegeräte wie Lautsprecher und einen Drucker umfassen.
Obwohl viele andere interne Komponenten des Steuerservers 122 und der dezentralen Computer 128 nicht abgebildet sind, werden Fachleute wissen, dass diese Komponenten und ihre Verbindung untereinander gut bekannt sind. Dementsprechend werden zusätzliche Details über den internen Aufbau des Steuerservers 122 und der dezentralen Computer 128 hier nicht weiter erläutert.
In 2 ist ein Blockdiagramm dargestellt, das ein Beispiel für eine Rechnersystemarchitektur zur Handhabung universeller Webdienste für DICOM-Objekte (Digital Imaging and Communications in Medicine) zeigt. Es wird deutlich, dass die in 2 gezeigte Computersystemarchitektur lediglich ein Beispiel für ein geeignetes Computersystem ist und keine Abhängigkeit oder Anforderung in Bezug auf ein einzelnes Modul/eine einzelne Komponente oder eine Kombination von Modulen/Komponenten darstellen soll.
Wie in 2 dargestellt, erzeugen SCU (client) 201₁-SCU (client) 201_N Webdienstanfragen 202, die an das medizinische Bildverwaltungssystem 203 gesendet werden. In einer Ausführungsform umfassen die SCU (client) 201₁-SCU (client) 201_N entfernte Web-Clients zum Betrachten, Abfragen oder Speichern medizinischer Bilder. Eine universelle Zugriffsmaschine(n) 210 arbeitet als Webdienstmaschine und empfängt Webdienstanfragen 202 von SCU (client) 201₁-SCU (client) 201_N. In einer Ausführungsform umfasst die Webdienstanfrage QIDO-RS-, WADO-RS-, STOW-RS- oder WADO-URI-Anfragen. Die Webdienstanfragen sind jedoch nicht auf diese Anfragen beschränkt, sondern können auch zukünftige, von NEMA, DICOM oder IHE genehmigte DICOM-Webdienste umfassen. In einer anderen Ausführungsform verwendet die Webdienstanfrage eine URL, die von der Zugriffsmaschine 210 entweder in eine DICOM-Webdienstanfrage (wie QIDO-RS) oder in eine DICOM-Nachrichtenanfrage (DIMSE) wie C-FIND umgewandelt werden kann. In einer weiteren Ausführungsform wird das Zugriffsmodul 210 als Anwendung auf der SCU/den Client-Geräten ausgeführt und eine Softwareschnittstelle verwendet, um Anfragen zu stellen, die vom Zugriffsmodul 210 entweder in eine DICOM-Webdienstanfrage oder eine DICOM-Nachrichtenanfrage (DIMSE) umgesetzt werden können. In diesem Fall ist der Dienst also ein lokaler Prozess, auf den ein medizinischer Bildgebungs-Client zugreifen kann, der als Vermittlungsstelle für Webdienste zu einem oder mehreren entfernten medizinischen Datensystemen wie einem PACS oder VNA fungiert, und diese Vermittlungsstelle stellt DICOM-Webanfragen aus, wenn sie von dem entfernten PACS/VNA unterstützt werden, und verwendet andernfalls DIMSE-Dienste wie oben beschrieben, wobei die Antwort in DICOM-Webdienstformate zur Verwendung durch den Client konvertiert wird.
In einer Ausführungsform bezieht sich die Webdienstanforderung 202 auf ein PACS 205, das keine DICOM-Webdienste unterstützt, oder DICOM-Webdienste auf eine Art und Weise unterstützt, die nicht dem Standard entspricht, oder auf eine Art und Weise unterstützt, die für die SCU 201 schwierig zu authentifizieren ist. Wenn eine dieser Bedingungen zutrifft, erzeugt die Universal Access Engine 210 als Reaktion auf den Empfang der Webdienstanforderung eine DIMSE-Dienstanforderung. In einer Ausführungsform umfasst die DIMSE-Dienstanforderung eine C-FIND-, C-GET-, C-MOVE- oder C-STORE-Operation. In einer Ausführungsform erzeugt die Universal Access Engine 210 eine DIMSE-Dienstanforderung auf der Grundlage einer in die Webdienstanforderung 202 eingebetteten Quell-PACS-Kennung 205. In einer Ausführungsform enthält die Webdienstanforderung 202 zusätzliche Informationen, die für eine DICOM C-FIND-, C-GET-, C-MOVE- oder C-STORE-Anforderung erforderlich sind, wie z. B. einen oder mehrere SCU AeTitle, Source PACS AeTitle, Source PACS Host und Port. In einer Ausführungsform wird die Webdienstanforderung 202 von der Zugriffsmaschine 210 geparst, um einen Webdiensttyp (z. B. QIDO-RS) zu identifizieren, einen DICOM-Client zu erstellen und den DICOM-Client eine DIMSE-Dienstanforderung basierend auf dem identifizierten Webdiensttyp ausgeben zu lassen. In einer Ausführungsform entspricht die erzeugte DIMSE-Dienstanforderung dem Standard, der das DICOM-Messaging für den Zugriff auf DICOM-Objekte spezifiziert. In einer Ausführungsform ist der Standard der NEMA DICOM PS3.1.
Das universelle Zugriffsmodul bzw. Universal Access Engine 210 sendet die DIMSE-Dienstanforderung 204 an ein Quell-PACS, einen DICOM-Server oder einen VNA, z. B. Quell-PACS/DICOM-Server 2051 - Quell-PACS/DICOM-Server 205N. Das Quell-PACS erzeugt eine Antwort auf die DIMSE-Dienstanforderung und sendet die Antwort an das Universal Access Engine 210. Das universelle Zugriffsmodul 210 formatiert die Antwort in ein Format um, das der entfernte Web-Client versteht, und gibt die umformatierte Antwort an den entfernten Web-Client zurück, z. B. SCU (client) 201₁-SCU (client) 201_N.
3 ist ein Blockdiagramm eines Teils einer Ausführungsform eines medizinischen Bildverwaltungssystems zur Bearbeitung von Webdienstanfragen, einschließlich einer Netzwerkschnittstelle 301 und einer universellen Zugriffsmaschine 302. In einer Ausführungsform umfasst das universelle Zugriffsmodul 302 einen oder mehrere Prozessoren oder andere Hardware (Schaltkreise, dedizierte Logik usw.), Software (z. B. Software, die auf einem Chip läuft), Firmware oder eine Kombination aus diesen drei Elementen.
Wie in dargestellt, wird eine Webdienstanforderung 311 von der Netzschnittstelle 301 von einem Web-Client empfangen. Die Webdienstanforderung 311 wird an die Universal Access Engine 302 gesendet, wo ein Parser 321 die Webdienstanforderung analysiert, um die Art der Anforderung zu bestimmen. Als Reaktion auf die Bestimmung des Anforderungstyps erzeugt der DICOM-Client-Generator 322 einen DICOM-SCU-Client. Es gibt Bibliotheken von Drittanbietern, wie z. B. MultiTech msiCOM3, die SCU-Client-Software zur Verfügung stellen können oder aus denen ein Fachmann seinen eigenen SCU-Client erstellen kann. Ebenfalls auf der Grundlage der Art der Webdienstanforderung erzeugt ein DIMSE-Anforderungsformer 323 eine DIMSE-Anforderung oder formt sie auf andere Weise. In einer Ausführungsform umfasst die DIMSE-Anforderung ein DICOM-Objekt für eine C-FIND-, C-GET-, C-MOVE- oder C-STORE-Operation. Nachdem der DIMSE-Anforderungserzeuger 323 ein DIMSE-Anforderungsobjekt erzeugt hat, stellt der DIMSE-Anforderungsaussteller 324 die DIMSE-Anforderung 312 aus. In einer Ausführungsform gibt der DIMSE-Anforderungsaussteller 324 die DIMSE-Anforderung 312 an die Netzwerkschnittstelle 301 aus, die die DIMSE-Anforderung 312 entgegennimmt und über ein Netzwerk (z. B. das Internet usw.) an den vom Parser 321 identifizierten PACS/DICOM/VNA-Server sendet.
Anschließend erzeugt der PACS/DICOM/VNA-Server, der die DIMSE-Anfrage erhalten hat, eine DIMSE-Antwort 313 auf die DIMSE-Anfrage 312, die von der Netzwerkschnittstelle 301 des medizinischen Bildverwaltungssystems empfangen wird. Die Antwort 313 auf die DIMSE-Anforderung wird an den Antwortgenerator 331 der Universal Access Engine 302 gesendet. Als Antwort auf die Antwort 313 konvertiert und/oder formatiert ein Konverter/Umformatierer 341 die Antwort 313 in ein Format, das mit der Webservice-Anforderung konform ist. Beispielsweise kann eine C-FIND-Antwort in application/dicom+xml oder application/dicom+json konvertiert werden, wie es im NEMA-Standard PS3.18 für QIDO-RS spezifiziert ist (ohne Einschränkung). Optional kann der Antwortgenerator 331 DICOM-Objekte für die Anzeige mit dem Renderer 342 rendern, wenn z. B. die Webdienstanforderung eine JPEG- oder PNG-Antwort erfordert. Optional kann der Antwortgenerator 331 Massendaten aus der DIMSE-Anforderungsantwort 313 mit Hilfe des Extraktors 343 extrahieren, um eine WADO-RS-Webdienstanforderung für Massendaten zu erfüllen. Optional kann der Antwortgenerator 331 DICOM-Header-Informationen konvertieren und mit Hilfe des Extraktors 343 eine Metadaten-Antwort erstellen, um eine WADO-RS-Metadaten-Webdienstanforderung zu erfüllen.
Optional kann die DIMSE-Antwort 313 oder Teile davon oder daraus gerenderte Elemente im Cache-Speicher unter Verwendung des Cache-Controllers 344 gespeichert werden. In einer Ausführungsform wird der Cache-Speicher anstelle des Client-Erstellers 322 verwendet, um auf medizinische Inhalte zuzugreifen, wenn die Webdienstanforderung 311 wiederholt wird.
Nach der Konvertierung/Umformatierung wird die Antwort auf die Webdienste an den Webdienst-Antwortgeber 345 gesendet, der die Webdienst-Antwort 314 an die Netzschnittstelle 301 ausgibt, die sie an den Web-Client sendet, der die Webdienst-Anfrage 311 ursprünglich erzeugt hat.
Die zeigen Beispiele für die Umwandlung von Webdienstanforderungen in DIMSE-Dienstanforderungen. In erzeugt die SCU 401, die ein Web-Client ist, eine QIDO-RS-Webdienstanforderung und sendet sie an eine universelle QIDO-RS-Engine 402, die sie in eine DIMSE-C-FIND-Anforderung umwandelt, die an den Quell-PACS 403 (einen DICOM-Server) gesendet wird. Als Antwort auf die DIMSE-C-FIND-Anforderung erzeugt das Quell-PACS 403 eine Antwort und sendet diese an die universelle QIDO-RS-Engine 402, die die Antwort umformatiert und als Antwort an die SCU 401 sendet.
Wie in dargestellt, erzeugt die SCU 411, bei der es sich um einen Web-Client handelt, eine WADO-RS-Webdienstanforderung und sendet sie an eine universelle WADO-RS-Engine 412, die sie in eine DIMSE-C-GET- oder C-MOVE-Anforderung umwandelt, die an den Quell-PACS 413 (einen DICOM-Server) gesendet wird. Als Antwort auf die DIMSE-C-GET- oder C-MOVE-Anforderung erzeugt das Quell-PACS 413 eine Antwort und sendet diese an die universelle WADO-RS-Engine 412, die die Antwort umformatiert und als Antwort an die SCU 411 sendet.
In erzeugt die SCU 421, die ein Web-Client ist, eine STOW-RS-Webdienstanforderung und sendet sie an eine universelle STOW-RS-Engine 422, die sie in eine C-STORE DIMSE-Anforderung umwandelt, die an das Quell-PACS 423 (einen DICOM-Server) gesendet wird. Als Antwort auf die C-STORE DIMSE-Anforderung erzeugt das Quell-PACS 423 eine Antwort und sendet diese an die universelle STOW-RS-Engine 422, die die Antwort umformatiert und als Antwort an die SCU 421 sendet.
Der NEMA-Standard für DICOM-Webdienste (PS3.18) spezifiziert die folgenden URL-Formate für spezifische Webserver-Anfragen zum Studium medizinischer Daten:

QIDO-RS: {SERVICE}/studies
WADO-RS: {SERVICE}/studies/{StudyInstanceUID}
STOW-RS: {SERVICE}/studies[/{StudylnstanceUID}]

http://myVna: 8080/wado-rs/MyCustomerDomain/studies

In einer Ausführungsform besteht ein neues Merkmal der hier beschriebenen universellen Zugriffsmaschine(n) darin, den Anwendungsnamen so zu erweitern, dass er alle für eine DICOM C-FIND/C-GET/C-MOVE/C-STORE-Anfrage erforderlichen Informationen enthält und gleichzeitig mit dem DICOM Web Service Standard konform ist.
In einer Ausführungsform sind die Aufrufe an die universelle(n) Zugriffsmaschine(n) {SERVICE} wie folgt definiert:

QIDO-RS URL:
- http://< UniversalServer> /qido-rs/cfind/<SCU AET> /<SCP AET>/<SCP Host>/<SCP Port>/<Dest AET>
WADO-RS URL:

http://< UniversalServer> /wado-rs/cmove/<SCU AET>/<SCP AET>/<SCP Host>/<SCP Port>/<Dest AET> oder
http://< UniversalServer> /wado-rs/cget/<SCU AET>/< SCP AET>/<SCP Host>/<SCP Port>
STOW-RS URL:
- http://< UniversalServer> /stow-rs/cstore/<SCU AET>/<SCP AET>/<SCP Host>/<SCP Port>

• eine http-Anfrage mit POST identifiziert STOW-RS.
• Wenn die http-Anfrage GET ohne {StudyInstanceUID} verwendet, dann wird angenommen, dass QIDO-RS
• Wenn die http-Anfrage GET verwendet und {StudyInstanceUID} vorhanden ist, dann wird angenommen, dass WADO-RS

Zum Beispiel die folgende http get-Anfrage ohne StudyInstanceUID
http://< UniversalServer>/<SCU AET>/<SCP AET>/<SCP Host>/<SCP Port>/<Dest AET> /Studien
ist für QIDO-RS, während die folgende URL mit einer StudyInstanceUID
http://< UniversalServer>/<SCU AET>/<SCP AET>/<SCP Host>/<SCP Port>/<Dest AET> /Studies/1.3.6.1.4.1.5962.1.3.1.1.1.20040826185059
ist für WADO-RS.
In den obigen Aufrufen sind cfind/cmove/cget/cstore optionale Tags, die es den Webdiensten ermöglichen, zwischen der traditionellen DICOM-Webdienstnutzung und dem universellen Remote-PACS-Zugriff umzuschalten. Zum Beispiel kann https://myServer/qidors/studies oder https://myServer/studies das myServer PACS mit QIDO-RS abfragen, während https://myServer/qido-rs/cfind/aeA/aeB/Pacs/aeC/studies oder https://myServer/cfind/aeA/aeB/Pacs/aeC/studies myServer nutzt, um eine C-FIND-Anfrage an ein entferntes PACS aeB zu stellen, wobei die Antwort für QIDO-RS umformatiert wird.
Wenn myServer kein PACS- oder VNA-Webserver ist oder DICOM-Webdienste für myServer PACS nicht erforderlich oder erwünscht sind, können die cfind/cmove/cstore-Tags weggelassen werden, und eine Abfrage könnte wie folgt aussehen
http://myServer/aeA/aeB/Pacs/aeC/studies (ohne Angabe der Dienstkennung),
oder
http://myServer/qido-rs/aeA/aeB/Pacs/aeC/studies (mit Kennung des Dienstes).
In dieser Ausführungsform ist die Universal Access Engine lediglich ein Proxy für einen oder mehrere unabhängige Source PACS Server.
In den obigen Aufrufen ist <SCU AET> der aufrufende AeTitle der SCU. Dieser kann für die Autorisierung von DICOM-Anfragen verwendet werden und wird möglicherweise von einem entfernten PACS benötigt.
In den obigen Aufrufen ist <SCP AET> der aufgerufene AeTitle des entfernten PACS, <SCP Host> ist der Rechnername des entfernten PACS und <SCP Port> ist der DICOM-Port für das entfernte PACS. Synapse® PACS verwendet z. B. standardmäßig Port 104 für DIMSE-Anfragen.
In den obigen Aufrufen ist <Dest AET> die von C-MOVE verwendete Return- bzw. Rücksprungadresse AeTitle. In einer Ausführungsform muss dies auf dem entfernten PACS konfiguriert werden, um angeforderte Inhalte an den Universal Web Service zurückzuspeichern (C-STORE). Beachten Sie, dass <Dest AET> für QIDO-RS mit C-FIND nicht unbedingt erforderlich ist. Es wird hier aus Gründen der Übersichtlichkeit eingefügt, da eine ordnungsgemäße QIDO-RS-Antwort eine WADO-RS-URL für den Zugriff auf jede durch die Abfrage gefundene DICOM-Instanz enthalten sollte. Mit der Aufnahme von <Dest AET> verfügt diese QIDO-RS über alle Informationen, die zum Aufbau einer WADO-RS-URL benötigt werden, die C-MOVE unterstützt. Wenn das universelle WADO-RS C-GET anstelle von C-MOVE verwendet, ist <Dest AET> in der URL nicht erforderlich.
QIDO-RS Arbeitsablauf
In einer Ausführungsform beginnt der QIDO-RS-Workflow, nachdem eine QIDO-RS-Anfrage von einem entfernten Web-Client gestellt wurde. Wenn die hier beschriebene universelle Web-Service-Engine eine QIDO-RS-Anfrage empfängt oder beim Parsen der Parameter nach {SERVICE} in der Anfrage erkennt, dass es sich um eine QIDO-RS-Anfrage handelt, erstellt die universelle Web-Service-Engine einen internen DICOM-SCU-Client, der eine C-FIND-Anfrage an den <SCP-Host> am <SCP-Port> unter Verwendung der bereitgestellten AeTitles <SCU AET> und <SCP AET> stellt. Anschließend erzeugt der SCP-Host (z. B. PACS, VNA-Server usw.) eine C-FIND-Antwort und sendet sie zurück. Die universelle Web-Service-Engine konvertiert die C-FIND-Antwort in DICOM+XML oder DCIOM+JSON, wie durch den/die Akzeptanztyp(en) der ursprünglichen Web-Anfrage und den NEMA-DICOM-Web-Service-Standard festgelegt. In einer Ausführungsform ist DICMO-XML der Standard des NEMA-Standards PS3.18, wenn kein Akzeptanztyp angegeben ist. Optional kann die universelle Web-Service-Engine in einer Ausführungsform auch die Antwort (formatiert, natives DICOM oder benutzerdefiniert) zwischenspeichern, um bei wiederholten Anfragen nach denselben DICOM-Objekten in der Zukunft schneller reagieren zu können. Die universelle Web-Service-Engine sendet die neu formatierte C-FIND-Antwort an den entfernten Web-Client zurück. In einer Ausführungsform wird die QIDO-RS-Antwort in Stapeln zusammengefasst, bis alle C-FIND-Nachrichten empfangen und in einer HTTP-Antwort mit bekannter Größe zurückgesendet sind. In einer anderen Ausführungsform wird die Antwort gestreamt, wobei nach dem Empfang jeder C-FIND-Nachricht ein QIDO-RS-formatiertes (DICMO-XML oder DICMO-JSON) Datenpaket zurückgegeben wird.
5 ist ein Flussdiagramm einer Ausführungsform eines Prozesses zur Bearbeitung einer QIDO-RS-Anfrage. In einer Ausführungsform wird der Prozess von einer Verarbeitungslogik durchgeführt, die aus Hardware (Schaltkreisen, dedizierter Logik usw.), Software (z. B. Software, die auf einem Chip läuft), Firmware oder einer Kombination aus diesen drei Elementen bestehen kann. In einer Ausführungsform wird der Prozess von einer medizinischen Bildverwaltungsplattform durchgeführt, wie zum Beispiel, aber nicht beschränkt auf, die oben in Verbindung mit den 2 und 3 beschriebenen medizinischen Bildverwaltungsplattformen.
Wie in 5 dargestellt, beginnt der Prozess damit, dass die Verarbeitungslogik eine QIDO-RS-Anfrage empfängt (Verarbeitungsblock 501). Als Reaktion auf den Empfang der QIDO-RS-Anforderung erkennt die Verarbeitungslogik, dass es sich bei der Anforderung um eine QIDO-RS-Anforderung handelt (Verarbeitungsblock 502). In einer Ausführungsform erkennt die Verarbeitungslogik die Anforderung als QIDO-RS-Anforderung, indem sie die QIDO-RS-Anforderung analysiert, um einen Dienstidentifikator zu finden. Dieses Parsing kann innerhalb und nach dem {SERVICE}-Teil der QIDO-RS-URL-Anfrage erfolgen.
Nachdem die Anforderung als QIDO-RS-Anforderung erkannt wurde, erstellt die Verarbeitungslogik einen internen DICOM-SCU-Client (Verarbeitungsblock 503) unter Verwendung von DICOM-Bibliotheken Dritter oder kundenspezifischer Software. Solche Clients sind in der Fachwelt wohlbekannt und im DICOM-Standard PS3.18 spezifiziert.
Nach der Erstellung des DICOM SCU-Clients stellt dieser eine C-FIND-Anfrage an den PACS/VNA/DICOM-Server (z. B. SCP-Host), der durch die ursprüngliche QIDO-RS-Webdienstanfrage identifiziert wurde (Verarbeitungsblock 504).
Anschließend empfängt die Verarbeitungslogik eine C-FIND-Antwort (Verarbeitungsblock 511) und konvertiert die C-FIND-Antwort in andere Formate wie z. B. den NEMA-Standard PS3.18 DICOM+XML oder DICOM+JSON (Verarbeitungsblock 512). Für die Rückgabe der Ergebnisse können auch andere Schemata wie JSON, XML oder andere Formate verwendet werden. Ob die C-FIND-Antwort in DICOM+XML oder DICOM+JSON konvertiert wird, hängt von der Angabe der Akzeptanztypen in der ursprünglichen HTTP/HTTPS-Anfrage ab.
Die Verarbeitungslogik speichert optional auch die C-FIND-Antwort im Cache (Verarbeitungsblock 513). Die Verarbeitungslogik sendet die umformatierte C-FIND-Antwort an den entfernten Web-Client (Verarbeitungsblock 514). In einer Ausführungsform kann das Senden der umformatierten C-FIND-Antwort darin bestehen, die Antwort zu stapeln, bis alle C-FIND-Nachrichten empfangen wurden, und sie als eine Antwort mit bekannter Größe zurückzusenden. In einer anderen Ausführungsform umfasst das Senden der umformatierten C-FIND-Antwort das Streaming der QIDO-RS-Antwort, wobei nach jeder C-FIND-Nachricht ein formatiertes Datenpaket (z. B. DICOM+XML oder DICOM+JSON) zurückgegeben wird.
WADO-RS mit C-GET Arbeitsablauf
In einer Ausführungsform beginnt der WADO-RS mit C-GET-Workflow, nachdem eine WADO-RS-Anfrage von einem entfernten Web-Client gestellt wurde. Wenn die hier beschriebene universelle Web-Service-Engine eine WADO-RS-Anfrage empfängt oder beim Parsen der Parameter nach {SERVICE} in der WADO-RS-Anfrage erkennt, dass es sich um eine WADO-RS-Anfrage handelt, erstellt die universelle Web-Service-Engine einen internen DICOM-SCU-Client, der eine C-GET-Anfrage an den <SCP-Host> am <SCP-Port> unter Verwendung der bereitgestellten AeTitles <SCU AET> und <SCP AET> stellt.
Anschließend erzeugt der SCP-Host (z. B. PACS, VNA-Server usw.) eine C-GET-Antwort und sendet sie zurück. Mit der C-GET-Antwort konvertiert die universelle Web-Service-Engine jedes DICOM-Objekt in eine andere Übertragungssyntax, wenn dies durch den/die Akzeptanztyp(en) der ursprünglichen Web-Anfrage vorgegeben ist. Der DICOM-Webdienst-Standard legt beispielsweise fest, dass der folgende URL-Parameter verwendet werden kann, um medizinische DICOM-Bilder anzufordern, die mit der verlustbehafteten bzw. Lossy JPEG-2000-Kompression kodiert sind:

accept=multipart/related;type=„application/octet-stream;transfersyntax=1.2.840.10008.1.2.4.91“

In einer alternativen Ausführungsform wird die gewünschte Übertragungssyntax in die C-GET-Anforderung aufgenommen, wenn sie vom entfernten PACS unterstützt wird. In einer Ausführungsform extrahiert die universelle Webservice-Engine die angeforderten Bilder, wenn die ursprüngliche URL in der Webservice-Anforderung eine Bilderliste gemäß NEMA-Standard PS3.18 enthält. In einer alternativen Ausführungsform werden die gewünschten Bildnummern in die C-GET-Anfrage aufgenommen, sofern das entfernte PACS sie unterstützt.
In einer Ausführungsform rendert die universelle Webservice-Engine jedes DICOM-Objekt zur Anzeige, wenn es durch die ursprüngliche URL gemäß NEMA-Standard PS3.18 in der ursprünglichen Webservice-Anfrage des Webclients angefordert wird. Zum Beispiel und ohne Einschränkung: http://{SERVICE}/studies/999.083000/series/999.083000.5/instances/999. 083000.5.104/rendered?accept=image/jpeg
In einer Ausführungsform extrahiert die universelle Web-Service-Engine Bulk-Daten, wenn diese von der ursprünglichen Web-Anfrage des Web-Clients angefordert werden, wie in DICOM Web Services PS3.18 6.1.1.8 und 6.5.1.2.2 beschrieben.
In einer Ausführungsform extrahiert die universelle Web-Service-Engine DICOM-Header-Informationen und erstellt eine Metadaten-Antwort in DICOM+XML oder DICOM+JSON oder einem anderen Format, das durch den/die Akzeptanztyp(en) der Web-Anfrage gefordert wird. Beispiel und ohne Einschränkung: http://{SERVICE}/studies/999.083000/metadata
In einer Ausführungsform speichert die universelle Web-Service-Engine die DICOM-Objekte oder gerenderten DICOM-Bilder im Zwischenspeicher, um bei wiederholten Anfragen nach denselben Gesundheitsinhalten schneller reagieren zu können.
In einer Ausführungsform verpackt die universelle Web-Service-Engine jedes neu formatierte Antwort-Element, das zurückgegeben werden soll, in einen HTML-Textteil gemäß dem NEMA-Standard PS3.18 und sendet diese Antwort an den entfernten Client zurück. In einer Ausführungsform fasst die universelle Web-Service-Engine die C-GET-Antworten zusammen und sendet die gesamte umformatierte WADO-RS-Antwort als einen Body bzw. Körper bekannter Größe zurück. In einer alternativen Ausführungsform wird jedes neu formatierte Antwortobjekt (z. B. DICOM-Objekt, gerendertes Bild oder Frame, Massendatenelement, Metadaten) als Chunking oder Streaming an den entfernten Client zurückgesendet, wenn C-GET-Antwortobjekte empfangen und verarbeitet werden.
ist ein Flussdiagramm einer Ausführungsform eines Prozesses zur Bearbeitung einer WADO-RS-Webdienstanfrage mit C-GET. In einer Ausführungsform wird der Prozess von einer Verarbeitungslogik durchgeführt, die Hardware (Schaltkreise, dedizierte Logik usw.), Software (z. B. Software, die auf einem Chip läuft), Firmware oder eine Kombination aus diesen drei Elementen umfassen kann. In einer Ausführungsform wird der Prozess von einer medizinischen Bildverwaltungsplattform durchgeführt, wie zum Beispiel, aber nicht beschränkt auf, die oben in Verbindung mit den 2 und 3 beschriebenen medizinischen Bildverwaltungsplattformen.
Wie in dargestellt, beginnt der Prozess damit, dass die Verarbeitungslogik eine WADO-RS-Anfrage empfängt (Verarbeitungsblock 601). In einer Ausführungsform wird die WADO-Anfrage von einer Universal Access (Web Service) Engine empfangen. Als Reaktion auf die WADO-RS-Anforderung erkennt die Verarbeitungslogik (Verarbeitungsblock 602), dass es sich um eine WADO-RS-Anforderung handelt. In einer Ausführungsform erkennt die Verarbeitungslogik, dass es sich bei der Anforderung um WADO-RS handelt, indem sie die WADO-RS-Anforderung nach einer Webdienst-Kennung analysiert. In einer Ausführungsform wird der Webdienst durch Parsing nach {Service} identifiziert. Als Reaktion auf die Erkennung, dass es sich bei der Anfrage um WADO-RS handelt, erstellt die Verarbeitungslogik einen internen DICOM-SCU-Client 603 und stellt eine C-GET-Anfrage (Verarbeitungsblock 604), die an den in der ursprünglichen WADO-RS-Webdienstanfrage identifizierten PACS/VNA/DICOM-Server (z. B. SCP-Host) gesendet wird.
Anschließend empfängt die Verarbeitungslogik eine C-GET-Antwort von einem PACS-, VNA- oder DICOM-Server (Verarbeitungsblock 611). Als Reaktion auf die C-GET-Antwort kann die Verarbeitungslogik eine Reihe von Operationen durchführen. In einer Ausführungsform konvertiert die Verarbeitungslogik jedes DICOM-Objekt in eine andere Übertragungssyntax (optional) (Verarbeitungsblock 612). In einer Ausführungsform können die angeforderten Bilder als Teil des Konvertierungsprozesses extrahiert werden, wenn die ursprüngliche URL eine Rahmenliste gemäß NEMA-Standard PS3.18 spezifiziert hat (Verarbeitungsblock 613). In einer Ausführungsform rendert die Verarbeitungslogik jedes DICOM-Bild oder jeden Rahmen für die Anzeige (z. B. JPEG, PNG), wenn dies von der ursprünglichen Web-Anfrage gemäß einem Standard (z. B. dem NEMA-Standard PS3.18) verlangt wird (Verarbeitungsblock 614). In einer Ausführungsform extrahiert die Verarbeitungslogik Massendaten, wenn sie von der ursprünglichen URL gemäß einem Standard (z. B. dem NEMA-Standard PS3.18) angefordert werden (Verarbeitungsblock 615). In einer Ausführungsform extrahiert die Verarbeitungslogik DICOM-Header-Informationen von jedem DICOM-Objekt und erstellt eine Metadaten-Antwort in DICOM+XML oder DICOM+JSON oder einem anderen Format, das durch den/die Akzeptanztyp(en) der Web-Anfrage gefordert wird. In einer weiteren alternativen Ausführungsform speichert die Verarbeitungslogik DICOM-Objekte oder gerenderte Bilder im Cache (optional) (Verarbeitungsblock 616). Zwischengespeicherte Inhalte ermöglichen eine schnellere Antwort bei wiederholten Anfragen nach denselben medizinischen Daten.
Die Verarbeitungslogik formatiert die C-GET-Antwort um (Verarbeitungsblock 617), damit sie dem WADO-RS-Antwortformat entspricht. In einer Ausführungsform umhüllt die Verarbeitungslogik jedes Antwortelement (DICOM-Objekte, Frames, gerenderte Anzeigen, Bulk-Daten, Metadaten) mit einem HTML-Körperteil, wie er von einem Standard (z. B. dem NEMA-Standard PS3.18) vorgegeben wird. Anschließend sendet die Verarbeitungslogik die umformatierte C-GET-Antwort an den Web-Client, der ursprünglich die WADO-RS-Anfrage gesendet hat (Verarbeitungsblock 618). In einer Ausführungsform könnte die Antwort in Stapeln zusammengefasst und als ein HTML-Objekt bekannter Größe zurückgegeben werden. In einer anderen Ausführungsform wird die Antwort als Chunking oder Streaming gesendet, sobald Antwort-Elemente verfügbar werden.
WADO-RS mit C-MOVE
In einer Ausführungsform beginnt der Arbeitsablauf von WADO-RS mit C-MOVE, nachdem eine WADO-RS-Anforderung von einem entfernten Web-Client (z. B. SCU) ausgegeben wurde. Wenn die hier beschriebene universelle Web-Service-Engine eine WADO-RS-Anfrage empfängt oder beim Parsen der Parameter nach {SERVICE} in der WADO-RS-Anfrage erkennt, dass es sich um eine WADO-RS-Anfrage handelt, erstellt die universelle Web-Service-Engine einen internen DICOM SCU-Client, der eine C-MOVE-Anfrage an den <SCP-Host> am <SCP-Port> eine C-MOVE-Anfrage unter Verwendung der angegebenen AeTitles <SCU AET> , <SCP AET> und <DEST AET> stellt, und die C-MOVE-Anfrage wird an den SCP-Host gesendet.
Anschließend erzeugt der SCP-Host (z. B. PACS, VNA, Server usw.) eine C-MOVE-Antwort und sendet sie zurück. Mit der C-MOVE-Antwort stellt die universelle Web-Service-Engine in einer Ausführungsform einen internen DICOM-SCP bereit, um die C-STORE-Antwort vom C-MOVE zu verarbeiten. Die C-STORE DICOM-Objekte können sofort wie unten beschrieben verarbeitet werden. Nach der Verarbeitung können die C-STORE-DICOM-Objekte zwischengespeichert oder verworfen werden.
In einer Ausführungsform wandelt die universelle Web-Service-Engine jedes C-STORE-DICOM-Objekt in eine andere Übertragungssyntax um, wenn dies durch den/die Akzeptanztyp(en) der anfänglichen Web-Anfrage, wie hier mit dem C-GET-Workflow beschrieben, festgelegt ist. In einer alternativen Ausführungsform wird die angeforderte Übertragungssyntax in der C-MOVE-Anforderung angegeben, wenn sie vom entfernten PACS unterstützt wird. In einer Ausführungsform extrahiert die universelle Web-Service-Engine die angeforderten Bilder aus den C-STORE-DICOM-Objekten, wenn die ursprüngliche URL in der Web-Service-Anfrage eine Bildliste gemäß NEMA-Standard PS3.18 enthält. In einer alternativen Ausführungsform werden die angeforderten Bilder in der C-MOVE-Anforderung angegeben, sofern sie vom entfernten PACS unterstützt werden.
In einer Ausführungsform rendert die universelle Web-Service-Engine jedes C-STORE-DICOM-Objekt für die Anzeige, wenn es von der ursprünglichen Web-Anfrage angefordert wird, gemäß dem NEMA-Standard PS3.18 und wie hier unter dem C-GET-Workflow beschrieben. In einer Ausführungsform extrahiert die universelle Webservice-Engine gemäß NEMA-Standard PS3.18 Massendaten, wenn diese von der ursprünglichen URL der Webanforderung angefordert werden. In einer Ausführungsform extrahiert die universelle Web-Service-Engine DICOM-Header-Informationen von jedem DICOM-Objekt und erstellt eine Metadaten-Antwort in DICOM+XML oder DICOM+JSON oder einem anderen Format, das durch den/die Akzeptanztyp(en) der Web-Anfrage gefordert wird. In einer Ausführungsform speichert die universelle Web-Service-Engine die DICOM-Objekte oder gerenderten Bilder in einem Zwischenspeicher, um bei wiederholten Anfragen nach denselben Gesundheitsinhalten schneller reagieren zu können.
In einer Ausführungsform verpackt die universelle Web-Service-Engine jedes Antwort-Element in bzw. als einen HTML-Teil, wie er im NEMA-Standard PS3.18 spezifiziert und hier unter C-GET-Workflow beschrieben ist. Die neu formatierte C-MOVE-Antwort wird als WADO-RS-Antwort an den entfernten Client gesendet. In einer Ausführungsform stapelt die universelle Webservice-Engine die gesamte C-MOVE-Antwort und sendet sie als ein Html-Objekt mit bekannter Größe zurück. In einer anderen Ausführungsform wird die Antwort in Chunks zerlegt oder gestreamt, wenn DICOM-Objekte verarbeitet werden und Antwort-Elemente in ähnlicher Weise wie der oben beschriebene C-GET-Workflow verfügbar werden.
7 ist ein Flussdiagramm einer Ausführungsform eines Prozesses zur Bearbeitung einer WADO-RS-Webdienstanfrage mit C-MOVE. In einer Ausführungsform wird der Prozess von einer Verarbeitungslogik durchgeführt, die Hardware (Schaltkreise, dedizierte Logik usw.), Software (z. B. Software, die auf einem Chip läuft), Firmware oder eine Kombination aus diesen drei Elementen umfassen kann. In einer Ausführungsform wird der Prozess von einer medizinischen Bildverwaltungsplattform durchgeführt, wie zum Beispiel, aber nicht beschränkt auf, die oben in Verbindung mit den 2 und 3 beschriebenen medizinischen Bildverwaltungsplattformen.
Wie in 7 dargestellt, beginnt der Prozess damit, dass die Verarbeitungslogik eine WADO-RS-Anfrage empfängt (Verarbeitungsblock 701). In einer Ausführungsform wird die WADO-Anfrage von einer Universal Access (Web Service) Engine empfangen. Als Reaktion auf die WADO-RS-Anforderung erkennt die Verarbeitungslogik, dass es sich um eine WADO-RS-Anforderung handelt (Verarbeitungsblock 702). In einer Ausführungsform erkennt die Verarbeitungslogik, dass es sich bei der Anforderung um WADO-RS handelt, indem sie den {Service}-Teil der URL analysiert. In einer Ausführungsform umfasst das Parsen der Diensterkennung auch die URL nach {Service}. Als Reaktion auf die Erkennung, dass es sich bei der Anforderung um WADO-RS handelt, erstellt die Verarbeitungslogik einen internen DICOM SCU-Client 703 und stellt eine C-MOVE-Anforderung (Verarbeitungsblock 704) aus, die an den PACS/VNA/DICOM-Server (z. B. SCP-Host) gesendet wird, der durch die ursprüngliche WADO-RS-Anforderung {Service} identifiziert wurde.
Anschließend verarbeitet die Verarbeitungslogik eine C-STORE-Anforderung vom SCP-Host als Antwort auf die C-MOVE-Anforderung (Verarbeitungsblock 711). In einer Ausführungsform empfängt ein DICOM-SCP-Client innerhalb der Verarbeitungslogik jede C-STORE-Antwort zur weiteren Verarbeitung. Ein SCP-Client kann mit Hilfe von DICOM-Bibliotheken von Drittanbietern erstellt oder in Software gemäß den Spezifikationen des DICOM-Standards PS3.1 eingebaut werden. In einer Ausführungsform speichert die Verarbeitungslogik auch die als Teil der C-STORE-Antwort empfangenen DICOM-Objekte im Cache (optional) (Verarbeitungsblock 713). Die Verarbeitungslogik erhält eine C-MOVE-Antwort, die den Abschluss aller gesendeten C-STORE-Objekte anzeigt (Verarbeitungsblock 712). In einer alternativen Ausführungsform kann ein externer SCP-Client oder ein PACS oder VNA die C-STORE-DICOM-Objekte empfangen und speichern/zwischenspeichern. In diesem Fall erhält die Verarbeitungslogik nach Erhalt der C-MOVE-Abschlussantwort die von WADO-RS angeforderten DICOM-Objekte durch Zugriff auf das externe SCP-PACS (über DIMSE oder Webdienste) oder den externen SCP-Speicher oder den externen SCP-Cache oder die externe SCP-Datenbank.
Die Verarbeitungslogik formatiert die empfangenen DICOM-Objekte neu bzw um (Verarbeitungsblock 714) und sendet die neu formatierte bzw. umformatierte Antwort an den Web-Client, der ursprünglich die WADO-RS-Webdienstanforderung generiert hat (Verarbeitungsblock 715).
WADO-URI ARBEITSABLAUF
In einer Ausführungsform wird der Arbeitsablauf für eine WADO-URI-Webanforderung auf die gleiche Weise implementiert wie der Arbeitsablauf für WADO-RS mit C-GET oder C-MOVE (siehe oben) mit drei Änderungen. Erstens gibt es nur ein DICOM-Objekt oder einen Frame pro URL-Antwort. Zweitens besteht die Web-Antwort aus dem gesamten HTML-Text. In einer Ausführungsform werden bei WADO-URI keine mehrteiligen Body-Grenzen verwendet. Drittens unterstützt WADO-URI keine Massendatenanforderungen für Elemente des DICOM-Headers.
STOW-RS ARBEITSABLAUF
In einer Ausführungsform beginnt der STOW-RS-Workflow, nachdem eine STOW-RS-Anfrage von einem entfernten Web-Client gestellt wurde. Wenn die hier beschriebene universelle Web-Service-Engine eine STOW-RS-Anfrage empfängt oder beim Parsen der Parameter nach {SERVICE} in der WADO-RS-Anfrage erkennt, dass es sich um eine WADO-RS-Anfrage handelt, erstellt die universelle Web-Service-Engine einen internen DICOM-SCU-Client, der jede DICOM-Instanz aus dem STOW-Body-Eingang in ein für C-STORE geeignetes DICOM-Objekt umwandelt und eine C-STORE-Anfrage an den <SCP-Host> am <SCP-Port> unter Verwendung der bereitgestellten AeTitles <SCU AET> und <SCP AET>. Je nach der ausgehandelten DICOM-Übertragungssyntax kann es erforderlich sein, die Übertragungssyntax der DICOM-Objekte in ein Format zu konvertieren, das von dem entfernten PACS unterstützt wird. Die universelle Web-Service-Engine sendet jedes DICOM-Objekt mit DIMSE C-STORE an den entfernten PACS/VNA/DICOM-Server (z. B. SCP-Host).
Anschließend generiert der SCP-Host (z. B. PACS, VNA, Server usw.) eine DIMSE-Antwort, die den Erfolg oder Misserfolg der Speicheranfrage anzeigt, und sendet sie zurück. Die universelle Webservice-Engine antwortet dem Web-Client mit dem C-STORE-Status, der gemäß dem NEMA-Standard PS3.18 6.6.1.3.2 „Response Message Body“ in einen STOW-Status umgewandelt wird.
8 zeigt eine Ausführungsform eines Prozesses bzw. Verfahrens zur Bearbeitung einer STOW-RS-Webdienstanfrage. In einer Ausführungsform wird der Prozess von einer Verarbeitungslogik durchgeführt, die aus Hardware (Schaltungen, dedizierter Logik usw.), Software (z. B. Software, die auf einem Chip läuft), Firmware oder einer Kombination aus diesen drei Elementen bestehen kann. In einer Ausführungsform wird der Prozess von einer medizinischen Bildverwaltungsplattform durchgeführt, wie zum Beispiel, aber nicht beschränkt auf, die oben in Verbindung mit den 2 und 3 beschriebenen medizinischen Bildverwaltungsplattformen.
Wie in 8 dargestellt, beginnt der Prozess damit, dass die Verarbeitungslogik eine STOW-RS-Anforderung empfängt (Verarbeitungsblock 801). Als Reaktion auf den Empfang der STOW-RS-Anforderung erkennt die Verarbeitungslogik, dass es sich um eine STOW-RS-Anforderung handelt (Verarbeitungsblock 802). In einer Ausführungsform erkennt die Verarbeitungslogik, dass es sich bei der Anforderung um eine STOW-RS handelt, indem sie die STOW-RS {SERVICE} nach einer Dienstkennung analysiert. In einer Ausführungsform parst die Verarbeitungslogik auch die Parameter nach {SERVICE}.
Als Reaktion auf die Erkennung der Anforderung als STOW-RS erstellt die Verarbeitungslogik einen internen DICOM-SCU-Client (Verarbeitungslogik 803) und konvertiert jede DICOM-Instanz aus dem STOW-Body-Eingang in ein für die C-STORE-Operation geeignetes DICOM-Objekt (Verarbeitungsblock 804). In einer Ausführungsform werden beispielsweise DICOM-Kopfdaten im DICOM+XML- oder DICOM+JSON-Format in DICOM-Elemente umgewandelt, Bulk- oder Binärinhalte, die STOW-RS als Metadaten-Link identifiziert, werden mit einem STOW-RS-Body-Teil, der die Bulk-Daten enthält, abgeglichen und durch diesen ersetzt, und referenzierte Bulk-Daten, die nicht in der STOW-RS-Anfrage enthalten sind, werden durch eine Verarbeitungslogik erfasst, die eine separate Web-Anfrage für die Bulk-Daten unter Verwendung des von STOW-RS bereitgestellten URL-Links stellt. In einer Ausführungsform kann die Verarbeitungslogik, abhängig von der ausgehandelten DICOM-Übertragungssyntax, die Übertragungssyntax der DICOM-Objekte in ein vom entfernten PACS/VNA/DICOM-Server unterstütztes Format konvertieren. Danach stellt die Verarbeitungslogik für jedes erfolgreich zusammengestellte und formatierte DICOM-Objekt eine C-STORE-Anforderung an den PACS/VNA/DICOM-Server (z. B. SCP-Host), der durch die ursprüngliche STOW-RS-Webdienstanforderung identifiziert wurde (Verarbeitungsblock 805).
Anschließend sendet die Verarbeitungslogik eine C-STORE-Statusantwort (Verarbeitungsblock 811). Als Reaktion auf den Empfang der C-STORE-Statusantwort wandelt die Verarbeitungslogik den C-STORE-Status in den STOW-RS-Status um (Verarbeitungsblock 812) und sendet die Antwort mit dem STOW-RS-Status an den Web-Client (Verarbeitungsblock 813).
Der oben beschriebene Arbeitsablauf kann in einer Reihe von Situationen sinnvoll eingesetzt werden. Bei der Entwicklung einer herstellerneutralen DICOM-Anwendung, die DICOM-Inhalte von mehreren PACS abfragt und anzeigt, kann beispielsweise WADO-RS/QIDO-RS mit einfachen Authentifizierungsschemata wie Windows User ID für den Zugriff auf PACS-Anbieter verwendet werden. Ohne die hier beschriebene universelle Zugriffs-Engine könnten einige PACS von Anbietern nicht durch vom Client ausgegebene DICOM-Webdienste unterstützt werden. Zum Beispiel ein vendor_1, der nicht vollständig PS3.18-konform ist und benutzerdefinierte Felder oder Header in der Webanfrage oder eine benutzerdefinierte Formatierung der Antworten erfordert. Ein weiteres Beispiel ist ein Vendor_2 mit einer benutzerdefinierten Webdienst-Authentifizierung wie einem SSO-Cookie-Token, der über ein webbasiertes Formular mit manueller Eingabe von Benutzernamen und Passwort erstellt wird. Die gewünschte DICOM-Anwendung wäre nicht universell oder herstellerneutral, wenn Code für herstellerspezifische Formate oder Authentifizierungssysteme hinzugefügt wird. Darüber hinaus könnte es sein, dass Vendor_3 noch keine DICOM-Webdienste unterstützt und stattdessen auf den älteren DIMSE-DICOM-Nachrichtenverkehr setzt.
Mit der Universal Web Service Software kann die DICOM-Anwendung auf Vendor_1, Vendor_2 und Vendor_3 zugreifen, indem sie WADO-RS/QIDO-RS mit der Universal Web Service Software verbindet. Zum Beispiel:

{Vendor_1 SERVICE} = http://universalHost/myScuAET/Vendor1AET/Vendor1Host/105

Unter Verwendung der hier beschriebenen Arbeitsabläufe kann die DICOM-Anwendung mit den Vendors_1, _2 und _3 interagieren, indem sie nur WADO-RS und QIDO-RS innerhalb der Anwendung verwendet.
Alternative Schema-Varianten
Es gibt eine Reihe von Alternativen für das oben vorgestellte URL-Schema. In einer Ausführungsform bestimmt die universelle Web-Service-Engine einen oder mehrere Parameter für die DIMSE-Anfrage, indem sie diese Parameter aus dem Speicher abruft, wobei sie die ein oder mehreren Daten in der ursprünglichen Web-Anfrage verwendet. Das eine oder die mehreren Daten umfassen beispielsweise einen Quellennamen in der Webdienstanforderung, wobei dies keine Einschränkung darstellt. Die universelle Web-Service-Engine führt eine Suche im Speicher (z. B. in einer Nachschlagetabelle) unter Verwendung des Quellennamens durch, um den DICOM-Server, den Port und die AeTitles für die DIMSE-Anfrage zu erhalten. Andere Arten von Informationen können auf der Grundlage von Daten in den Webdienstanforderungen aus dem Speicher abgerufen werden. So kann die Abfrage des Quellennamens beispielsweise anzeigen, dass das Quell-PACS jetzt DICOM-Webdienste-konform ist und mit QIDO-RS und WADO-RS direkt angesprochen werden kann. In diesem Fall liefert die Suche einen alternativen {SERVICE2}-Wert für den Anbieter, und die Verarbeitungslogik ersetzt den ursprünglichen {SERVICE} durch {SERVICE2}, stellt dann eine neue Webanforderung mit der geänderten URL und dem ursprünglichen http-Accept-Wert (falls vorhanden) und sendet die Webantwort des Anbieters direkt an den ursprünglichen Client zurück.
In einer Ausführungsform verwendet ein universeller DICOM-Webdienst einen Quellennamen und eine Nachschlagetabelle, um das entfernte PACS und die entfernten Verbindungsparameter zu identifizieren.
protocol://webhost[:port]/[serviceName]/sourceName/{NEMA PS3.18 Parameter}
z. B., GET http://myHost:1000/sourcel/studies
Die Verarbeitungslogik stellt fest, dass es sich um eine QIDO-RS-Anfrage für Vendor Sourcel handelt, die nicht PS3.18-konform ist, und ermittelt die DIMSE-Parameter für eine C-FIND-Anfrage an den Lieferanten über die Datenabfrage auf Source1.

sourceName host port calledAeTitle callingAeTitle

sourcel Host1 105 AeT1 myAeT
Beachten Sie, dass in einer Ausführungsform die Namen der nachgeschlagenen Spalten bzw. Nachschlagespalten beliebig sind. Die Eingabemethode und die Persistenz dieser Tabellendaten sind beliebig. In einer Ausführungsform könnten die DIMSE-Parameter beispielsweise aus einer formatierten Datei gelesen, aus einem Registrierungsschlüssel geladen, aus einer Datenbank gelesen, aus einer web.config gelesen oder in der universellen Zugriffsmaschine oder ihrer Anwendung hartkodiert werden.
Das obige Beispiel kann auf WADO-RS-Anfragen ausgedehnt werden, bei denen der C-MOVE-Workflow verwendet wird und ein Ziel-AeTitle erforderlich ist, wie z. B. unten gezeigt:

sourceName host port calledAeTitle callingAeTitle destAeTitle

sourcel Host1 105 AeT1 myAeT myDestAeT
Diese Beispiele können modifiziert werden, um Quellen zu identifizieren, die DICOM PS3.18-konform sind, und die Suchdaten liefern einen quellengenehmigten Benutzernamen und ein Kennwort für Webanfragen sowie {SERVICE}-Werte, die z. B. für Webdienstanfragen verwendet werden können, wie unten gezeigt:

sourceName userID password QIDO-RS-Basis WADO-RS-Basis

eFilm1 eID ePasswort http://eHost/qidoRS http://eHost/wadoRS
In einer weiteren alternativen Ausführungsform wird der Tabelle eine STOW-RS-Basis-URL hinzugefügt.
In einer weiteren alternativen Ausführungsform ersetzt eine WADO-URI-Basis die WADO-RS-Basis oder ist eine zusätzliche Tabellenspalte.
In einer weiteren alternativen Ausführungsform wird der Tabelle eine neue Spalte hinzugefügt und die quellenspezifische Zugriffsmethode (Webdienst oder DIMSE) wird durch den in die Tabelle eingegebenen Wert bestimmt. Diese Spalte ist optional, und die Zugriffsmethode könnte einer einfachen Logik folgen wie: Anwendung von DIMSE, wenn der Basiswert {SERVICE} für die Quellenabfrage nicht definiert ist.
In einer weiteren alternativen Ausführungsform wird der Quellenname in der URL durch einen eindeutigen Port ersetzt, der jeder konfigurierten Quelle zugewiesen wird. Zum Beispiel,
protocol://webhost:port/{NEMA-Norm PS3.18 parameter}
z.B., http://myHost: 1000/studies
mit einer der Variantennachschlagetabellen in verwandten Ansprüchen, bei denen der Anschluss als Nachschlageschlüssel anstelle des Quellennamens dient

inputPort host port calledAeTitle callingAeTitle

1000 aHost1 104 aAeT myAeT
In einer anderen Variante werden sowohl sourceName als auch inputPort zur Identifizierung des entfernten PACS/VNA/DICOM-Servers verwendet. Zum Beispiel, protocol://webhost:port/sourceName/{NEMA-Norm PS3.18 Parameter}
z.B. http://myHost:1000/a1/studies/
mit einer geänderten Tabelle oder einer der Variantentabellen, bei denen inputPort hinzugefügt wird

sourceName inputPort host port calledAeTitle callingAeTitle

al 1000 aHost1 105 aAeT meinAeT

a1 1001 aHost2 104 a2AeT myAeT2
9 ist ein Flussdiagramm einer Ausführungsform eines Prozesses zur Verarbeitung einer Webdienstanforderung unter Verwendung von Parametern aus dem Speicher (z. B. einer Nachschlagetabelle). In einer Ausführungsform wird der Prozess von einer Verarbeitungslogik durchgeführt, die aus Hardware (Schaltkreisen, spezieller Logik usw.), Software (z. B. Software, die auf einem Chip läuft), Firmware oder einer Kombination aus diesen drei Elementen bestehen kann. In einer Ausführungsform wird der Prozess von einer medizinischen Bildverwaltungsplattform durchgeführt, wie zum Beispiel, aber nicht beschränkt auf, die oben in Verbindung mit den 2 und 3 beschriebenen medizinischen Bildverwaltungsplattformen.
Wie in 9 dargestellt, beginnt der Prozess damit, dass die Verarbeitungslogik die Anforderung des Webdienstes empfängt (Verarbeitungsblock 901) und einen oder mehrere Nachschlageschlüssel für eine Quellennachschlagtabelle bestimmt (Verarbeitungsblock 902). In einer Ausführungsform kann der eine oder die mehreren URL-Eingabeparameter einen Quellennamen und/oder einen Port umfassen.
Die Verarbeitungslogik identifiziert den Dienstanforderungstyp anhand der URL und bestimmt optional den Typ der anzuwendenden Fernverbindungsmethode anhand einer Nachschlagetabelle unter Verwendung der Eingabeparameter aus 902. Die Nachschlagetabelle wird verwendet, um die notwendigen Informationen für eine neue Web-Service-Anforderung oder eine neue DIMSE-Anforderung auf der Grundlage der in 902 ermittelten Informationen zu erhalten (Verarbeitungsblock 903). In einer Ausführungsform identifiziert die Verarbeitungslogik die DIMSE-Parameter für die Eingabeparameter 902 auf der Grundlage einer Nachschlagetabelle im Speicher (z. B. einer Nachschlagetabelle).
Anhand der ermittelten Parameter 903 erzeugt die Verarbeitungslogik eine Anforderung (Verarbeitungsblock 904) und sendet die erzeugte Anforderung an den PACS/VNA/DICOM-Server (Verarbeitungsblock 905).
Ein beispielhaftes Managementsystem für medizinische Bildgebung
10 zeigt eine beispielhafte Ausführungsform einer logischen Darstellung eines medizinischen Bildgebungs- und Informationsmanagementsystems 1000, das Layouts mit aktuellen und früheren Werten der oben besprochenen Parameter erzeugt und wiedergibt. In einer Ausführungsform ist das System 1000 Teil eines medizinischen Bildgebungssystems, wie es oben beschrieben wurde.
Das medizinische Bildgebungs- und Informationsmanagementsystem 1000 umfasst einen oder mehrere Prozessoren 1001, die über ein erstes Übertragungsmedium 1020 mit einer Kommunikationsschnittstellenlogik 1010 verbunden sind. Die Kommunikationsschnittstellenlogik 1010 ermöglicht die Kommunikation mit anderen elektronischen Geräten, insbesondere die Kommunikation mit entfernten Anwendern wie Ärzten, Krankenschwestern und/oder medizinischem Fachpersonal, entfernten Datenbanken (z. B. PACS), die Studien zur medizinischen Versorgung speichern, Modalitäten zur medizinischen Versorgung, die Studien erzeugen und senden, und einem oder mehreren entfernten Standorten (z. B. Cloud-basierte Server). Gemäß einer Ausführungsform der Offenlegung kann die Kommunikationsschnittstellenlogik 1010 als physische Schnittstelle mit einem oder mehreren Ports für verdrahtete Anschlüsse implementiert werden. Zusätzlich oder alternativ kann die Kommunikationsschnittstellenlogik 1010 mit einer oder mehreren Funkeinheiten zur Unterstützung der drahtlosen Kommunikation mit anderen elektronischen Geräten implementiert werden.
Der/die Prozessor(en) 1001 ist/sind außerdem über das zweite Übertragungsmedium 1025 mit dem dauerhaften Speicher 1030 verbunden. Gemäß einer Ausführungsform der Offenlegung kann der dauerhafte Speicher 1030 Daten und Code zur Implementierung enthalten: (a) Schnittstellenlogik 1041, (b) universelle Zugriffslogik 1042, (c) Logik für die Erkennung von Webdienstanfragen (z.B. Parser) 1043, (d) Logik für die Erzeugung und Ausgabe von Anfragen 1044, (e) Logik für die Erzeugung von Webdienstantworten (z.B. Umformung) 1045, (f) Logik für das Nachschlagen von Parametern 1046, (g) Logik für die Erzeugung von Renderem/Ausgaben 1033, (h) Logik für die Anzeigesteuerung 1034, (i) eine Notizdatenbank 1036 und (j) eine Datensatzdatenbank 1037.
In einer Ausführungsform umfasst die Schnittstellenlogik 1041 eine Logik zur Ermöglichung der Interaktion zwischen Komponenten der Plattform, einschließlich Clients und Hosts, sowie zwischen einem Benutzer und den auf dem Bildschirm angezeigten Anzeigebereichen.
In einer Ausführungsform umfasst die Logik 1042 der Universal Access Engine eine Logik, die die Verarbeitung und Koordinierung von Webdienstanfragen und deren Antworten wie oben beschrieben ermöglicht. Die Logik 1043 zur Erkennung von Webdienstanfragen umfasst eine Logik zur Bestimmung des Typs von Webdiensten, der in einer empfangenen Webdienstantwort enthalten ist. In einer Ausführungsform umfasst die Logik 1043 zur Erkennung von Webdienstanfragen eine Analyselogik, um festzustellen, ob die Webdienstanforderung eine Webdienstkennung enthält. Die Logik 1044 zur Erzeugung und Ausgabe von DIMSE-Anfragen umfasst eine Logik zur Erzeugung und Ausgabe einer DIMSE-Anfrage wie oben beschrieben. Die Logik 1045 zur Erzeugung einer Webdienstantwort enthält eine Logik zur Erzeugung einer Webdienstantwort aus der Antwort auf die vom SCP-Host empfangene DIMSE-Anfrage. In einer Ausführungsform enthält die Logik 1045 zur Erzeugung von Webdienstantworten eine Umformatierungslogik, um die Antwort wie oben beschrieben umzuformatieren. Die Logik 1046 für das Nachschlagen von Parametern umfasst eine Logik zum Durchführen von Nachschlageoperationen im Speicher (z. B. in einer Nachschlagetabelle), um Parameter anhand von Informationen zu finden, die in der Webdienstanfrage enthalten waren, so dass die Parameter bei der Formulierung der DIMSE-Anfrage wie oben beschrieben verwendet werden können.
Die Renderer-/Ausgabe-Erzeugungslogik 1033 umfasst eine Logik zur Erzeugung einer gerenderten Ausgabe wie oben beschrieben. Das Speichern des Zustands kann das Speichern mindestens (i) der einen oder mehreren Informationen und (ii) der Betrachtungseigenschaften jeder der einen oder mehreren Informationen in einem nichttransitorischen computerlesbaren Medium umfassen. Die Layout-Vorlage kann ein oder mehrere Bilder einer Gesundheitsstudie darstellen, die Bilddaten zeigt, die für einen Befund aus einem automatischen Bildanalysealgorithmus relevant sind.
Die Anzeigesteuerungslogik 1034 umfasst die Logik zur Anzeige von Benutzeroberflächen, Bildern, DICOM-Objekten, Studien oder Teilen davon und Datensätzen aus dem Gesundheitswesen, die wie oben beschrieben lokal gerendert wurden. In einer Ausführungsform umfasst die Anzeigesteuerungslogik 1034 eine Logik zum Erstellen einer Browserseite, auf der die oben beschriebenen Bilder und Benutzeroberflächen angezeigt werden.
In der Notizdatenbank 1036 werden Notizen gespeichert, die von einem Arzt, einer Krankenschwester, einem Medizintechniker usw. aufgezeichnet wurden und die ein Benutzer in einen Anzeigebereich einer Layoutvorlage importieren kann. Schließlich speichert die Datenbank 1037 medizinische Aufzeichnungen, die ein Benutzer in einen Anzeigebereich einer Layoutvorlage importieren kann.
Es gibt eine Reihe von Ausführungsbeispielen, die hier beschrieben werden.
Beispiel 1 ist ein Verfahren, das Folgendes umfasst: Empfangen einer Webdienstanforderung von einem entfernten Webclient für ein oder mehrere DICOM-Objekte (Digital Imaging and Communications in Medicine) an einer Webdienstmaschine; Erzeugen einer DIMSE-Dienstanforderung aus der Webdienstanforderung, wobei das Erzeugen der DIMSE-Dienstanforderung das Parsen einer modifizierten Basis-URL umfasst, die Informationen für eine DIMSE-Dienstanforderung enthält, wobei die modifizierte URL mit einem Standard konform ist, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert; Senden der DIMSE-Dienstanforderung an einen Server; Empfangen einer Antwort auf die DIMSE-Dienstanforderung von dem Server; Neuformatieren der Antwort, so dass sie mit dem Standard übereinstimmt, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert; und Zurücksenden der neu formatierten Antwort an den entfernten Web-Client.
Beispiel 2 ist das Verfahren gemäß Beispiel 1, das optional beinhalten kann, dass die geänderte Basis-URL Informationen enthält, die für eine DICOM C-FIND-, C-GET-, C-MOVE- oder C-STORE-Anfrage erforderlich sind.
Beispiel 3 ist das Verfahren von Beispiel 2, die optional beinhalten kann, dass der Standard der NEMA DICOM Web Services Standard PS3.18 ist.
Beispiel 4 ist das Verfahren aus Beispiel 1, das optional beinhalten kann, dass die Webdienstanforderung eine QIDO-RS-, WADO-RS-, STOW-RS- oder WADO-URI-Anforderung umfasst und die DIMSE-Dienstanforderung eine DICOM C-FIND-, C-GET-, C-MOVE- oder C-STORE-Operation umfasst.
Beispiel 5 ist das Verfahren gemäß Beispiel 1, das optional die Analyse der Webdienstanforderung nach der Basis-URL zur Identifizierung eines Webdiensttyps, die Erstellung eines DICOM-Clients und die Ausgabe eines DIMSE-Dienstes, der auf der Grundlage des identifizierten Webdiensttyps ausgewählt wurde, durch den DICOM-Client umfassen kann.
Beispiel 6 ist das Verfahren gemäß Beispiel 1, das optional beinhalten kann, dass die Webdienstanforderung einen oder mehrere Bezugspunkte enthält, und das ferner die Bestimmung eines oder mehrerer Parameter für die DIMSE-Anforderung umfasst, indem der eine oder die mehreren Parameter aus dem Speicher unter Verwendung des einen oder der mehreren Bezugspunkte gewonnen werden.
Beispiel 7 ist das Verfahren gemäß Beispiel 6, das optional beinhalten kann, dass die ein oder mehreren Daten verwendet werden, um die Verbindungsmethode für den Zugriff auf den entfernten Server zu bestimmen.
Beispiel 8 ist ein medizinisches Bildverwaltungssystem, das Folgendes umfasst: eine Netzwerkkommunikationsschnittstelle zum Empfangen einer Webdienstanforderung von einem entfernten Webclient für ein oder mehrere DICOM-Objekte; einen mit der Netzwerkkommunikationsschnittstelle gekoppelten Speicher zum Speichern empfangener medizinischer Studien; einen mit dem Speicher gekoppelten Anzeigebildschirm zum Anzeigen der empfangenen medizinischen Studien; und einen oder mehrere Prozessoren, die mit der Netzwerkverbindungsschnittstelle, dem Speicher und dem Anzeigebildschirm gekoppelt und so konfiguriert sind, dass sie eine DIMSE-Dienstanforderung aus der Webdienstanforderung erzeugen, wobei das Erzeugen der DIMSE-Dienstanforderung das Parsen einer modifizierten Basis-URL umfasst, die Informationen für einen DIMSE-Dienst enthält, wobei die modifizierte URL mit einem Standard konform ist, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert, wobei die DIMSE-Dienstanforderung über die Netzwerkkommunikationsschnittstelle an einen Server gesendet wird; Umformatieren einer Antwort auf die DIMSE-Dienstanforderung, die von dem Server über die Netzwerkkommunikationsschnittstelle empfangen wurde; und Zurücksenden der umformatierten Antwort an den entfernten Web-Client über die Netzwerkkommunikationsschnittstelle, wobei die Antwort mit dem Standard konform ist, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert.
Beispiel 9 ist das System gemäß Beispiel 8, das optional beinhalten kann, dass die geänderte Basis-URL Informationen enthält, die für eine DICOM C-FIND-, C-GET-, C-MOVE- oder C-STORE-Anfrage erforderlich sind.
Beispiel 10 ist das System gemäß Beispiel 9, das optional den NEMA DICOM Web Services Standard PS3.18 als Standard enthalten kann.
Beispiel 11 ist das System gemäß Beispiel 8, das optional beinhalten kann, dass die Webdienstanforderung eine QIDO-RS-, WADO-RS-, STOW-RS- oder WADO-URI-Anforderung umfasst und die DIMSE-Dienstanforderung eine C-FIND-, C-GET-, C-MOVE- oder C-STORE-Operation umfasst.
Beispiel 12 ist das System gemäß Beispiel 8, das optional so konfiguriert sein kann, dass der eine oder die mehreren Prozessoren die Webdienstanforderung nach der Basis-URL analysiert bzw. analysieren, um einen Typ von Webdienst zu identifizieren; einen DICOM-Client zu erstellen; und unter Verwendung des DICOM-Clients einen DIMSE-Dienst auszugeben, der auf der Grundlage des identifizierten Typs von Webdienst ausgewählt wurde.
Beispiel 13 ist das System gemäß Beispiel 8, das optional so beschaffen sein kann, dass die Webdienstanforderung einen oder mehrere Bezugspunkte enthält, und dass der eine oder die mehreren Prozessoren so betrieben werden können, dass sie einen oder mehrere Parameter für die DIMSE-Anforderung bestimmen, indem sie den einen oder die mehreren Parameter unter Verwendung des einen oder der mehreren Bezugspunkte aus dem Speicher abrufen.
Beispiel 14 ist das System gemäß Beispiel 13, bei dem optional die ein oder mehreren Daten verwendet werden, um die Verbindungsmethode für den Zugriff auf den entfernten Server zu bestimmen.
Beispiel 15 ist ein nicht-transitorisches computerlesbares Speichermedium mit darauf gespeicherten Anweisungen, die, wenn sie von einem System mit mindestens einem Prozessor, einem Speicher und einem Bildschirm ausgeführt werden, das System veranlassen, ein Verfahren durchzuführen, das Folgendes umfasst: Empfangen einer Webdienstanforderung von einem entfernten Webclient für ein oder mehrere DICOM-Objekte (Digital Imaging and Communications in Medicine) an einer Webdienstmaschine; Erzeugen einer DIMSE-Dienstanforderung aus der Webdienstanforderung, wobei das Erzeugen der DIMSE-Dienstanforderung das Parsen einer modifizierten Basis-URL für einen Dienst umfasst, der Informationen für einen DIMSE-Dienst enthält, wobei die DIMSE-Dienstanforderung mit einem Standard konform ist, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert; Senden der DIMSE-Dienstanforderung an einen Server; Empfangen einer Antwort auf die DIMSE-Dienstanforderung von dem Server; Neuformatieren der Antwort, so dass sie mit dem Standard übereinstimmt, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert; und Zurücksenden der neu formatierten Antwort an den entfernten Web-Client.
Beispiel 16 ist das computerlesbare Speichermedium gemäß Beispiel 15, bei dem der Standard optional der NEMA DICOM Web Services Standard PS3.18 ist, und bei dem die modifizierte Basis-URL Informationen enthält, die für eine DICOM C-FIND, C-GET, C-MOVE oder C-STORE Anfrage notwendig sind.
Beispiel 17 ist das computerlesbare Speichermedium gemäß Beispiel 15, bei dem optional die Webdienstanforderung eine QIDO-RS-, WADO-RS-, STOW-RS- oder WADO-URI-Anforderung und die DIMSE-Dienstanforderung eine DICOM C-FIND-, C-GET-, C-MOVE- oder C-STORE-Operation umfasst.
Beispiel 18 ist das computerlesbare Speichermedium gemäß Beispiel 15, das optional die folgenden Schritte umfasst: Analysieren der Webdienstanforderung nach der Basis-URL, um einen Typ von Webdienst zu identifizieren; Erstellen eines DICOM-Clients; und Ausgeben eines DIMSE-Dienstes, der auf der Grundlage des identifizierten Webdiensttyps ausgewählt wurde, durch den DICOM-Client.
Beispiel 19 ist das computerlesbare Speichermedium gemäß Beispiel 15, das optional sein kann, dass die Webdienstanforderung einen oder mehrere Bezugspunkte enthält, und das Verfahren ferner die Bestimmung eines oder mehrerer Parameter für die DIMSE-Anforderung umfasst, indem der eine oder die mehreren Parameter aus dem Speicher unter Verwendung des einen oder der mehreren Bezugspunkte erhalten werden.
Beispiel 20 ist das computerlesbare Speichermedium gemäß Beispiel 19, bei dem optional das eine oder die mehreren Daten verwendet werden können, um die Verbindungsmethode für den Zugriff auf den entfernten Server zu bestimmen.
Beispiel 21 ist ein medizinisches Bildverwaltungssystem, das Folgendes umfasst: eine Netzwerkschnittstelle zur Kommunikation mit einem oder mehreren Clients und einem oder mehreren entfernten Servern; und eine Zugriffsmaschine mit Schaltkreisen zum Empfangen eines ersten Satzes von Anforderungen von dem einen oder den mehreren Clients, die an den einen oder die mehreren entfernten Server gerichtet sind, und zum Ausgeben eines zweiten Satzes von Anforderungen an die entfernten Server als Reaktion auf den ersten Satz von Anforderungen, wobei der zweite Satz von Anforderungen entweder eine DICOM-Webdienstanforderung oder eine DIMSE-Anforderung ist.
Beispiel 22 ist das medizinische Bildverwaltungssystem gemäß Beispiel 21, bei dem die DICOM-Webdienstanforderung optional eine QIDO-RS-, WADO-RS-, STOW-RS- oder WADO-URI-Anforderung und die DIMSE-Anforderung eine DICOM C-FIND-, C-GET-, C-MOVE- oder C-STORE-Operation umfassen kann.
Beispiel 23 ist das medizinische Bildverwaltungssystem gemäß Beispiel 21, wobei mindestens eine der ersten Gruppe von Anfragen ein oder mehrere Daten enthält und die Zugriffsmaschine in der Lage ist, anhand eines oder mehrerer Daten und optionaler persistierter Daten zu bestimmen, ob Webdienste oder DIMSE verwendet werden sollen, und die Zugriffsmaschine in der Lage ist, anhand eines oder mehrerer Daten und optionaler persistierter Daten eine gültige Anfrage an den entfernten Server zu erstellen und auszugeben.
Einige Teile der obigen detaillierten Beschreibungen werden in Form von Algorithmen und symbolischen Darstellungen von Operationen an Datenbits in einem Computerspeicher dargestellt. Diese algorithmischen Beschreibungen und Darstellungen sind die Mittel, die von Fachleuten der Datenverarbeitung verwendet werden, um anderen Fachleuten den Inhalt ihrer Arbeit am effektivsten zu vermitteln. Ein Algorithmus wird hier und im Allgemeinen als eine in sich konsistente Abfolge von Schritten verstanden, die zu einem gewünschten Ergebnis führen. Bei den Schritten handelt es sich um solche, die physikalische Manipulationen von physikalischen Größen erfordern. Normalerweise, wenn auch nicht notwendigerweise, haben diese Größen die Form von elektrischen oder magnetischen Signalen, die gespeichert, übertragen, kombiniert, verglichen und anderweitig manipuliert werden können. Zuweilen hat es sich als zweckmäßig erwiesen, diese Signale vor allem aus Gründen des allgemeinen Sprachgebrauchs als Bits, Werte, Elemente, Symbole, Zeichen, Begriffe, Zahlen oder dergleichen zu bezeichnen.
Es sollte jedoch bedacht werden, dass alle diese und ähnliche Begriffe mit den entsprechenden physikalischen Größen in Verbindung zu bringen sind und lediglich praktische Bezeichnungen für diese Größen darstellen. Sofern in der folgenden Beschreibung nicht ausdrücklich etwas anderes angegeben ist, beziehen sich Begriffe wie „Verarbeitung“ oder „Berechnung“ oder „Berechnung“ oder „Bestimmung“ oder „Anzeige“ oder ähnliches auf die Aktionen und Prozesse eines Computersystems oder eines ähnlichen elektronischen Rechengeräts, das Daten, die als physikalische (elektronische) Größen in den Registern und Speichern des Computersystems dargestellt werden, manipuliert und in andere Daten umwandelt, die in ähnlicher Weise als physikalische Größen in den Speichern oder Registern des Computersystems oder in anderen Geräten zur Speicherung, Übertragung oder Anzeige von Informationen dargestellt werden.
Die vorliegende Erfindung bezieht sich auch auf ein Gerät zur Durchführung der hier beschriebenen Vorgänge. Diese Vorrichtung kann speziell für die erforderlichen Zwecke konstruiert sein, oder sie kann einen Universalcomputer umfassen, der durch ein im Computer gespeichertes Computerprogramm selektiv aktiviert oder rekonfiguriert wird. Ein solches Computerprogramm kann in einem computerlesbaren Speichermedium gespeichert sein, wie z. B., aber nicht beschränkt auf, jede Art von Diskette, einschließlich Disketten, optische Disketten, CD-ROMs und magnetisch-optische Disketten, Festwertspeicher (ROMs), Direktzugriffsspeicher (RAMs), EPROMs, EEPROMs, magnetische oder optische Karten oder jede Art von Medien, die zur Speicherung elektronischer Anweisungen geeignet sind und jeweils mit einem Computersystembus gekoppelt sind.
Die hier vorgestellten Algorithmen und Anzeigen sind nicht inhärent aus an einen bestimmten Computer oder ein anderes Gerät gebunden. Verschiedene Allzwecksysteme können mit Programmen gemäß den hier dargelegten Lehren verwendet werden, oder es kann sich als zweckmäßig erweisen, ein spezielleres Gerät zu konstruieren, um die erforderlichen Verfahrensschritte durchzuführen. Die erforderliche Struktur für eine Vielzahl dieser Systeme geht aus der nachfolgenden Beschreibung hervor. Darüber hinaus wird die vorliegende Erfindung nicht unter Bezugnahme auf eine bestimmte Programmiersprache beschrieben. Es versteht sich von selbst, dass eine Vielzahl von Programmiersprachen verwendet werden kann, um die Lehren der Erfindung, wie hier beschrieben, zu implementieren.
Ein maschinenlesbares Medium ist ein Mechanismus zum Speichern oder Übertragen von Informationen in einer Form, die von einer Maschine (z. B. einem Computer) gelesen werden kann. Ein maschinenlesbares Medium umfasst beispielsweise Festwertspeicher („ROM“), Speicher mit wahlfreiem Zugriff („RAM“), Magnetplattenspeichermedien, optische Speichermedien, Flash-Speichergeräte, elektrische, optische, akustische oder andere Formen von übertragenen Signalen (z. B. Trägerwellen, Infrarotsignale, digitale Signale usw.) usw.
Während viele Änderungen und Modifikationen der vorliegenden Erfindung zweifellos für eine Person mit gewöhnlichen Kenntnissen auf dem Gebiet der Technik nach dem Lesen der vorstehenden Beschreibung offensichtlich werden, ist es zu verstehen, dass jede besondere Ausführungsform, die zur Veranschaulichung gezeigt und beschrieben wird, in keiner Weise als einschränkend angesehen werden soll. Daher sollen Verweise auf Einzelheiten verschiedener Ausführungsformen den Umfang der Ansprüche nicht einschränken, in denen nur die Merkmale aufgeführt sind, die als wesentlich für die Erfindung angesehen werden.

Claims

Ein Verfahren, das Folgendes umfasst: Empfang einer Web-Service-Anfrage von einem entfernten Web-Client für ein oder mehrere DICOM-Objekte (Digital Imaging and Communications in Medicine) durch eine Web-Service-Engine; Erzeugen einer DIMSE-Service- bzw. Dienstanforderung aus der Webdienstanforderung, wobei das Erzeugen der DIMSE-Dienstanforderung das Parsen einer modifizierten Basis-URL umfasst, die Informationen für eine DIMSE-Dienstanforderung enthält, wobei die modifizierte URL mit einem Standard konform ist, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert; Senden der DIMSE-Dienstanfrage an einen Server; Empfang einer Antwort auf die DIMSE-Dienstanforderung vom Server; Neuformatierung der Antwort, um dem Standard zu entsprechen, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert; und Rücksendung der neu formatierten Antwort an den entfernten Web-Client.
Verfahren nach Anspruch 1, wobei die modifizierte Basis-URL Informationen enthält, die für eine DICOM C-FIND-, C-GET-, C-MOVE- oder C-STORE-Anfrage erforderlich sind.
Verfahren nach Anspruch 2, wobei der Standard der NEMA DICOM Web Services Standard PS3.18 ist.
Verfahren nach Anspruch 1, wobei die Webdienstanforderung eine QIDO-RS-, WADO-RS-, STOW-RS- oder WADO-URI-Anforderung umfasst und die DIMSE-Dienstanforderung eine DICOM C-FIND-, C-GET-, C-MOVE- oder C-STORE-Operation umfasst.
Verfahren nach Anspruch 1, das ferner umfasst: Parsen bzw. Analysieren der Webservice-Anfrage nach der Basis-URL, um den Typ des Webdienstes zu identifizieren; Erstellen eines DICOM-Clients; und Ausgabe eines DIMSE-Dienstes durch den DICOM-Client, der auf der Grundlage der identifizierten Art des Webdienstes ausgewählt wurde.
Verfahren nach Anspruch 1, bei dem die Webdienstanforderung ein oder mehrere Daten enthält und das ferner die Bestimmung eines oder mehrerer Parameter für die DIMSE-Anforderung umfasst, indem der eine oder die mehreren Parameter unter Verwendung des einen oder der mehreren Daten aus dem Speicher gewonnen werden.
Verfahren nach Anspruch 6, bei dem die ein oder mehreren Daten verwendet werden, um die Verbindungsmethode für den Zugriff auf den entfernten Server zu bestimmen.
Medizinisches Bildverwaltungssystem, das Folgendes umfasst: eine Netzwerkkommunikationsschnittstelle zum Empfang einer Webdienstanforderung von einem entfernten Web-Client für ein oder mehrere DICOM-Objekte; einen Speicher, der mit der Netzkommunikationsschnittstelle verbunden ist, um empfangene Gesundheitsstudien zu speichern; einen mit dem Speicher gekoppelten Anzeigeschirm zur Anzeige der empfangenen Gesundheitsstudien; und einen oder mehrere Prozessoren, die mit der Netzverbindungsschnittstelle, dem Speicher und dem Bildschirm gekoppelt und konfiguriert sind zum Erzeugen einer DIMSE-Dienstanforderung aus der Webdienstanforderung, wobei das Erzeugen der DIMSE-Dienstanforderung das Parsen einer modifizierten Basis-URL umfasst, die Informationen für einen DIMSE-Dienst enthält, wobei die modifizierte URL mit einem Standard konform ist, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert, wobei die DIMSE-Dienstanforderung über die Netzwerkkommunikationsschnittstelle an einen Server gesendet wird; Neuformatieren einer Antwort auf die vom Server über die Netzkommunikationsschnittstelle empfangene DIMSE-Dienstanforderung; und Zurücksenden der neu formatierten Antwort über die Netzwerkkommunikationsschnittstelle an den entfernten Web-Client, wobei die Antwort dem Standard entspricht, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert.
System nach Anspruch 8, wobei die modifizierte Basis-URL Informationen umfasst, die für eine DICOM C-FIND-, C-GET-, C-MOVE- oder C-STORE-Anforderung erforderlich sind.
System nach Anspruch 9, wobei der Standard der NEMA DICOM Web Services Standard PS3.18 ist.
System nach Anspruch 8, wobei die Webdienstanforderung eine QIDO-RS-, WADO-RS-, STOW-RS- oder WADO-URI-Anforderung umfasst und die DIMSE-Dienstanforderung eine C-FIND-, C-GET-, C-MOVE- oder C-STORE-Operation umfasst.
System nach Anspruch 8, wobei der eine oder die mehreren Prozessoren so konfiguriert sind, dass sie: die Webdienstanfrage nach der Basis-URL analysieren, um die Art des Webdienstes zu ermitteln; einen DICOM-Client erstellen; und über den DICOM-Client einen DIMSE-Dienst ausgeben, der auf der Grundlage des identifizierten Webdiensttyps ausgewählt wurde.
System nach Anspruch 8, wobei die Webdienstanforderung einen oder mehrere Daten bzw. Bezugspunkte enthält und der eine oder die mehreren Prozessoren so betrieben werden können, dass sie einen oder mehrere Parameter für die DIMSE-Anforderung bestimmen, indem sie den einen oder die mehreren Parameter unter Verwendung des einen oder der mehreren Daten aus dem Speicher abrufen.
System nach Anspruch 13, bei dem die ein oder mehreren Daten verwendet werden, um das Verbindungsverfahren für den Zugriff auf den entfernten Server zu bestimmen.
Nicht-transitorisches computerlesbares Speichermedium mit darauf gespeicherten Befehlen, die, wenn sie von einem System mit mindestens einem Prozessor, einem Speicher und einem Bildschirm ausgeführt werden, das System veranlassen, ein Verfahren durchzuführen, das Folgendes umfasst Empfangen einer Web-Service-Anfrage von einem entfernten Web-Client für ein oder mehrere DICOM-Objekte (Digital Imaging and Communications in Medicine) durch eine Web-Service-Engine; Erzeugen einer DIMSE-Dienstanforderung aus der Webdienstanforderung, wobei das Erzeugen der DIMSE-Dienstanforderung das Parsen einer modifizierten Basis-URL für einen Dienst umfasst, der Informationen für einen DIMSE-Dienst enthält, wobei die DIMSE-Dienstanforderung mit einem Standard konform ist, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert; Senden der DIMSE-Dienstanfrage an einen Server; Empfangen einer Antwort auf die DIMSE-Dienstanforderung vom Server; Neuformatieren der Antwort, um dem Standard zu entsprechen, der einen webbasierten Dienst für den Zugriff auf und die Darstellung von DICOM-Objekten spezifiziert; und Rücksenden der neu formatierten Antwort an den entfernten Web-Client.
Computerlesbares Speichermedium nach Anspruch 15, wobei es sich bei dem Standard um den NEMA DICOM Web Services Standard PS3.18 handelt und wobei die modifizierte Basis-URL Informationen enthält, die für eine DICOM C-FIND-, C-GET-, C-MOVE- oder C-STORE-Anforderung erforderlich sind.
Computerlesbares Speichermedium nach Anspruch 15, wobei die Webdienstanforderung eine QIDO-RS-, WADO-RS-, STOW-RS- oder WADO-URI-Anforderung umfasst und die DIMSE-Dienstanforderung eine DICOM C-FIND-, C-GET-, C-MOVE- oder C-STORE-Operation umfasst.
Computerlesbares Speichermedium nach Anspruch 15, wobei das Verfahren weiterhin umfasst: Parsen bzw. Analysieren der Webservice-Anfrage nach der Basis-URL, um den Typ des Webservices bzw. -dienstes zu identifizieren; Erstellen eines DICOM-Clients; und Ausgabe eines DIMSE-Dienstes durch den DICOM-Client, der auf der Grundlage der identifizierten Art des Webdienstes ausgewählt wurde.
Computerlesbares Speichermedium nach Anspruch 15, wobei die Webdienstanforderung einen oder mehrere Daten bzw. Bezugspunkte enthält und das Verfahren ferner das Bestimmen eines oder mehrerer Parameter für die DIMSE-Anforderung durch Abrufen des einen oder der mehreren Parameter aus dem Speicher unter Verwendung des einen oder der mehreren Daten umfasst.
Computerlesbares Speichermedium nach Anspruch 19, wobei das eine oder die mehreren Daten verwendet werden, um das Verbindungsverfahren für den Zugriff auf den entfernten Server zu bestimmen.
Ein medizinisches Bildverwaltungssystem, das Folgendes umfasst: eine Netzwerkschnittstelle zur Kommunikation mit einem oder mehreren Clients und einem oder mehreren entfernten Servern; und eine Zugriffsmaschine bzw. Access-Engine mit Schaltkreisen zum Empfangen eines ersten Satzes von Anforderungen von dem einen oder den mehreren Clients, die an den einen oder die mehreren entfernten Server gerichtet sind, und zum Ausgeben eines zweiten Satzes von Anforderungen an die entfernten Server als Reaktion auf den ersten Satz von Anforderungen, wobei der zweite Satz von Anforderungen entweder eine DICOM-Webdienstanforderung oder eine DIMSE-Anforderung ist.
Medizinisches Bildverwaltungssystem nach Anspruch 21, wobei die DICOM-Webdienstanforderung eine QIDO-RS-, WADO-RS-, STOW-RS- oder WADO-URI-Anforderung umfasst und die DIMSE-Anforderung eine DICOM C-FIND-, C-GET-, C-MOVE- oder C-STORE-Operation umfasst.
Medizinisches Bildverwaltungssystem nach Anspruch 21, wobei mindestens eine der ersten Gruppe von Anforderungen ein oder mehrere Daten enthält und die Zugriffsmaschine in der Lage ist, anhand eines oder mehrerer Daten und optionaler persistierter bzw. persistenter Daten zu bestimmen, ob Webdienste oder DIMSE verwendet werden sollen, und die Zugriffsmaschine bzw. Access-Engine in der Lage ist, anhand eines oder mehrerer Daten und optionaler persistierter Daten eine gültige Anforderung an den entfernten Server zu erstellen und auszugeben.