Freigeben über

DICOM Conformance Statement v2

  • Artikel

Hinweis

API Version 2 ist die neueste API-Version. Eine Liste der Änderungen in v2 im Vergleich zu v1 finden Sie unter DICOM-Dienst-API v2-Änderungen

Der Medical Imaging Server für DICOM® unterstützt eine Teilmenge des DICOMweb-Standards. Der Support umfasst:

Darüber hinaus werden diese nicht standardmäßigen APIs unterstützt:

Der Dienst verwendet die REST-API-Versionsverwaltung. Die Version der REST-API muss explizit als Teil der Basis-URL angegeben werden, wie im folgenden Beispiel gezeigt:

https://<service_url>/v<version>/studies

Diese Version der Konformitäts-Anweisung entspricht der v2 Version der REST-APIs.

Weitere Informationen zum Angeben der Version beim Erstellen von Anforderungen finden Sie in der API-Versionsverwaltungsdokumentation.

Sie finden Beispielanforderungen für unterstützte Transaktionen in der Postman-Sammlung.

Präambelbereinigung

Der Dienst ignoriert die 128-Byte-Dateivorschrift und ersetzt den Inhalt durch NULL-Zeichen. Dieses Verhalten stellt sicher, dass keine Dateien, die über den Dienst übergeben werden, anfällig für die böswillige Präambel-Sicherheitsanfälligkeit sind. Diese Präambelbereinigung bedeutet jedoch auch, dass Präambel, die zum Codieren von Inhalten im dualen Format verwendet werden, z. B. TIFF, nicht mit dem Dienst verwendet werden können.

Studienservice

Der Studiendienst ermöglicht Es Benutzern, DICOM-Studien, Reihen und Instanzen zu speichern, abzurufen und zu suchen. Wir haben die nicht standardmäßige Delete-Transaktion hinzugefügt, um einen vollständigen Ressourcenlebenszyklus zu aktivieren.

Store (STOW-RS)

Diese Transaktion verwendet die POST- oder PUT-Methode, um Darstellungen von Studien, Datenreihen und Instanzen in der Anforderungsnutzlast zu speichern.

Methode Pfad Beschreibung
POST .. /Studium Speichern von Instanzen.
POST .. /studies/{study} Speichern sie Instanzen für eine bestimmte Studie.
PUT .. /Studium Upsert-Instanzen.
PUT .. /studies/{study} Upsert-Instanzen für eine bestimmte Studie.

Der Parameter study entspricht dem DICOM-Attribut "StudyInstanceUID". Wenn angegeben, wird jede Instanz, die nicht zur bereitgestellten Studie gehört, mit einem 43265 Warncode abgelehnt.

Es folgt der einzige Antwortheader Accept , der unterstützt wird:

  • application/dicom+json

Die folgenden Content-Type Header werden unterstützt:

  • multipart/related; type="application/dicom"
  • application/dicom

Hinweis

Der Server erzwingt keine Attribute, die mit vorhandenen Daten für POST-Anforderungen in Konflikt geraten. Alle Daten werden wie bereitgestellt gespeichert. Bei Upsert-Anforderungen (PUT) werden die vorhandenen Daten durch die neuen empfangenen Daten ersetzt.

Erforderliche Attribute speichern

Die folgenden DICOM-Elemente müssen in jeder DICOM-Datei vorhanden sein, die versucht, gespeichert zu werden:

  • StudyInstanceUID
  • SeriesInstanceUID
  • SOPInstanceUID
  • SOPClassUID
  • PatientID

Hinweis

Alle UIDs müssen zwischen 1 und 64 Zeichen lang sein und nur alphanumerische Zeichen oder die folgenden Sonderzeichen enthalten: ., -. PatientID ist weiterhin ein erforderliches Tag und kann den Wert in der Eingabe als NULL aufweisen. PatientID wird basierend auf dem LO VR Typ überprüft.

Jede gespeicherte Datei muss eine eindeutige Kombination aus StudyInstanceUID, , SeriesInstanceUIDund SopInstanceUID. Der Warncode 45070 wird zurückgegeben, wenn bereits eine Datei mit denselben Bezeichnern vorhanden ist.

Es werden nur Syntaxen mit expliziten Wertdarstellungen akzeptiert.

Hinweis

Anforderungen sind auf 4 GB beschränkt. Dieser Grenzwert kann von keiner einzelnen DICOM-Datei oder einer Einzelnen Kombination von Dateien überschritten werden.

Store-Änderungen von v1

In früheren Versionen schlägt eine Store-Anforderung fehl, wenn eine der erforderlichen oder durchsuchbaren Attribute die Überprüfung fehlgeschlagen ist. Ab V2 schlägt die Anforderung nur fehl, wenn die überprüfung der erforderlichen Attribute fehlschlägt.

Fehler bei der Überprüfung von Attributen, die von der API nicht erforderlich sind, führt dazu, dass die Datei mit einer Warnung gespeichert wird. Es wird eine Warnung zu jedem Fehlerhaften Attribut pro Instanz angezeigt. Wenn eine Sequenz ein Attribut enthält, bei dem die Überprüfung fehlschlägt oder mehrere Probleme mit einem einzelnen Attribut auftreten, wird nur der erste fehlerhafte Attributgrund angegeben.

Wenn ein Attribut mit Nullen aufgefüllt wird, wird das Attribut bei Durchsuchbarem indiziert und wie in dicom+json-Metadaten gespeichert. Es wird keine Überprüfungswarnung bereitgestellt.

Store-Antwortstatuscodes

Code Beschreibung
200 (OK) Alle SOP-Instanzen in der Anforderung wurden gespeichert.
202 (Accepted) Der Ursprungsserver speicherte einige instanzen und andere fehler oder zurückgegebene Warnungen. Weitere Informationen zu diesem Fehler finden Sie möglicherweise im Nachrichtentext der Antwort.
204 (No Content) In der Store-Transaktionsanforderung wurden keine Inhalte bereitgestellt.
400 (Bad Request) Die Anforderung wurde schlecht formatiert. Der angegebene Untersuchungsinstanzbezeichner entspricht beispielsweise nicht dem erwarteten UID-Format.
401 (Unauthorized) Der Client ist nicht authentifiziert.
406 (Not Acceptable) Die angegebene Accept Kopfzeile wird nicht unterstützt.
409 (Conflict) Keine der Instanzen in der Speichertransaktionsanforderung wurde gespeichert.
415 (Unsupported Media Type) Die bereitgestellte Version Content-Type wird nicht unterstützt.
424 (Failed Dependency) Der DICOM-Dienst kann nicht auf eine Ressource zugreifen, von der sie abhängig ist, um diese Anforderung abzuschließen. Ein Beispiel ist ein Fehler beim Zugriff auf den verbundenen Data Lake-Speicher oder der Schlüsseltresor zur Unterstützung der vom Kunden verwalteten Schlüsselverschlüsselung.
500 (Internal Server Error) Auf dem Server ist ein unbekannter interner Fehler aufgetreten. Versuchen Sie es später noch einmal.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Paylo der Store-Antwort

Die Antwortnutzlast füllt ein DICOM-Dataset mit den folgenden Elementen auf:

Tag Name Beschreibung
(0008, 1190) RetrieveURL Die Abrufen-URL der Studie, wenn die StudyInstanceUID in der Store-Anforderung bereitgestellt wurde und mindestens eine Instanz erfolgreich gespeichert wird.
(0008, 1198) FailedSOPSequence Die Abfolge von Instanzen, die nicht gespeichert werden konnten.
(0008, 1199) ReferencedSOPSequence Die Abfolge gespeicherter Instanzen.

Jedes Dataset in der FailedSOPSequence Datei weist die folgenden Elemente auf (wenn die ZU speichernde DICOM-Datei gelesen werden könnte):

