In einen DICOM Medical Viewer einbinden

Auf dieser Seite werden Konzepte und Best Practices für die Integration eines Viewer für medizinische Bilder in die Cloud Healthcare API erläutert. Die Cloud Healthcare API ist in mehrere Viewer integriert, einschließlich des Open Health Imaging Foundation (Ohif) Viewers und des Weasis-Viewers.

Hinweise

Wenn Sie keine DICOM-Bilder zur Verwendung in Ihrem Viewer gespeichert haben, lesen Sie zuerst DICOM-Daten speichern und DICOM-Daten mit Cloud Storage importieren und exportieren.

Anfragen mit OAuth 2.0 autorisieren und authentifizieren

Google Cloud APIs unterstützen das OAuth 2.0-Protokoll für die Authentifizierung und Autorisierung.

Ein Betrachter aus der Medizin muss die Authentifizierung und Autorisierung für den Zugriff auf in der Cloud Healthcare API gespeicherte DICOM-Daten durchführen. Sie haben zwei Möglichkeiten, diese Berechtigungen zu erteilen. Jede Methode hat ihre eigenen Kosten und Vorteile:

OAuth 2.0-Vorgang für Google Identity Services verwenden

  • Endnutzer authentifizieren sich über die medizinische Anzeige bei der Cloud Healthcare API.
  • Der medizinische Betrachter greift im Namen des Endnutzers auf die Cloud Healthcare API zu.
  • Berechtigungen werden auf Nutzerebene verwaltet und die Aktionen des Nutzers werden in Cloud-Audit-Logs mit der eindeutigen ID des Nutzers protokolliert.
  • Die Verwendung des Google Identity Services-Vorgangs ist komplexer als die Verwendung eines Dienstkontos. Ihre Anwendung muss beispielsweise Rückrufe zum Speichern des Autorisierungstokens verarbeiten, was eine einfache Anwendung unnötig komplex machen kann.

Dienstkonto verwenden

  • Sie konfigurieren die medizinische Anzeige mit einer eigenen Autorisierungs- und Zugriffssteuerung, um zu bestimmen, ob ein Endnutzer eine bestimmte Cloud Healthcare API-Ressource anzeigen kann. Die Verwendung eines Dienstkontos ist hilfreich, wenn Sie bereits einen Viewer haben, der eigene Nutzerverwaltungs- und Authentifizierungsprüfungen durchführt.
  • Aktionen, die im Viewer ausgeführt werden, werden in Cloud-Audit-Logs protokolliert, aber Sie können keine Logs auf der Ebene einzelner Endnutzer sehen.
  • Die Authentifizierung mit einem Dienstkonto ist einfacher als die Verwendung des Google Identity Services-Vorgangs. Es ist beispielsweise nicht erforderlich, einen Nutzer zur Anmeldung aufzufordern und daher kein Zugriffstoken zu speichern.

Mit dem OAuth 2.0-Vorgang von Google Identity Services autorisieren

Sie können einem medizinischen Betrachter den Zugriff auf DICOM-Daten gestatten, die in der Cloud Healthcare API im Namen eines Nutzers gespeichert sind, indem Sie den OAuth 2.0-Ablauf für Google Identity Services verwenden. Je nach Anwendungsfall sind Abläufe für die folgenden Anwendungen verfügbar:

In der folgenden Beschreibung für den Anmeldevorgang wird davon ausgegangen, dass der Nutzer, der auf den Betrachter zugreift, einen DICOM-Speicher erstellt und DICOM-Instanzen im Speicher gespeichert hat:

  1. Ein Nutzer öffnet Ihre medizinische Anzeige. Der Betrachter zeigt ein Zustimmungsfenster von Google an, in dem der Name Ihrer Anwendung und die Google API-Dienste angezeigt werden, für die mit den Autorisierungsanmeldedaten des Nutzers eine Berechtigung angefordert wird. Der Nutzer kann dann zustimmen oder den Zugriff auf Ihre Anwendung verweigern.
  2. Der Nutzer wird zu einer Seite der Google Identity Services weitergeleitet. Wenn der Nutzer Ihrer Anwendung den angeforderten Zugriff gewährt, erhält Ihre Anwendung die Berechtigung, auf die Daten des Nutzers zuzugreifen.

Speichern Sie keine Aktualisierungstokens im Viewer. Die Zugriffstokens, die der Nutzer dem Nutzer gewährt, sollten nur von kurzer Dauer sein und nur ausgetauscht werden, wenn die Tokens ablaufen.

Aktualisierungstokens sind aus folgenden Gründen ebenfalls nicht erforderlich:

  • Der Nutzer ist immer anwesend, wenn er den Viewer verwendet.
  • Die Verwendung von Aktualisierungstokens erfordert zusätzliche Arbeit, um das Token sicher zu speichern.

Mit einem Dienstkonto autorisieren

Sie können die Authentifizierung und Autorisierung auf der Ebene des medizinischen Viewers und nicht auf Endnutzerebene verwalten, indem Sie OAuth 2.0 mit einem Dienstkonto verwenden.

Eine Anleitung zur Authentifizierung eines medizinischen Viewers bei der Cloud Healthcare API mit einem Dienstkonto finden Sie unter Bei der API authentifizieren.

Erforderliche Rollen

Damit der Betrachter ordnungsgemäß funktioniert, muss ein Nutzer die folgenden Rollen haben:

  • roles/healthcare.dicomViewer: zum Aufrufen von DICOM-Ressourcen
  • roles/healthcare.dicomEditor: zum Anzeigen, Bearbeiten und Erstellen von DICOM-Ressourcen

Im Anmeldevorgang wird davon ausgegangen, dass der Nutzer diese Rollen bereits konfiguriert hat und der Betrachter nichts weiter tun muss. Wenn Sie ein Dienstkonto verwenden, müssen die Rollen im Dienstkonto festgelegt werden. Der Betrachter sollte Nutzern, die nicht über die erforderlichen Berechtigungen für den Zugriff auf ihre DICOM-Speicher verfügen, entsprechende PERMISSION_DENIED-Fehler zurückgeben.

Auf DICOMweb-Endpunkte zugreifen

Nachdem sich der Nutzer beim Betrachter authentifiziert hat, kann der Betrachter Anfragen an DICOMweb-Endpunkte senden. Jeder DICOM-Speicher stellt einen einzelnen DICOMweb-Endpunkt bereit.

Wenn sich der Nutzer im Viewer befindet, muss er angeben, auf welche Projekte und DICOM-Speicher er zugreifen möchte. Am einfachsten ist es, den Nutzer aufzufordern, die IDs für das Projekt, das Dataset und den DICOM-Speicher anzugeben, auf die er zugreifen möchte. Die Bereitstellung jedes einzelnen Werts kann jedoch lange dauern.

Alternativ können Sie eine Kombination aus Nutzereingabe und automatischer Vervollständigung im Viewer bereitstellen. Beispiel: Der Nutzer muss eine Projekt-ID eingeben. Der Betrachter füllt dann automatisch eine Liste der Datasets und DICOM-Speicher in diesem Projekt aus. Sie können auch ein einzelnes Eingabefeld angeben, das automatisch die Projekte, Datasets und DICOM-Speicher ausfüllt, auf die der Nutzer Zugriff hat. Die folgenden API-Methoden können bei der Einrichtung einer dieser Alternativen hilfreich sein:

Sie können auch eine Liste der Ressourcen eines Nutzers vorab füllen. Wenn ein Nutzer jedoch Hunderte oder Tausende von DICOM-Speichern oder -Datasets hat, ist es möglicherweise nicht möglich, die Liste vorab auszufüllen und anzuzeigen.

Mit DICOMweb auf Ressourcen im Viewer zugreifen

Die Cloud Healthcare API unterstützt den DICOMweb-Standard. Damit Nutzer auf ihre Daten zugreifen können, muss der Betrachter die DICOMweb RESTful HTTP-Methoden anstelle der alten DIMSE-Protokolle implementieren.

Jeder Betrachter hat zwei Hauptkomponenten:

  • Anbieter der Arbeitsliste
  • Image-Viewer

Sie können den DICOMweb-Standard mit beiden Komponenten verwenden.

Anbieter der Arbeitsliste anzeigen

In der Regel sehen Nutzer beim Öffnen eines Viewers zunächst eine Liste aller verfügbaren Studien in jedem DICOM-Speicher. Der Betrachter kann diese Studien über die Suchtransaktion abrufen.

Weitere Informationen zur Implementierung der Suchtransaktion in der Cloud Healthcare API finden Sie in der DICOM-Konformitätserklärung der Cloud Healthcare API.

Instanzen anzeigen

Nachdem der Nutzer zum Anbieter der Arbeitsliste gehört hat, wählt er in der Regel eine Studie zur Ansicht aus. Zum Rendern der Studie muss der Betrachter auf die Rohpixelbytes der Studie und die DICOM-Metadaten zugreifen. Der Betrachter kann diese Informationen mithilfe dem Satz von Methoden Transaktion abrufen abrufen. Mit den Abruftranstransaktionsmethoden können Sie eine gesamte DICOM-Rohdatei oder die Rohpixeldaten der Datei abrufen. Die Abruftranstransaktionsmethoden unterstützen auch die Transcodierung zwischen verschiedenen Übertragungssyntaxen.

Weitere Informationen zur Implementierung der Such- und Abruftransaktionsmethoden in der Cloud Healthcare API finden Sie in der DICOM-Konformitätserklärung der Cloud Healthcare API.

Den Netzwerkdurchsatz maximieren

Manchmal muss ein Betrachter mehrere Instanzen gleichzeitig herunterladen, um das Bild zu rendern. Die besten Ergebnisse erzielen Sie, wenn Sie jede Instanz parallel mit einer hohen Anzahl gleichzeitiger Anfragen (z. B. 50 oder mehr) abrufen. Die genaue Anzahl hängt von Ihrer Anwendung und der Netzwerkbandbreite ab.