Tag Name Beschreibung
(0008, 1150) ReferencedSOPClassUID Der eindeutige SOP-Klassenbezeichner der Instanz, die nicht gespeichert werden konnte.
(0008, 1155) ReferencedSOPInstanceUID Der eindeutige SOP-Instanzbezeichner der Instanz, die nicht gespeichert werden konnte.
(0008, 1197) FailureReason Der Grundcode, warum diese Instanz nicht gespeichert werden konnte.
(0008, 1196) WarningReason Ein WarningReason Hinweis auf Überprüfungsprobleme, die erkannt wurden, aber nicht schwerwiegend genug waren, um den Speichervorgang fehlzuschlagen.
(0074, 1048) FailedAttributesSequence Die Sequenz davon ErrorComment enthält den Grund für jedes fehlgeschlagene Attribut.

Jedes Dataset in der Datei ReferencedSOPSequence weist die folgenden Elemente auf:

Tag Name Beschreibung
(0008, 1150) ReferencedSOPClassUID Der eindeutige SOP-Klassenbezeichner der gespeicherten Instanz.
(0008, 1155) ReferencedSOPInstanceUID Der eindeutige SOP-Instanzbezeichner der gespeicherten Instanz.
(0008, 1190) RetrieveURL Die Abrufen-URL dieser Instanz auf dem DICOM-Server.

Beispielantwort mit Accept Header application/dicom+json ohne FailedAttributesSequence in einer ReferencedSOPSequence:

{
  "00081190":
  {
    "vr":"UR",
    "Value":["http://localhost/studies/d09e8215-e1e1-4c7a-8496-b4f6641ed232"]
  },
  "00081198":
  {
    "vr":"SQ",
    "Value":
    [{
      "00081150":
      {
        "vr":"UI","Value":["cd70f89a-05bc-4dab-b6b8-1f3d2fcafeec"]
      },
      "00081155":
      {
        "vr":"UI",
        "Value":["22c35d16-11ce-43fa-8f86-90ceed6cf4e7"]
      },
      "00081197":
      {
        "vr":"US",
        "Value":[43265]
      }
    }]
  },
  "00081199":
  {
    "vr":"SQ",
    "Value":
    [{
      "00081150":
      {
        "vr":"UI",
        "Value":["d246deb5-18c8-4336-a591-aeb6f8596664"]
      },
      "00081155":
      {
        "vr":"UI",
        "Value":["4a858cbb-a71f-4c01-b9b5-85f88b031365"]
      },
      "00081190":
      {
        "vr":"UR",
        "Value":["http://localhost/studies/d09e8215-e1e1-4c7a-8496-b4f6641ed232/series/8c4915f5-cc54-4e50-aa1f-9b06f6e58485/instances/4a858cbb-a71f-4c01-b9b5-85f88b031365"]
      }
    }]
  }
}

Beispielantwort mit Accept Header application/dicom+json mit failedAttributesSequence in einer ReferencedSOPSequence:

{
  "00081190":
  {
    "vr":"UR",
    "Value":["http://localhost/studies/d09e8215-e1e1-4c7a-8496-b4f6641ed232"]
  },
  "00081199":
  {
    "vr":"SQ",
    "Value":
    [{
      "00081150":
      {
        "vr":"UI",
        "Value":["d246deb5-18c8-4336-a591-aeb6f8596664"]
      },
      "00081155":
      {
        "vr":"UI",
        "Value":["4a858cbb-a71f-4c01-b9b5-85f88b031365"]
      },
      "00081190":
      {
        "vr":"UR",
        "Value":["http://localhost/studies/d09e8215-e1e1-4c7a-8496-b4f6641ed232/series/8c4915f5-cc54-4e50-aa1f-9b06f6e58485/instances/4a858cbb-a71f-4c01-b9b5-85f88b031365"]
      },
      "00081196": {
        "vr": "US",
        "Value": [
            1
        ]
      },
      "00741048": {
        "vr": "SQ",
        "Value": [
          {
            "00000902": {
              "vr": "LO",
              "Value": [
                "DICOM100: (0008,0020) - Content \"NotAValidDate\" does not validate VR DA: one of the date values does not match the pattern YYYYMMDD"
              ]
            }
          },
          {
            "00000902": {
              "vr": "LO",
              "Value": [
                "DICOM100: (0008,002a) - Content \"NotAValidDate\" does not validate VR DT: value does not mach pattern YYYY[MM[DD[HH[MM[SS[.F{1-6}]]]]]]"
              ]
            }
          }
        ]
      }
    }]
  }
}

Fehlerursachencodes für den Store

Code Beschreibung
272 Die Store-Transaktion hat die Instanz aufgrund eines allgemeinen Fehlers bei der Verarbeitung des Vorgangs nicht gespeichert.
43264 Die DICOM-Instanz hat die Überprüfung fehlgeschlagen.
43265 Die angegebene Instanz StudyInstanceUID entspricht nicht der in der Store-Anforderung angegebenen StudyInstanceUID Instanz.
45070 Eine DICOM-Instanz mit demselben StudyInstanceUID, SeriesInstanceUID, und SopInstanceUID wurde bereits gespeichert. Wenn Sie den Inhalt aktualisieren möchten, löschen Sie diese Instanz zuerst.
45071 Eine DICOM-Instanz wird von einem anderen Prozess erstellt, oder der vorherige Versuch, einen Fehler zu erstellen, und der Bereinigungsvorgang ist nicht abgeschlossen. Löschen Sie die Instanz zuerst, bevor Sie erneut versuchen, die Instanz zu erstellen.

Store-Warnungsursachencodes

Code Beschreibung
45063 Ein DICOM-Instanzdatensatz stimmt nicht mit der SOP-Klasse überein. Die Studienspeichertransaktion (Abschnitt 10.5) hat festgestellt, dass das Dataset während des Speichers der Instanz nicht mit den Einschränkungen der SOP-Klasse übereinstimmte.
1 Die Studienspeichertransaktion (Abschnitt 10.5) hat festgestellt, dass das Dataset eine Überprüfung hat.

Speicherfehlercodes

Code Beschreibung
100 Die bereitgestellten Instanzattribute erfüllten die Überprüfungskriterien nicht.

Abrufen (WADO-RS)

Diese Retrieve-Transaktion bietet Unterstützung für das Abrufen gespeicherter Studien, Datenreihen, Instanzen und Frames nach Referenz.

Methode Pfad Beschreibung
GET .. /studies/{study} Ruft alle Instanzen innerhalb einer Studie ab.
GET .. /studies/{study}/metadata Ruft die Metadaten für alle Instanzen innerhalb einer Studie ab.
GET .. /studies/{study}/series/{series} Ruft alle Instanzen innerhalb einer Datenreihe ab.
GET .. /studies/{study}/series/{series}/metadata Ruft die Metadaten für alle Instanzen innerhalb einer Datenreihe ab.
GET .. /studies/{study}/series/{series}/instances/{instance} Ruft eine einzelne Instanz ab.
GET .. /studies/{study}/series/{series}/instances/{instance}/metadata Ruft die Metadaten für eine einzelne Instanz ab.
GET .. /studies/{study}/series/{series}/instances/{instance}/rendern Ruft eine Instanz ab, die in einem Bildformat gerendert wird.
GET .. /studies/{study}/series/{series}/instances/{instance}/frames/{frames} Ruft einen oder mehrere Frames aus einer einzelnen Instanz ab. Um mehr als einen Frame anzugeben, trennt ein Komma jeden frame, der zurückgegeben werden soll. Beispiel: /studies/1/series/2/instance/3/frames/4,5,6.
GET .. /studies/{study}/series/{series}/instances/{instance}/frames/{frame}/rendern Ruft einen einzelnen Frame ab, der in einem Bildformat gerendert wird.

Abrufen von Instanzen innerhalb einer Studie oder Datenreihe

Die folgenden Accept Kopfzeilen werden für das Abrufen von Instanzen innerhalb einer Studie oder einer Datenreihe unterstützt.

  • multipart/related; type="application/dicom"; transfer-syntax=*
  • multipart/related; type="application/dicom"; (wenn die Transfersyntax nicht angegeben ist, wird 1.2.840.10008.1.2.1 als Standard verwendet)
  • multipart/related; type="application/dicom"; transfer-syntax=1.2.840.10008.1.2.1
  • multipart/related; type="application/dicom"; transfer-syntax=1.2.840.10008.1.2.4.90
  • */* (wenn die Transfersyntax nicht angegeben wird, * wird als Standard- und mediaType-Standardeinstellung verwendet unter application/dicom)

Abrufen einer Instanz

Die folgenden Accept Header werden zum Abrufen einer bestimmten Instanz unterstützt.

  • application/dicom; transfer-syntax=*
  • multipart/related; type="application/dicom"; transfer-syntax=*
  • application/dicom; (wenn die Transfersyntax nicht angegeben ist, 1.2.840.10008.1.2.1 wird als Standard verwendet)
  • multipart/related; type="application/dicom" (wenn die Transfersyntax nicht angegeben ist, 1.2.840.10008.1.2.1 wird als Standard verwendet)
  • application/dicom; transfer-syntax=1.2.840.10008.1.2.1
  • multipart/related; type="application/dicom"; transfer-syntax=1.2.840.10008.1.2.1
  • application/dicom; transfer-syntax=1.2.840.10008.1.2.4.90
  • multipart/related; type="application/dicom"; transfer-syntax=1.2.840.10008.1.2.4.90
  • */* (wenn die Transfersyntax nicht angegeben wird, * wird als Standard- und mediaType-Standardeinstellung verwendet unter application/dicom)

Frames abrufen

Die folgenden Accept Header werden zum Abrufen von Frames unterstützt.

  • multipart/related; type="application/octet-stream"; transfer-syntax=*
  • multipart/related; type="application/octet-stream"; (wenn die Transfersyntax nicht angegeben ist, 1.2.840.10008.1.2.1 wird als Standard verwendet)
  • multipart/related; type="application/octet-stream"; transfer-syntax=1.2.840.10008.1.2.1
  • multipart/related; type="image/jp2"; (wenn die Transfersyntax nicht angegeben ist, 1.2.840.10008.1.2.4.90 wird als Standard verwendet)
  • multipart/related; type="image/jp2";transfer-syntax=1.2.840.10008.1.2.4.90
  • application/octet-stream; transfer-syntax=* für den Abruf einzelner Frames
  • */* (wenn die Transfersyntax nicht angegeben wird, * wird als Standard- und mediaType-Standardeinstellung verwendet unter application/octet-stream)

Abrufen der Übertragungssyntax

Wenn sich die angeforderte Übertragungssyntax von der ursprünglichen Datei unterscheidet, wird die ursprüngliche Datei in die angeforderte Übertragungssyntax transcodiert. Die Originaldatei muss eines der folgenden Formate sein, damit die Transcodierung erfolgreich ist, andernfalls schlägt die Transcodierung fehl.

  • 1.2.840.10008.1.2 (Little Endian Implicit)
  • 1.2.840.10008.1.2.1 (Little Endian Explicit)
  • 1.2.840.10008.1.2.2 (Explicit VR Big Endian)
  • 1.2.840.10008.1.2.4.50 (JPEG Baseline Process 1)
  • 1.2.840.10008.1.2.4.57 (JPEG Lossless)
  • 1.2.840.10008.1.2.4.70 (JPEG Lossless Selection Value 1)
  • 1.2.840.10008.1.2.4.90 (JPEG 2000 Lossless Only)
  • 1.2.840.10008.1.2.4.91 (JPEG 2000)
  • 1.2.840.10008.1.2.5 (RLE Lossless)

Ein nicht unterstütztes transfer-syntax Ergebnis in 406 Not Acceptable.

Abrufen von Metadaten (für Studie, Datenreihe oder Instanz)

Der folgende Accept Header wird zum Abrufen von Metadaten für eine Studie, eine Datenreihe oder eine Instanz unterstützt.

  • application/dicom+json

Beim Abrufen von Metadaten werden keine Attribute mit den folgenden Wertdarstellungen zurückgegeben.

VR-Name Beschreibung
OB Anderes Byte
OD Sonstiges Double
OF Sonstiges Float-Format
OL Andere lang
OV Andere 64-Bit-Sehr lange
OW Anderes Wort
UN Unbekannt

Abgerufene Metadaten enthalten das Nullzeichen, wenn das Attribut mit Nullen aufgefüllt und gespeichert wurde.

Abrufen der Metadatencacheüberprüfung (für Studie, Datenreihe oder Instanz)

Die Cacheüberprüfung wird mithilfe des ETag Mechanismus unterstützt. In der Antwort auf eine Metadatenanforderung wird ETag als einer der Header zurückgegeben. Dieses ETag kann zwischengespeichert und als If-None-Match Header in den späteren Anforderungen für dieselben Metadaten hinzugefügt werden. Zwei Arten von Antworten sind möglich, wenn die Daten vorhanden sind.

  • Die Daten sind seit der letzten Anforderung unverändert: Die HTTP 304 (Not Modified) Antwort wird ohne Antworttext gesendet.
  • Daten wurden seit der letzten Anforderung geändert: Die HTTP 200 (OK) Antwort wird mit dem aktualisierten ETag gesendet. Erforderliche Daten werden als Teil des Textkörpers zurückgegeben.

Abrufen gerenderter Bilder (z. B. Frame)

Die folgenden Accept Kopfzeilen werden zum Abrufen eines gerenderten Bilds in einer Instanz oder einem Frame unterstützt.

  • image/jpeg
  • image/png

In dem Fall, dass kein Accept Header angegeben wird, wird standardmäßig ein image/jpeg Dienst gerendert.

Der Dienst unterstützt nur das Rendern eines einzelnen Frames. Wenn das Rendern für eine Instanz mit mehreren Frames angefordert wird, wird standardmäßig nur der erste Frame als Bild gerendert.

Wenn Sie einen bestimmten zurückzugebenden Frame angeben, beginnt die Frameindizierung bei 1.

Der quality Abfrageparameter wird ebenfalls unterstützt. Ein ganzzahliger Wert zwischen 1 und 100 einschließlich (1 ist schlechteste Qualität und 100 die beste Qualität) wird möglicherweise als Wert für den Abfrageparameter übergeben. Dieser Parameter wird für Bilder verwendet, die als jpeggerendert werden, und wird für png Renderanforderungen ignoriert. Wenn der Parameter nicht angegeben ist, wird standardmäßig auf 100.

Ursprüngliche Version abrufen

Mithilfe des Massenaktualisierungsvorgangs können Sie entweder die ursprüngliche oder neueste Version einer Studie, Serie oder Instanz abrufen. Die neueste Version einer Studie, Serie oder Instanz wird standardmäßig zurückgegeben. Die ursprüngliche Version kann zurückgegeben werden, indem sie die msdicom-request-original Kopfzeile auf true. Hier sehen Sie eine Beispielanforderung:

GET ../studies/{study}/series/{series}/instances/{instance}
Accept: multipart/related; type="application/dicom"; transfer-syntax=*
msdicom-request-original: true
Content-Type: application/dicom

Abrufen von Antwortstatuscodes

Code Beschreibung
200 (OK) Alle angeforderten Daten wurden abgerufen.
304 (Not Modified) Die angeforderten Daten sind seit der letzten Anforderung unverändert. Inhalt wird dem Antworttext in diesem Fall nicht hinzugefügt. Weitere Informationen finden Sie im vorherigen Abschnitt Abrufen der Metadatencacheüberprüfung (für Studie, Datenreihe oder Instanz).
400 (Bad Request) Die Anforderung wurde schlecht formatiert. Der angegebene Untersuchungsinstanzbezeichner stimmte beispielsweise nicht mit dem erwarteten UID-Format überein, oder die angeforderte Transfersyntaxcodierung wird nicht unterstützt.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Die angegebene DICOM-Ressource konnte nicht gefunden werden, oder für gerenderte Anforderung enthielt die Instanz keine Pixeldaten.
406 (Not Acceptable) Der angegebene Accept Header wird nicht unterstützt, oder für gerenderte und transcodierte Anforderungen war die angeforderte Datei zu groß.
424 (Failed Dependency) Der DICOM-Dienst kann nicht auf eine Ressource zugreifen, von der sie abhängig ist, um diese Anforderung abzuschließen. Ein Beispiel ist ein Fehler beim Zugriff auf den verbundenen Data Lake-Speicher oder der Schlüsseltresor zur Unterstützung der vom Kunden verwalteten Schlüsselverschlüsselung.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Suche (QIDO-RS)

Mithilfe von Abfragen anhand der ID für DICOM Objects (QIDO) können Sie nach Studien, Datenreihen und Instanzen nach Attributen suchen.

Methode Pfad Beschreibung
Nach Studien suchen
GET .. /Studium?... Suchen nach Studien
Nach Datenreihen suchen
GET .. /Reihe?... Suchen nach Datenreihen
GET .. /studies/{study}/series?... Suchen nach Reihen in einer Studie
Suchen nach Instanzen
GET .. /Instanzen?... Suchen nach Instanzen
GET .. /studies/{study}/instances?... Suchen nach Beispielen in einer Studie
GET .. /studies/{study}/series/{series}/instances?... Suchen nach Instanzen in einer Reihe

Die folgende Accept Kopfzeile wird für die Suche unterstützt.

  • application/dicom+json

Suchänderungen von v1

Wenn in der v1-API und der Fortsetzung für v2 ein erweitertes Abfragetag Fehler aufweist, da mindestens eine der vorhandenen Instanzen einen Tagwert aufweist, der nicht indiziert werden konnte, werden nachfolgende Suchabfragen, die das erweiterte Abfragetag enthalten, wie in der Dokumentation beschrieben zurückgegebenerroneous-dicom-attributes. Tags (auch als Attribute bezeichnet) mit Validierungswarnungen von STOW-RS sind jedoch nicht in diesem Header enthalten. Wenn eine Speicheranforderung zu Überprüfungswarnungen für durchsuchbare Attribute zum Zeitpunkt der Speicherung der Instanz führt, werden diese Attribute möglicherweise nicht zum Suchen nach der gespeicherten Instanz verwendet. Alle durchsuchbaren Attribute , die bei der Überprüfung fehlgeschlagen sind, können jedoch Ergebnisse zurückgeben, wenn die Werte von Instanzen in derselben Studie oder Datenreihe überschrieben werden, die nach dem fehlgeschlagenen Attribut gespeichert werden, oder wenn die Werte bereits von einer vorherigen Instanz ordnungsgemäß gespeichert wurden. Wenn die Attributwerte nicht überschrieben werden, erzeugen sie keine Suchergebnisse.

Ein Attribut kann wie folgt korrigiert werden.

  • Löschen der gespeicherten Instanz und Hochladen einer neuen Instanz mit korrigierten Daten
  • Hochladen einer neuen Instanz in derselben Studie/Serie mit korrigierten Daten

Unterstützte Suchparameter

Die folgenden Parameter für jede Abfrage werden unterstützt:

Schlüssel Supportwerte Zulässige Anzahl Beschreibung
{attributeID}= {value} 0...N Suchen nach Attribut-/Wertabgleich in der Abfrage
includefield= {attributeID}
all		 0...N Die anderen Attribute, die in der Antwort zurückgegeben werden sollen. Sowohl öffentliche als auch private Tags werden unterstützt.
Weitere all Informationen finden Sie in der Suchantwort .
Wenn eine Mischung aus {attributeID} und all bereitgestellt wird, verwendet der Server standardmäßig all
limit= {value} 0..1 Ganzzahliger Wert, um die Anzahl der in der Antwort zurückgegebenen Werte zu begrenzen.
Der Wert kann zwischen dem Bereich 1 >= x <= 200 liegen. Standardmäßig auf 100 festgelegt
offset= {value} 0..1 Ergebnisse überspringen {value} .
Wenn ein Offset größer als die Anzahl der Suchergebnisse bereitgestellt wird, wird eine Antwort von 204 (keine Inhalte) zurückgegeben.
fuzzymatching= true / false 0..1 Wenn true fuzzy matching auf das PatientName-Attribut angewendet wird. Es führt eine Präfixwort-Übereinstimmung eines beliebigen Namensteils innerhalb des PatientName-Werts durch. Wenn "PatientName" beispielsweise "John^Doe" lautet, dann "joh", "do", "jo do", "Doe" und "John Doe" alle übereinstimmen. "ohn" stimmt jedoch nicht überein.

Durchsuchbare Attribute

Wir unterstützen die Suche nach den folgenden Attributen und Suchtypen.

Attributschlüsselwort Alle Studien Alle Serien Alle Instanzen Studienreihe Instanzen der Studie Instanzen der Studienreihe
StudyInstanceUID X X X
PatientName X X X
PatientID X X X
PatientBirthDate X X X
AccessionNumber X X X
ReferringPhysicianName X X X
StudyDate X X X
StudyDescription X X X
ModalitiesInStudy X X X
SeriesInstanceUID X X X X
Modality X X X X
PerformedProcedureStepStartDate X X X X
ManufacturerModelName X X X X
SOPInstanceUID X X X

Hinweis

Die Suche mit einer leeren Zeichenfolge für Attribute wird nicht unterstützt.

Suchabgleich

Wir unterstützen die folgenden übereinstimmenden Typen.

Suchtyp Unterstütztes Attribut Beispiel
Bereichsabfrage StudyDate/PatientBirthDate {attributeID}={value1}-{value2}. Für Datums-/Uhrzeitwerte unterstützen wir einen inklusiven Bereich auf dem Tag. Dieser Bereich ist zugeordnet attributeID >= {value1} AND attributeID <= {value2}. Wenn {value1} nicht angegeben, werden alle Vorkommen von Datums- und Uhrzeitangaben vor und einschließlich {value2} übereinstimmen. Ebenso werden, wenn {value2} nicht angegeben, alle Vorkommen und {value1} nachfolgende Datums-/Uhrzeiten übereinstimmen. Einer dieser Werte muss jedoch vorhanden sein. {attributeID}={value1}- und {attributeID}=-{value2} sind gültig, {attributeID}=- ist jedoch ungültig.
Genaue Übereinstimmung Alle unterstützten Attribute {attributeID}={value1}
Fuzzy Match PatientName, ReferringPhysicianName Entspricht einer beliebigen Komponente des Namens, die mit dem Wert beginnt.
UID-Listen-Übereinstimmung StudyInstanceUID Entspricht Studien, die durch die in der Liste angegebenen Werte identifiziert werden. Unterstützt Komma (,) oder einen umgekehrten Schrägstrich (\) als gültiges Trennzeichen. {attributeID}=1.2.3,5.6.7,8.9.0 gibt Details zurück, die allen Studien zugeordnet sind, sofern sie vorhanden sind.

Attribut-ID

Tags können auf verschiedene Arten für den Abfrageparameter codiert werden. Wir haben den Standard teilweise wie in PS3.18 6.7.1.1.1.1 definiert implementiert. Die folgenden Codierungen für ein Tag werden unterstützt.

Wert Beispiel
{group}{element} 0020000D
{dicomKeyword} StudyInstanceUID

Beispielabfragesuche für Instanzen:

../instances?Modality=CT&00280011=512&includefield=00280010&limit=5&offset=0

Suchantwort

Die Antwort ist ein Array von DICOM-Datasets. Je nach Ressource werden standardmäßig die folgenden Attribute zurückgegeben.

Standard-Studientags

Tag Attributname
(0008, 0020) StudyDate
(0008, 0050) AccessionNumber
(0008, 1030) StudyDescription
(0009, 0090) ReferringPhysicianName
(0010, 0010) PatientName
(0010, 0020) PatientID
(0010, 0030) PatientBirthDate
(0020, 000D) StudyInstanceUID

Standardserientags

Tag Attributname
(0008, 0060) Modality
(0008, 1090) ManufacturerModelName
(0020, 000E) SeriesInstanceUID
(0040, 0244) PerformedProcedureStepStartDate

Standardinstanztags

Tag Attributname
(0008, 0018) SOPInstanceUID

Wenn includefield=alldiese Attribute zusammen mit Standardattributen enthalten sind. Zusammen mit den Standardattributen enthält diese Liste eine vollständige Liste der Attribute, die auf jeder Ressourcenebene unterstützt werden.

Andere Studientags

Tag Attributname
(0008, 0005) SpecificCharacterSet
(0008, 0030) StudyTime
(0008, 0056) InstanceAvailability
(0008, 0201) TimezoneOffsetFromUTC
(0008, 0063) AnatomicRegionsInStudyCodeSequence
(0008, 1032) ProcedureCodeSequence
(0008, 1060) NameOfPhysiciansReadingStudy
(0008, 1080) AdmittingDiagnosesDescription
(0008, 1110) ReferencedStudySequence
(0010, 1010) PatientAge
(0010, 1020) PatientSize
(0010, 1030) PatientWeight
(0010, 2180) Occupation
(0010, 21B0) AdditionalPatientHistory
(0010, 0040) PatientSex
(0020, 0010) StudyID

Andere Reihentags

Tag Attributname
(0008, 0005) SpecificCharacterSet
(0008, 0201) TimezoneOffsetFromUTC
(0020, 0011) SeriesNumber
(0020, 0060) Lateralität
(0008, 0021) SeriesDate
(0008, 0031) SeriesTime
(0008, 103E) SeriesDescription
(0040, 0245) PerformedProcedureStepStartTime
(0040, 0275) RequestAttributesSequence

Andere Instanztags

Tag Attributname
(0008, 0005) SpecificCharacterSet
(0008, 0016) SOPClassUID
(0008, 0056) InstanceAvailability
(0008, 0201) TimezoneOffsetFromUTC
(0020, 0013) InstanceNumber
(0028, 0010) Zeilen
(0028, 0011) Spalten
(0028, 0100) BitsAllocated
(0028, 0008) NumberOfFrames

Die folgenden Attribute werden zurückgegeben.

  • Alle Abfrageparameter und UIDs der Übereinstimmung in der Ressourcen-URL
  • IncludeField Attribute, die auf dieser Ressourcenebene unterstützt werden
  • Wenn die Zielressource lautet All Series, Study werden auch Ebenenattribute zurückgegeben.
  • Wenn die Zielressource lautet All Instances, Study werden auch Attribute der Series Ebene zurückgegeben.
  • Wenn die Zielressource lautet Study's Instances, Series werden auch Ebenenattribute zurückgegeben.
  • NumberOfStudyRelatedInstances Das aggregierte Attribut wird auf Study Ebene includeFieldunterstützt.
  • NumberOfSeriesRelatedInstances Das aggregierte Attribut wird auf Series Ebene includeFieldunterstützt.

Suchantwortcodes

Die Abfrage-API gibt einen der folgenden Statuscodes in der Antwort zurück.

Code Beschreibung
200 (OK) Die Antwortnutzlast enthält alle übereinstimmenden Ressourcen.
204 (No Content) Die Suche wurde erfolgreich abgeschlossen, aber keine Ergebnisse zurückgegeben.
400 (Bad Request) Der Server konnte die Abfrage nicht ausführen, da die Abfragekomponente ungültig war. Der Antworttext enthält Details des Fehlers.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
414 (URI Too Long) Der URI hat die maximal unterstützte Länge von 8192 Zeichen überschritten.
424 (Failed Dependency) Der DICOM-Dienst kann nicht auf eine Ressource zugreifen, von der sie abhängig ist, um diese Anforderung abzuschließen. Ein Beispiel ist ein Fehler beim Zugriff auf den verbundenen Data Lake-Speicher oder der Schlüsseltresor zur Unterstützung der vom Kunden verwalteten Schlüsselverschlüsselung.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Hinweise

  • Abfragen mithilfe der TimezoneOffsetFromUTC (00080201) Abfrage werden nicht unterstützt.
  • Die Abfrage-API gibt nicht zurück 413 (request entity too large). Wenn der angeforderte Abfrageantwortgrenzwert außerhalb des zulässigen Bereichs liegt, wird eine ungültige Anforderung zurückgegeben. Alles, was innerhalb des zulässigen Bereichs angefordert wird, wird aufgelöst.
  • Wenn die Zielressource "Studie/Serie" ist, gibt es ein Potenzial für inkonsistente Metadaten auf Studien-/Reihenebene über mehrere Instanzen hinweg. Beispielsweise könnten zwei Instanzen unterschiedliche patientNamehaben. In diesem Fall gewinnen die neuesten Gewinne, und Sie können nur nach den neuesten Daten suchen.
  • Seitenergebnisse werden optimiert, um zuerst übereinstimmende Instanzen zurückzugeben, was möglicherweise zu doppelten Datensätzen auf nachfolgenden Seiten führt, wenn neuere Daten hinzugefügt wurden, die mit der Abfrage übereinstimmen.
  • Bei übereinstimmungen wird die Groß-/Kleinschreibung nicht beachtet, und bei PN VR-Typen wird keine Akzente beachtet.
  • Bei übereinstimmungen wird die Groß-/Kleinschreibung nicht beachtet, und bei anderen Zeichenfolgen-VR-Typen wird Akzent berücksichtigt.
  • Nur der erste Wert wird von einem einzelnen wertigen Datenelement indiziert, das falsch mehrere Werte aufweist.
  • Die Verwendung der Standardattribute oder das Einschränken der Anzahl der angeforderten Ergebnisse maximiert die Leistung.
  • Wenn ein Attribut mit NULL-Abstand gespeichert wurde, kann es mit oder ohne den NULL-Abstand in der URI-Codierung gesucht werden. Die abgerufenen Ergebnisse beziehen sich auf Attribute, die sowohl mit als auch ohne Nullabstand gespeichert werden.

Löschen

Diese Transaktion ist nicht Teil des offiziellen DICOMweb Standard. Es verwendet die DELETE-Methode, um Darstellungen von Studien, Reihen und Instanzen aus dem Speicher zu entfernen.

Methode Pfad Beschreibung
DELETE .. /studies/{study} Löschen Sie alle Instanzen für eine bestimmte Studie.
DELETE .. /studies/{study}/series/{series} Löschen Sie alle Instanzen für eine bestimmte Datenreihe innerhalb einer Studie.
DELETE .. /studies/{study}/series/{series}/instances/{instance} Löschen sie eine bestimmte Instanz innerhalb einer Datenreihe.

Parameter study, series, und instance entsprechen den DICOM-Attributen StudyInstanceUID, SeriesInstanceUID, bzw SopInstanceUID . entsprechen.

Es gibt keine Einschränkungen für den Kopfzeilen- oder Content-Type KopfzeilenAccept- oder Textkörperinhalt der Anforderung.

Hinweis

Nach einer Löschtransaktion können die gelöschten Instanzen nicht wiederhergestellt werden.

Antwortstatuscodes

Code Beschreibung
204 (No Content) Wenn alle SOP-Instanzen gelöscht werden.
400 (Bad Request) Die Anforderung wurde schlecht formatiert.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Wenn die angegebene Datenreihe in einer Studie nicht gefunden wurde oder die angegebene Instanz nicht innerhalb der Datenreihe gefunden wurde.
424 (Failed Dependency) Der DICOM-Dienst kann nicht auf eine Ressource zugreifen, von der sie abhängig ist, um diese Anforderung abzuschließen. Ein Beispiel ist ein Fehler beim Zugriff auf den verbundenen Data Lake-Speicher oder der Schlüsseltresor zur Unterstützung der vom Kunden verwalteten Schlüsselverschlüsselung.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Antwortnutzlast löschen

Der Antworttext ist leer. Der Statuscode ist die einzige nützliche Information, die zurückgegeben wird.

Worklist Service (UPS-RS)

Der DICOM-Dienst unterstützt die Push- und Pull-SOPs des Arbeitslistendiensts (UPS-RS). Dieser Dienst bietet Zugriff auf eine Arbeitsliste mit Workitems, die jeweils einen Unified Procedure Step (UPS) darstellt.

Im Gesamten steht die Variable {workitem} in einer URI-Vorlage für eine Workitem UID.

Verfügbare UPS-RS-Endpunkte umfassen:

Verb Pfad Beschreibung
POST {s}/workitems{? BetroffeneSOPInstanceUID} Erstellen eines Arbeitselements
POST {s}/workitems/{instance}{?transaction} Ein Arbeitselement aktualisieren
GET {s}/workitems{?query*} Suchen nach Arbeitselementen
GET {s}/workitems/{instance} Abrufen einer Arbeitsaufgabe
PUT {s}/workitems/{instance}/state Ändern des Arbeitsaufgabenstatus
POST {s}/workitems/{instance}/cancelrequest Arbeitsaufgabe abbrechen
POST {s}/workitems/{instance}/subscribers/{AETitle}{?deletionlock} Abonnement erstellen
POST {s}/workitems/1.2.840.10008.5.1.4.34.5/ Abonnement aussetzen
DELETE {s}/workitems/{instance}/subscribers/{AETitle} Löschen eines Abonnements
GET {s}/abonnenten/{AETitle} Öffnen des Abonnementkanals

Arbeitselement erstellen

Diese Transaktion verwendet die POST-Methode, um ein neues Workitem zu erstellen.

Methode Pfad Beschreibung
POST .. /workitems Erstellen Sie ein Arbeitselement.
POST .. /workitems? {workitem} Erstellt ein Workitem mit der angegebenen UID.

Wenn der URI nicht angegeben ist, muss das Nutzlast-Dataset das Workitem im SOPInstanceUID Attribut enthalten.

Die Accept Header und Content-Type Die Kopfzeilen sind in der Anforderung erforderlich und müssen beide den Wert application/dicom+jsonaufweisen.

Es gibt mehrere Anforderungen im Zusammenhang mit DICOM-Datenattributen im Kontext einer bestimmten Transaktion. Attribute müssen möglicherweise vorhanden sein, müssen nicht vorhanden sein, müssen leer sein oder nicht leer sein. Diese Anforderungen finden Sie in dieser Tabelle.

Hinweis

Obwohl die Referenztabelle besagt, dass die SOP-Instanz-UID nicht vorhanden sein sollte, ist diese Anleitung spezifisch für das DIMSE-Protokoll und wird in DICOMWeb anders behandelt. DIE SOP-Instanz-UID sollte im Dataset vorhanden sein, wenn nicht im URI.

Hinweis

Alle bedingte Anforderungscodes einschließlich 1C und 2C werden als optional behandelt.

Erstellen von Antwortstatuscodes

Code Beschreibung
201 (Created) Das Zielarbeitselement wurde erfolgreich erstellt.
400 (Bad Request) Es gab ein Problem mit der Anforderung. Die Anforderungsnutzlast erfüllte beispielsweise nicht die Anforderungen.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
409 (Conflict) Das Arbeitselement ist bereits vorhanden.
415 (Unsupported Media Type) Die bereitgestellte Version Content-Type wird nicht unterstützt.
424 (Failed Dependency) Der DICOM-Dienst kann nicht auf eine Ressource zugreifen, von der sie abhängig ist, um diese Anforderung abzuschließen. Ein Beispiel ist ein Fehler beim Zugriff auf den verbundenen Data Lake-Speicher oder der Schlüsseltresor zur Unterstützung der vom Kunden verwalteten Schlüsselverschlüsselung.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Erstellen der Antwortnutzlast

Eine Erfolgsantwort hat keine Nutzlast. Die Header und Antwortheader enthalten einen URI-Verweis auf das erstellte Workitem.The Location and Content-Location response headers contain a URI reference to the created Workitem.

Eine Fehlerantwortnutzlast enthält eine Meldung, die den Fehler beschreibt.

Absage anfordern

Diese Transaktion ermöglicht es dem Benutzer, den Abbruch eines nicht im Besitz befindlichen Workitems anzufordern.

Es gibt vier gültige Workitem-Status:

  • SCHEDULED
  • IN PROGRESS
  • CANCELED
  • COMPLETED

Diese Transaktion ist nur erfolgreich für Workitems im SCHEDULED Zustand. Jeder Benutzer kann den Besitz eines Workitem-Objekts geltend machen, indem er seine Transaktions-UID festlegt und seinen Zustand auf IN PROGRESSändert. Anschließend kann ein Benutzer das Workitem nur ändern, indem er die richtige Transaktions-UID bereitstellt. Während UPS Überwachungs- und Ereignis-SOP-Klassen definiert, mit denen Abbruchanforderungen und andere Ereignisse weitergeleitet werden können, implementiert dieser DICOM-Dienst diese Klassen nicht und sodass Abbruchanforderungen für Arbeitsaufgaben, die IN PROGRESS einen Fehler zurückgeben. Ein eigenes Workitem-Objekt kann über die Transaktion "Workitem State ändern" abgebrochen werden.

Methode Pfad Beschreibung
POST .. /workitems/{workitem}/cancelrequest Anfordern des Abbruchs eines geplanten Arbeitselements

Die Content-Type Kopfzeile ist erforderlich und muss den Wert application/dicom+jsonaufweisen.

Die Anforderungsnutzlast kann Aktionsinformationen enthalten, die im DICOM-Standard definiert sind.

Statuscodes für anforderungsabbruchsantwort

Code Beschreibung
202 (Accepted) Die Anforderung wurde vom Server akzeptiert, aber der Status "Zielarbeitselement" wurde noch nicht geändert.
400 (Bad Request) Es gab ein Problem mit der Syntax der Anforderung.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Das Zielarbeitselement wurde nicht gefunden.
409 (Conflict) Die Anforderung ist mit dem aktuellen Status des Zielarbeitselements inkonsistent. Beispielsweise befindet sich das Zielarbeitselement im SCHEDULED Oder COMPLETED Zustand.
415 (Unsupported Media Type) Die bereitgestellte Version Content-Type wird nicht unterstützt.
424 (Failed Dependency) Der DICOM-Dienst kann nicht auf eine Ressource zugreifen, von der sie abhängig ist, um diese Anforderung abzuschließen. Ein Beispiel ist ein Fehler beim Zugriff auf den verbundenen Data Lake-Speicher oder der Schlüsseltresor zur Unterstützung der vom Kunden verwalteten Schlüsselverschlüsselung.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Anforderungsabbruchantwortnutzlast

Eine Erfolgsantwort hat keine Nutzlast, und eine Fehlerantwortnutzlast enthält eine Meldung, die den Fehler beschreibt. Wenn sich die Workitem-Instanz bereits in einem abgebrochenen Zustand befindet, enthält die Antwort den folgenden HTTP-Warnungsheader: 299: The UPS is already in the requested state of CANCELED.

Arbeitselement abrufen

Diese Transaktion ruft ein Workitem-Objekt ab. Sie entspricht dem UPS DIMSE N-GET-Vorgang.

Referenzieren: https://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_11.5

Wenn das Arbeitselement auf dem Ursprungsserver vorhanden ist, wird das Arbeitselement in einem akzeptablen Medientyp zurückgegeben. Das zurückgegebene Workitem-Objekt enthält nicht das Transaktions-UID-Attribut (0008.1195). Dies ist erforderlich, um die Rolle des Attributs als Zugriffssperre beizubehalten.

Methode Pfad Beschreibung
GET .. /workitems/{workitem} Anforderung zum Abrufen eines Workitem-Objekts

Die Accept Kopfzeile ist erforderlich und muss den Wert application/dicom+jsonaufweisen.

Abrufen von Antwortstatuscodes für Arbeitselemente

Code Beschreibung
200 (OK) Die Workitem-Instanz wurde erfolgreich abgerufen.
400 (Ungültige Anforderung) Es gab ein Problem mit der Anforderung.
401 (Nicht autorisiert) Der Client ist nicht authentifiziert.
403 (Unzulässig) Der Benutzer ist nicht autorisiert.
404 (Nicht gefunden) Das Zielarbeitselement wurde nicht gefunden.
424 (Fehlgeschlagene Abhängigkeit) Der DICOM-Dienst kann nicht auf eine Ressource zugreifen, von der sie abhängig ist, um diese Anforderung abzuschließen. Ein Beispiel ist ein Fehler beim Zugriff auf den verbundenen Data Lake-Speicher oder der Schlüsseltresor zur Unterstützung der vom Kunden verwalteten Schlüsselverschlüsselung.
503 (Dienst nicht verfügbar) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Abrufen der Arbeitselementantwortnutzlast

  • Eine Erfolgsantwort weist eine einzelne Teilnutzlast auf, die das angeforderte Arbeitselement im ausgewählten Medientyp enthält.
  • Das zurückgegebene Workitem-Objekt darf nicht das Transaktions-UID-Attribut (0008, 1195) des Workitem enthalten, da dies nur dem Besitzer bekannt sein sollte.

Workitem aktualisieren

Diese Transaktion ändert Attribute eines vorhandenen Workitem-Objekts. Sie entspricht dem UPS DIMSE N-SET-Vorgang.

Referenzieren: https://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_11.6

Um ein Arbeitselement zu aktualisieren, das derzeit im SCHEDULED Zustand ist, ist das Transaction UID Attribut nicht vorhanden. Für ein Workitem-Objekt im IN PROGRESS Status muss die Anforderung die aktuelle Transaktions-UID als Abfrageparameter enthalten. Wenn sich das Workitem-Objekt bereits in den Zuständen COMPLETED befindet CANCELED , lautet 400 (Bad Request)die Antwort .

Methode Pfad Beschreibung
POST .. /workitems/{workitem}? {transaction-uid} Workitem-Transaktion aktualisieren

Die Content-Type Kopfzeile ist erforderlich und muss den Wert application/dicom+jsonaufweisen.

Die Anforderungsnutzlast enthält ein Dataset mit den Änderungen, die auf das Zielarbeitselement angewendet werden sollen. Wenn eine Sequenz geändert wird, muss die Anforderung alle Elemente in der Sequenz enthalten, nicht nur die zu ändernden Elemente. Wenn Sie mehrere Attribute als Gruppe aktualisieren müssen, aktualisieren Sie sie als mehrere Attribute in einer einzigen Anforderung, nicht als mehrere Anforderungen.

Es gibt viele Anforderungen im Zusammenhang mit DICOM-Datenattributen im Kontext einer bestimmten Transaktion. Attribute müssen möglicherweise vorhanden sein, müssen nicht vorhanden sein, müssen leer sein oder nicht leer sein. Diese Anforderungen finden Sie in dieser Tabelle.

Hinweis

Alle bedingte Anforderungscodes einschließlich 1C und 2C werden als optional behandelt.

Hinweis

Die Anforderung kann den Wert des Prozedurschrittstatus-Attributs (0074.1000) nicht festlegen. Der Prozedurschrittstatus wird mithilfe der Transaktion "Status ändern" oder der Anforderungsabbruchtransaktion verwaltet.

Aktualisieren der Statuscodes für die Transaktionsantwort von Workitem

Code Beschreibung
200 (OK) Das Zielarbeitselement wurde aktualisiert.
400 (Bad Request) Es gab ein Problem mit der Anforderung. Beispiel: (1) Das Zielarbeitselement befindet sich im COMPLETED Oder-Zustand CANCELED . (2) Die Transaktions-UID fehlt. (3) Die Transaktions-UID ist falsch. (4) Das Dataset entspricht nicht den Anforderungen.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Das Zielarbeitselement wurde nicht gefunden.
409 (Conflict) Die Anforderung ist mit dem aktuellen Status des Zielarbeitselements inkonsistent.
415 (Unsupported Media Type) Die bereitgestellte Version Content-Type wird nicht unterstützt.
424 (Failed Dependency) Der DICOM-Dienst kann nicht auf eine Ressource zugreifen, von der sie abhängig ist, um diese Anforderung abzuschließen. Ein Beispiel ist ein Fehler beim Zugriff auf den verbundenen Data Lake-Speicher oder der Schlüsseltresor zur Unterstützung der vom Kunden verwalteten Schlüsselverschlüsselung.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Workitem-Transaktionsantwortnutzlast aktualisieren

Der Ursprungsserver unterstützt Kopfzeilenfelder nach Bedarf in Tabelle 11.6.3-2.

Eine Erfolgsantwort hat entweder keine Nutzlast oder eine Nutzlast, die ein Statusberichtsdokument enthält.

Eine Nutzlast der Fehlerantwort kann einen Statusbericht enthalten, der Fehler, Warnungen oder andere nützliche Informationen beschreibt.

Arbeitselementstatus ändern

Diese Transaktion wird verwendet, um den Status eines Workitem-Objekts zu ändern. Es entspricht dem UPS DIMSE N-ACTION-Vorgang "UPS State ändern". Statusänderungen werden verwendet, um den Besitz, den Abschluss oder das Abbrechen eines Workitem-Objekts anzufordern.

Referenzieren: https://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_11.7

Wenn das Arbeitselement auf dem Ursprungsserver vorhanden ist, wird das Arbeitselement in einem akzeptablen Medientyp zurückgegeben. Das zurückgegebene Workitem-Objekt enthält nicht das Transaktions-UID-Attribut (0008,1195). Dies ist erforderlich, um die Rolle des Attributs wie hier beschrieben als Zugriffssperre beizubehalten.

Methode Pfad Beschreibung
PUT .. /workitems/{workitem}/state Arbeitselementstatus ändern

Die Accept Kopfzeile ist erforderlich und muss den Wert application/dicom+jsonaufweisen.

Die Anforderungsnutzlast enthält die Change UPS State Data Elements. Diese Datenelemente sind wie folgt.

  • Transaktions-UID (0008, 1195). Die Anforderungsnutzlast enthält eine Transaktions-UID. Der Benutzer-Agent erstellt die Transaktions-UID, wenn ein Übergang zum IN PROGRESS Status für ein bestimmtes Arbeitselement angefordert wird. Der Benutzer-Agent stellt die Transaktions-UID in nachfolgenden Transaktionen mit diesem Workitem bereit.
  • Prozedurschrittstatus (0074, 1000). Die rechtlichen Werte entsprechen dem angeforderten Zustandsübergang. Dies sind: IN PROGRESS, , COMPLETED, oder CANCELED.

Ändern der Antwortstatuscodes des Workitem-Zustands

Code Beschreibung
200 (OK) Die Workitem-Instanz wurde erfolgreich abgerufen.
400 (Bad Request) Die Anforderung kann aus einem der folgenden Gründe nicht ausgeführt werden: (1) Die Anforderung ist aufgrund des aktuellen Status des Zielarbeitselements ungültig. (2) Die Transaktions-UID fehlt. (3) Die Transaktions-UID ist falsch.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Das Zielarbeitselement wurde nicht gefunden.
409 (Conflict) Die Anforderung ist mit dem aktuellen Status des Zielarbeitselements inkonsistent.
424 (Failed Dependency) Der DICOM-Dienst kann nicht auf eine Ressource zugreifen, von der sie abhängig ist, um diese Anforderung abzuschließen. Ein Beispiel ist ein Fehler beim Zugriff auf den verbundenen Data Lake-Speicher oder der Schlüsseltresor zur Unterstützung der vom Kunden verwalteten Schlüsselverschlüsselung.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Change Workitem state response payload

  • Antworten umfassen die Kopfzeilenfelder, die in Abschnitt 11.7.3.2 angegeben sind.
  • Eine Erfolgsantwort hat keine Nutzlast.
  • Eine Nutzlast der Fehlerantwort kann einen Statusbericht enthalten, der Fehler, Warnungen oder andere nützliche Informationen beschreibt.

Sucharbeitselemente

Mit dieser Transaktion können Sie nach Attributen nach Workitems suchen.

Methode Pfad Beschreibung
GET .. /workitems? Nach Arbeitselementen suchen

Die folgende Accept Kopfzeile wird für die Suche unterstützt.

  • application/dicom+json

Unterstützte Suchparameter

Die folgenden Parameter für jede Abfrage werden unterstützt:

Schlüssel Supportwerte Zulässige Anzahl Beschreibung
{attributeID}= {value} 0...N Suchen Sie in der Abfrage nach Attribut-/Wertabgleich.
includefield= {attributeID}
all		 0...N Die anderen Attribute, die in der Antwort zurückgegeben werden sollen. Nur Attribute auf oberster Ebene können eingeschlossen werden – nicht Attribute, die Teil von Sequenzen sind. Sowohl öffentliche als auch private Tags werden unterstützt. Wann all wird angegeben. Weitere Informationen dazu, welche Attribute für jeden Abfragetyp zurückgegeben werden, finden Sie unter Search Response . Wenn eine Mischung aus {attributeID} und all bereitgestellt wird, verwendet der Server standardmäßig "alle".
limit= {value} 0...1 Ganzzahliger Wert, um die Anzahl der in der Antwort zurückgegebenen Werte zu begrenzen. Der Wert kann zwischen dem Bereich 1 >= x <= 200liegen. Standardmäßig auf 100.
offset= {value} 0...1 Überspringen Sie {value}-Ergebnisse. Wenn ein Offset größer als die Anzahl der Suchergebnisse bereitgestellt wird, wird eine 204 (no content) Antwort zurückgegeben.
fuzzymatching= true \ false 0...1 Wenn "true fuzzy matching" auf attribute mit der Person Name (PN) Value Representation (VR) angewendet wird. Es erfolgt eine Präfixwort-Übereinstimmung mit einem beliebigen Namensteil innerhalb dieser Attribute. Wenn es sich z. B. um John^Doeeine Übereinstimmung handelt, PatientName johdann , do, jo dound Doe John Doe alle übereinstimmungen. Stimmt jedoch ohn nicht überein.
Durchsuchbare Attribute

Wir unterstützen die Suche nach den folgenden Attributen.

Attributschlüsselwort
PatientName
PatientID
ReferencedRequestSequence.AccessionNumber
ReferencedRequestSequence.RequestedProcedureID
ScheduledProcedureStepStartDateTime
ScheduledStationNameCodeSequence.CodeValue
ScheduledStationClassCodeSequence.CodeValue
ScheduledStationGeographicLocationCodeSequence.CodeValue
ProcedureStepState
StudyInstanceUID

Hinweis

Die Suche mit einer leeren Zeichenfolge für Attribute wird nicht unterstützt.

Suchabgleich

Wir unterstützen die folgenden übereinstimmenden Typen.

Suchtyp Unterstütztes Attribut Beispiel
Bereichsabfrage ScheduledProcedureStepStartDateTime {attributeID}={value1}-{value2}. Für Datums-/Uhrzeitwerte unterstützen wir einen inklusiven Bereich auf dem Tag. Dieser Bereich ist zugeordnet attributeID >= {value1} AND attributeID <= {value2}. Wenn {value1} nicht angegeben, werden alle Vorkommen von Datums- und Uhrzeitangaben vor und einschließlich {value2} übereinstimmen. Ebenso werden, wenn {value2} nicht angegeben, alle Vorkommen und {value1} nachfolgende Datums-/Uhrzeiten übereinstimmen. Einer dieser Werte muss jedoch vorhanden sein. {attributeID}={value1}- und {attributeID}=-{value2} sind gültig, {attributeID}=- ist jedoch ungültig.
Genaue Übereinstimmung Alle unterstützten Attribute {attributeID}={value1}
Fuzzy Match PatientName Entspricht einer beliebigen Komponente des Namens, die mit dem Wert beginnt.
WildCard-Übereinstimmung PatientID,
ReferencedRequestSequence.AccessionNumber,
ReferencedRequestSequence.RequestedProcedureID,
ProcedureStepState,
ScheduledStationNameCodeSequence.CodeValue,
ScheduledStationClassCodeSequence.CodeValue,
ScheduledStationGeographicLocationCodeSequence.CodeValue		 Folgende Wildcardzeichen werden unterstützt:
* - Entspricht null oder mehr Zeichen. Beispiel: {attributeID}={val*} entspricht "val", "valid", "value", but not "evaluate".
? - Entspricht einem einzelnen Zeichen. Beispiel: {attributeID}={valu?} entspricht "Value", "valu1", aber nicht "valued" oder "valu"

Hinweis

Obwohl der vollständige Sequenzabgleich nicht unterstützt wird, wird die genaue Übereinstimmung der in einer Sequenz enthaltenen Attribute unterstützt.

Attribut-ID

Tags können auf viele Arten für den Abfrageparameter codiert werden. Wir haben den Standard teilweise wie in PS3.18 6.7.1.1.1.1 definiert implementiert. Die folgenden Codierungen für ein Tag werden unterstützt.

Wert Beispiel
{group}{element} 00100010
{dicomKeyword} PatientName

Beispielabfrage:

../workitems?PatientID=K123&0040A370.00080050=1423JS&includefield=00404005&limit=5&offset=0

Suchantwort

Die Antwort ist ein Array von 0...N DICOM-Datasets mit den folgenden zurückgegebenen Attributen.

  • Alle Attribute in DICOM PowerShell 3.4 Table CC.2.5-3 mit einem Rückgabeschlüsseltyp von 1 oder 2
  • Alle Attribute in DICOM PowerShell 3.4 Table CC.2.5-3 mit einem Rückgabeschlüsseltyp von 1C, für den die bedingten Anforderungen erfüllt sind
  • Alle anderen Workitem-Attribute, die als Übereinstimmungsparameter übergeben werden
  • Alle anderen Workitem-Attribute, die als includefield Parameterwerte übergeben werden

Suchantwortcodes

Die Abfrage-API gibt einen der folgenden Statuscodes in der Antwort zurück:

Code Beschreibung
200 (OK) Die Antwortnutzlast enthält alle übereinstimmenden Ressourcen.
206 (Partial Content) Die Antwortnutzlast enthält nur einige der Suchergebnisse, und der Rest kann über die entsprechende Anforderung angefordert werden.
204 (No Content) Die Suche wurde erfolgreich abgeschlossen, aber keine Ergebnisse zurückgegeben.
400 (Bad Request) Es gab ein Problem mit der Anforderung. Beispiel: Ungültige Abfrageparametersyntax. Der Antworttext enthält Details des Fehlers.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
424 (Failed Dependency) Der DICOM-Dienst kann nicht auf eine Ressource zugreifen, von der sie abhängig ist, um diese Anforderung abzuschließen. Ein Beispiel ist ein Fehler beim Zugriff auf den verbundenen Data Lake-Speicher oder der Schlüsseltresor zur Unterstützung der vom Kunden verwalteten Schlüsselverschlüsselung.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Zusätzliche Hinweise

Die Abfrage-API gibt nicht zurück 413 (request entity too large). Wenn der angeforderte Abfrageantwortgrenzwert außerhalb des zulässigen Bereichs liegt, wird eine ungültige Anforderung zurückgegeben. Alles, was innerhalb des zulässigen Bereichs angefordert wird, wird aufgelöst.

  • Seitenergebnisse sind so optimiert, dass zuerst übereinstimmungsgleiche Instanzen zurückgegeben werden, was zu doppelten Datensätzen auf nachfolgenden Seiten führen kann, wenn neuere Daten hinzugefügt wurden, die mit der Abfrage übereinstimmen.
  • Bei übereinstimmungen wird die Groß-/Kleinschreibung nicht beachtet, und bei PN VR-Typen wird die Groß-/Kleinschreibung nicht beachtet.
  • Bei übereinstimmungen wird die Groß-/Kleinschreibung beachtet, und bei anderen Zeichenfolgen-VR-Typen wird die Groß-/Kleinschreibung beachtet.
  • Wenn es ein Szenario gibt, in dem das Abbrechen eines Arbeitselements und das Abfragen desselben gleichzeitig erfolgt, schließt die Abfrage höchstwahrscheinlich das Arbeitselement aus, das aktualisiert wird, und der Antwortcode lautet 206 (Partial Content).

Hinweis

DICOM® ist die eingetragene Marke des National Electrical Manufacturers Association für seine Standards-Publikationen über die digitale Kommunikation medizinischer Informationen.