DICOM-Konformitätserklärung

Der Medical Imaging Server für DICOM unterstützt eine Teilmenge des DICOMweb-Standards™. Die Unterstützung umfasst Folgendes:

Darüber hinaus werden die folgenden nicht standardmäßigen API(s) 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

Weitere Informationen zum Angeben der Version beim Stellen von Anforderungen finden Sie in der Dokumentation zur API-Versionsverwaltung.

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

Präambelbereinigung

Der Dienst ignoriert die 128-Byte-Präambel der Datei 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äambelsicherheit sind. Dies bedeutet jedoch auch, dass Präambeln, die zum Codieren von Inhalten im dualen Format verwendet werden, z. B. TIFF, nicht mit dem Dienst verwendet werden können.

Studiendienst

Der Studiendienst ermöglicht Benutzern das Speichern, Abrufen und Suchen nach DICOM-Studien, Reihen und Instanzen. Wir haben die nicht standardmäßige Delete-Transaktion hinzugefügt, um einen vollständigen Ressourcenlebenszyklus zu ermöglichen.

Store (STOW-RS)

Diese Transaktion verwendet die POST-Methode, um Darstellungen von Studien, Reihen und Instanzen zu speichern, die in der Anforderungsnutzlast enthalten sind.

Methode Pfad BESCHREIBUNG
POST .. /Studien Speichern von Instanzen.
POST .. /studies/{study} Speichern von 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.

Die folgenden Accept Header für die Antwort werden unterstützt:

  • application/dicom+json

Die folgenden Content-Type Header werden unterstützt:

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

Hinweis

Der Server ersetzt keine Attribute, die mit vorhandenen Daten in Konflikt stehen. Alle Daten werden wie angegeben gespeichert.

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

  • StudyInstanceUID
  • SeriesInstanceUID
  • SOPInstanceUID
  • SOPClassUID
  • PatientID

Hinweis

Alle Bezeichner müssen zwischen 1 und 64 Zeichen lang sein und nur alphanumerische Zeichen oder die folgenden Sonderzeichen enthalten: ., -.

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

Es werden nur Übertragungssyntaxen mit expliziten Wertdarstellungen akzeptiert.

Statuscodes für Speicherantworten

Code BESCHREIBUNG
200 (OK) Alle SOP-Instanzen in der Anforderung wurden gespeichert.
202 (Accepted) Einige Instanzen in der Anforderung wurden gespeichert, aber bei anderen ist ein Fehler aufgetreten.
204 (No Content) In der Store-Transaktionsanforderung wurde kein Inhalt bereitgestellt.
400 (Bad Request) Die Anforderung war falsch formatiert. Der angegebene Bezeichner der Studieninstanz entsprach beispielsweise nicht dem erwarteten UID-Format.
401 (Unauthorized) Der Client wird nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
406 (Not Acceptable) Der angegebene Accept Header wird nicht unterstützt.
409 (Conflict) Keine der Instanzen in der Speichertransaktionsanforderung wurde gespeichert.
415 (Unsupported Media Type) Die bereitgestellte Content-Type wird nicht unterstützt.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Speicherantwortnutzlast

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

Tag Name BESCHREIBUNG
(0008, 1190) RetrieveURL Die Abruf-URL der Studie, wenn die StudyInstanceUID in der Store-Anforderung angegeben wurde und mindestens eine Instanz erfolgreich gespeichert wurde.
(0008, 1198) FailedSOPSequence Die Sequenz von Instanzen, die nicht gespeichert werden konnten.
(0008, 1199) ReferencedSOPSequence Die Sequenz der gespeicherten Instanzen.

Jedes Dataset im FailedSOPSequence verfügt über die folgenden Elemente (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.
(0074, 1048) FailedAttributesSequence Die Sequenz von ErrorComment enthält den Grund für jedes fehlerhafte Attribut.

Jedes Dataset im ReferencedSOPSequence weist die folgenden Elemente auf:

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, 1190) RetrieveURL Die Abruf-URL dieser Instanz auf dem DICOM-Server.

Eine Beispielantwort mit Accept Header application/dicom+json:

{
  "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"]
      }
    }]
  }
}

Speichern von Fehlerursachecodes

Code BESCHREIBUNG
272 Die Speichertransaktion hat die Instanz aufgrund eines allgemeinen Fehlers bei der Verarbeitung des Vorgangs nicht gespeichert.
43264 Fehler bei der Überprüfung der DICOM-Instanz.
43265 Die bereitgestellte Instanz StudyInstanceUID stimmte nicht mit der in der Speicheranforderung angegebenen StudyInstanceUID überein.
45070 Eine DICOM-Instanz mit demselben StudyInstanceUID, SeriesInstanceUIDund 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 Erstellungsversuch ist fehlgeschlagen, und der Bereinigungsprozess hatte noch keine Möglichkeit, eine Bereinigung durchzuführen. Löschen Sie zuerst die Instanz, bevor Sie versuchen, erneut zu erstellen.

Warnungsgrundcodes speichern

Code BESCHREIBUNG
45063 Ein DICOM-Instanzdatensatz stimmt nicht mit der SOP-Klasse überein. In der Studienspeichertransaktion (Abschnitt 10.5) wurde festgestellt, dass das Dataset während der Speicherung der Instanz nicht mit den Einschränkungen der SOP-Klasse übereinstimmte.

Speicherfehlercodes

Code BESCHREIBUNG
100 Die bereitgestellten Instanzattribute erfüllten nicht die Validierungskriterien.

Abrufen (WADO-RS)

Diese Abruftransaktion bietet Unterstützung zum Abrufen gespeicherter Studien, Serien, Instanzen und Frames nach Verweis.

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 Reihe ab.
GET .. /studies/{study}/series/{series}/metadata Ruft die Metadaten für alle Instanzen innerhalb einer Reihe ab.
GET .. /studies/{study}/series/{series}/instances/{instances} 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}/frames/{frames} Ruft einen oder mehrere Frames aus einer einzelnen Instanz ab. Um mehr als einen Frame anzugeben, verwenden Sie ein Komma, um jeden zurückzugebenden Frame zu trennen. Beispiel: /studies/1/series/2/instance/3/frames/4,5,6

Abrufen von Instanzen innerhalb einer Studie oder Einer Reihe

Die folgenden Accept Header werden für das Abrufen von Instanzen innerhalb einer Studie oder Einer Reihe 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

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

Frames abrufen

Die folgenden Accept Header werden für das 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

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 originale Datei muss eines der folgenden Formate aufweisen, damit die Transcodierung erfolgreich ist. Andernfalls schlägt die Transcodierung möglicherweise fehl:

  • 1.2.840.10008.1.2 (Little Endian Implizit)
  • 1.2.840.10008.1.2.1 (Little Endian Explicit)
  • 1.2.840.10008.1.2.2 (Explizite VR Big Endian)
  • 1.2.840.10008.1.2.4.50 (JPEG-Baselineprozess 1)
  • 1.2.840.10008.1.2.4.57 (JPEG Verlustfrei)
  • 1.2.840.10008.1.2.4.70 (JPEG Lossless Selection Value 1)
  • 1.2.840.10008.1.2.4.90 (JPEG 2000 Nur verlustfrei)
  • 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 Führt zu 406 Not Acceptable.

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

Der folgende Accept Header wird zum Abrufen von Metadaten für eine Studie, eine Reihe 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 Andere Byte
OD Sonstiges Double
OF Sonstiger Float
OL Andere Lange
OV Andere 64-Bit sehr lang
OW Anderes Wort
UN Unbekannt

Abrufen der Metadatencacheüberprüfung für (Studie, Serie 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. Wenn die Daten vorhanden sind, sind zwei Arten von Antworten möglich:

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

Abrufen von Antwortstatuscodes

Code BESCHREIBUNG
200 (OK) Alle angeforderten Daten wurden abgerufen.
304 (Not Modified) Die angeforderten Daten wurden seit der letzten Anforderung nicht mehr geändert. Der Inhalt wird in diesem Fall nicht dem Antworttext hinzugefügt. Weitere Informationen finden Sie im obigen Abschnitt Abrufen der Überprüfung des Metadatencaches (für Studie, Serie oder Instanz)..
400 (Bad Request) Die Anforderung war schlecht formatiert. Beispielsweise entsprach der angegebene Bezeichner der Studieninstanz nicht dem erwarteten UID-Format, oder die angeforderte Transfersyntaxcodierung wird nicht unterstützt.
401 (Unauthorized) Der Client wird nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Die angegebene DICOM-Ressource konnte nicht gefunden werden.
406 (Not Acceptable) Der angegebene Accept Header wird nicht unterstützt.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Suchen (QIDO-RS)

Abfrage basierend auf ID für DICOM-Objekte (QIDO) ermöglicht Ihnen die Suche nach Studien, Reihen und Instanzen nach Attributen.

Methode Pfad BESCHREIBUNG
Suche nach Studien
GET .. /Studien?... Nach Studien suchen
Nach Serie suchen
GET .. /Serie?... Nach Serien suchen
GET .. /studies/{study}/series?... Suchen nach Serien in einer Studie
Suchen nach Instanzen
GET .. /Instanzen?... Suchen nach Instanzen
GET .. /studies/{study}/instances?... Suchen nach Instanzen in einer Studie
GET .. /studies/{study}/series/{series}/instances?... Suchen nach Instanzen in einer Reihe

Die folgenden Accept Header werden für die Suche unterstützt:

  • application/dicom+json

Unterstützte Suchparameter

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

Schlüssel Supportwert(en) Zulässige Anzahl BESCHREIBUNG
{attributeID}= {value} 0...N Suchen Sie in der Abfrage nach Attribut-/Wertabgleich.
includefield= {attributeID}
all
0...N Die zusätzlichen Attribute, die in der Antwort zurückgegeben werden sollen. Sowohl öffentliche als auch private Tags werden unterstützt.
Wenn all angegeben wird, finden Sie unter Suchantwort weitere Informationen dazu, welche Attribute für jeden Abfragetyp zurückgegeben werden.
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. Der Standardwert ist 100.
offset= {value} 0..1 Ergebnisse überspringen {value} .
Wenn ein Offset bereitgestellt wird, der größer als die Anzahl der Suchabfrageergebnisse ist, wird eine Antwort 204 (ohne Inhalt) zurückgegeben.
fuzzymatching= true / false 0..1 Wenn auf das Attribut PatientName true fuzzy matching angewendet wird. Es führt eine Präfixwortgleichung eines beliebigen Namensteils innerhalb des Werts PatientName durch. Wenn PatientName beispielsweise "John^Doe" lautet, stimmen alle mit "joh", "do", "jo do", "Doe" und "John Doe" überein. "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 Studieninstanzen 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

Suchabgleich

Wir unterstützen die folgenden übereinstimmenden Typen.

Suchtyp Unterstütztes Attribut Beispiel
Bereichsabfrage StudyDate/PatientBirthDate {attributeID}={value1}-{value2}. Für Datums-/Uhrzeitwerte wird ein inklusiver Bereich für das Tag unterstützt. Dies wird zugeordnet attributeID >= {value1} AND attributeID <= {value2}. Wenn {value1} nicht angegeben ist, werden alle Vorkommen von Datums-/Uhrzeiten vor und einschließlich {value2} abgeglichen. Wenn nicht angegeben wird, werden auch {value2} alle Vorkommen von {value1} und nachfolgende Datums-/Uhrzeitangaben abgeglichen. 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 jeder Komponente des Namens, die mit dem -Wert beginnt.

Attribut-ID

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

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

Beispielabfrage bei der Suche nach Instanzen:

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

Suchantwort

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

Standardstudientags

Tag Attributname
(0008, 0005) SpecificCharacterSet
(0008, 0020) StudyDate
(0008, 0030) StudyTime
(0008, 0050) AccessionNumber
(0008, 0056) InstanceAvailability
(0008, 0090) ReferringPhysicianName
(0008, 0201) TimezoneOffsetFromUTC
(0010, 0010) PatientName
(0010, 0020) PatientID
(0010, 0030) PatientBirthDate
(0010, 0040) PatientSex
(0020, 0010) StudyID
(0020, 000D) StudyInstanceUID

Standardserientags

Tag Attributname
(0008, 0005) SpecificCharacterSet
(0008, 0060) Modality
(0008, 0201) TimezoneOffsetFromUTC
(0008, 103E) SeriesDescription
(0020, 000E) SeriesInstanceUID
(0040, 0244) PerformedProcedureStepStartDate
(0040, 0245) PerformedProcedureStepStartTime
(0040, 0275) RequestAttributesSequence

Standardinstanztags

Tag Attributname
(0008, 0005) SpecificCharacterSet
(0008, 0016) SOPClassUID
(0008, 0018) SOPInstanceUID
(0008, 0056) InstanceAvailability
(0008, 0201) TimezoneOffsetFromUTC
(0020, 0013) InstanceNumber
(0028, 0010) Rows
(0028, 0011) Columns
(0028, 0100) BitsAllocated
(0028, 0008) NumberOfFrames

Wenn includefield=all, sind die folgenden Attribute zusammen mit Standardattributen enthalten. Zusammen mit den Standardattributen ist dies die vollständige Liste der Attribute, die auf jeder Ressourcenebene unterstützt werden.

Zusätzliche Studientags

Tag Attributname
(0008, 1030) Study Description
(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

Zusätzliche Reihentags

Tag Attributname
(0020, 0011) SeriesNumber
(0020, 0060) Laterality
(0008, 0021) SeriesDate
(0008, 0031) SeriesTime

Zusammen mit den folgenden Attributen werden zurückgegeben:

  • Alle übereinstimmungen Abfrageparameter und UIDs in der Ressourcen-URL.
  • IncludeField Attribute, die auf dieser Ressourcenebene unterstützt werden.
  • Wenn die Zielressource ist All Series, Study werden auch Ebenenattribute zurückgegeben.
  • Wenn die Zielressource lautet All Instances, werden auch attribute Study und Series level zurückgegeben.
  • Wenn die Zielressource ist Study's Instances, Series werden auch Ebenenattribute zurückgegeben.
  • NumberOfStudyRelatedInstances Das aggregierte Attribut wird in Study der Ebene includeFieldunterstützt.
  • NumberOfSeriesRelatedInstances Das aggregierte Attribut wird in Series der 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 es wurden keine Ergebnisse zurückgegeben.
400 (Bad Request) Der Server konnte die Abfrage nicht ausführen, weil die Abfragekomponente ungültig war. Der Antworttext enthält Details zum Fehler.
401 (Unauthorized) Der Client wird nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Zusätzliche Hinweise

  • Abfragen mit dem TimezoneOffsetFromUTC (00080201) 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 "Study/Series" lautet, besteht die Möglichkeit für inkonsistente Metadaten auf Studien-/Reihenebene über mehrere Instanzen hinweg. Beispielsweise könnten zwei Instanzen unterschiedliche Patientennamen aufweisen. In diesem Fall gewinnt die neueste, und Sie können nur nach den neuesten Daten suchen.
  • Ausgelagerte Ergebnisse sind so optimiert, dass sie zuerst eine übereinstimmende neueste Instanz zurückgeben. Dies kann zu doppelten Datensätzen auf nachfolgenden Seiten führen, wenn neuere Daten hinzugefügt wurden, die der Abfrage entsprechen.
  • Beim Abgleich wird bei PN-VR-Typen zwischen Groß-/Kleinschreibung und Akzent unterschieden.
  • Beim Abgleich wird die Groß-/Kleinschreibung und der Akzent für andere Zeichenfolgen-VR-Typen beachtet.
  • Nur der erste Wert wird von einem einzelnen Datenelement mit einem Wert indiziert, das fälschlicherweise mehrere Werte aufweist.

Löschen

Diese Transaktion ist nicht Teil des offiziellen DICOMweb-Standards™. 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 Reihe innerhalb einer Studie.
Delete .. /studies/{study}/series/{series}/instances/{instance} Löschen Sie eine bestimmte Instanz innerhalb einer Reihe.

Die Parameter study, seriesund instance entsprechen den DICOM-Attributen StudyInstanceUID, SeriesInstanceUIDund SopInstanceUID bzw.

Es gibt keine Einschränkungen für den Inhalt des Headers, Content-Type der Kopfzeile oder des Textkörpers Accept der Anforderung.

Hinweis

Nach einer Delete-Transaktion können die gelöschten Instanzen nicht mehr wiederhergestellt werden.

Antwortstatuscodes

Code BESCHREIBUNG
204 (No Content) Wenn alle SOP-Instanzen gelöscht wurden.
400 (Bad Request) Die Anforderung war falsch formatiert.
401 (Unauthorized) Der Client wird nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Wenn die angegebene Reihe innerhalb einer Studie nicht gefunden wurde oder die angegebene Instanz nicht innerhalb der Reihe gefunden wurde.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Löschen der Antwortnutzlast

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

Worklist-Dienst (UPS-RS)

Der DICOM-Dienst unterstützt die Push- und Pull-SOPs des Worklist-Diensts (UPS-RS). Dieser Dienst bietet Zugriff auf eine Arbeitsliste, die Arbeitselemente enthält, die jeweils einen einheitlichen Prozedurschritt (Unified Procedure Step, UPS) darstellen.

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

Zu den verfügbaren UPS-RS-Endpunkten gehören:

Verb Pfad BESCHREIBUNG
POST {s}/workitems{? AffectedSOPInstanceUID} Erstellen eines Arbeitselements
POST {s}/workitems/{instance}{?transaction} Aktualisieren eines Arbeitselements
GET {s}/workitems{?query*} Suchen nach Arbeitselementen
GET {s}/workitems/{instance} Abrufen eines Arbeitselements
PUT {s}/workitems/{instance}/state Ändern des Arbeitselementstatus
POST {s}/workitems/{instance}/cancelrequest Abbrechen eines Arbeitselements
POST {s}/workitems/{instance}/subscribers/{AETitle}{?deletionlock} Erstellen des Abonnements
POST {s}/workitems/1.2.840.10008.5.1.4.34.5/ Abonnement anhalten
Delete {s}/workitems/{instance}/subscribers/{AETitle} Löschen eines Abonnements
GET {s}/abonnenten/{AETitle} Öffnen des Abonnementkanals

Erstellen eines Arbeitselements

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 nicht im URI angegeben, muss das Nutzlastdataset das Workitem im SOPInstanceUID Attribut enthalten.

Die Accept Header und Content-Type sind in der Anforderung erforderlich und müssen 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 müssen nicht leer sein. Diese Anforderungen finden Sie in dieser Tabelle.

Hinweise zu Datasetattributen:

  • UID der SOP-Instanz: Obwohl in der obigen Referenztabelle angegeben ist, dass die SOP-Instanz-UID nicht vorhanden sein sollte, ist diese Anleitung spezifisch für das DIMSE-Protokoll und wird in DICOMWeb™ unterschiedlich behandelt. DIE UID der SOP-Instanz sollte im Dataset vorhanden sein, wenn sie nicht im URI enthalten ist.
  • Codes für bedingte Anforderungen: Alle Codes für bedingte Anforderungen, 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 ist ein Problem mit der Anforderung aufgetreten. Beispielsweise erfüllte die Anforderungsnutzlast nicht die oben genannten Anforderungen.
401 (Unauthorized) Der Client wird nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
409 (Conflict) Das Arbeitselement ist bereits vorhanden.
415 (Unsupported Media Type) Die bereitgestellte Content-Type wird nicht unterstützt.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Erstellen einer Antwortnutzlast

Eine Erfolgsantwort hat keine Nutzlast. Die Location Antwortheader und Content-Location enthalten einen URI-Verweis auf das erstellte Workitem.

Eine Antwortnutzlast für Fehler enthält eine Meldung, die den Fehler beschreibt.

Anforderungsabbruch

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

Es gibt vier gültige Workitem-Zustände:

  • SCHEDULED
  • IN PROGRESS
  • CANCELED
  • COMPLETED

Diese Transaktion ist nur für Workitems im SCHEDULED Zustand erfolgreich. Jeder Benutzer kann den Besitz eines Workitems beanspruchen, indem er seine Transaktions-UID festlegt und seinen Zustand auf IN PROGRESSändert. Ab dann kann ein Benutzer das Workitem nur ändern, indem er die richtige Transaktions-UID bereitstellt. Während UPS Watch- und Event-SOP-Klassen definiert, die die Weiterleitung von Abbruchanforderungen und anderen Ereignissen ermöglichen, implementiert dieser DICOM-Dienst diese Klassen nicht, sodass Abbruchanforderungen für Arbeitselemente, die IN PROGRESS Fehler zurückgeben. Ein eigenes Workitem kann über die Transaktion Change Workitem State abgebrochen werden.

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

Der Content-Type -Header ist erforderlich und muss den Wert application/dicom+jsonaufweisen.

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

Anforderungsstatuscodes für die Antwort auf Abbruch

Code BESCHREIBUNG
202 (Accepted) Die Anforderung wurde vom Server akzeptiert, aber der Status des Zielarbeitselements hat sich noch nicht unbedingt geändert.
400 (Bad Request) Es ist ein Problem mit der Syntax der Anforderung aufgetreten.
401 (Unauthorized) Der Client wird nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Das Zielarbeitselement wurde nicht gefunden.
409 (Conflict) Die Anforderung ist nicht mit dem aktuellen Status des Zielarbeitselements vereinbar. Beispielsweise befindet sich das Zielarbeitselement im Status SCHEDULED oder COMPLETED .
415 (Unsupported Media Type) Die bereitgestellte Content-Type wird nicht unterstützt.

Antwortnutzlast für Anforderungsabbruch

Eine Erfolgsantwort enthält keine Nutzlast, und eine Antwortnutzlast für Fehler 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.

Abrufen des Arbeitselements

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

Weitere Informationen finden Sie unter: 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 darf nicht das Transaktions-UID-Attribut (0008,1195) enthalten. Dies ist erforderlich, um die Rolle dieses Attributs als Zugriffssperre beizubehalten.

Methode Pfad BESCHREIBUNG
GET .. /workitems/{workitem} Anforderung zum Abrufen eines Arbeitselements

Der Accept Header ist erforderlich und muss den Wert application/dicom+jsonaufweisen.

Abrufen von Arbeitselement-Antwortstatuscodes

Code BESCHREIBUNG
200 (OK) Die Workitem-Instanz wurde erfolgreich abgerufen.
400 (Bad Request) Es ist ein Problem mit der Anforderung aufgetreten.
401 (Unauthorized) Der Client wird nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Das Zielarbeitselement wurde nicht gefunden.

Abrufen der Arbeitselementantwortnutzlast

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

Aktualisieren von Arbeitsaufgaben

Diese Transaktion ändert attribute eines vorhandenen Workitems. Sie entspricht dem UPS DIMSE N-SET-Vorgang.

Weitere Informationen finden Sie unter: https://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_11.6

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

Methode Pfad BESCHREIBUNG
POST .. /workitems/{workitem}? {transaction-uid} Aktualisieren der Workitem-Transaktion

Der Content-Type -Header 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. Beim Ändern einer Sequenz muss die Anforderung alle Elemente in der Sequenz enthalten, nicht nur die zu ändernden Elemente. Wenn mehrere Attribute als Gruppe aktualisiert werden müssen, führen Sie dies als mehrere Attribute in einer einzelnen Anforderung und nicht als mehrere Anforderungen aus.

Es gibt eine Reihe von 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 müssen nicht leer sein. Diese Anforderungen finden Sie in dieser Tabelle.

Hinweise zu Datasetattributen:

  • Codes für bedingte Anforderungen: Alle Codes für bedingte Anforderungen, einschließlich 1C und 2C, werden als optional behandelt.

  • Die Anforderung kann den Wert des Attributs Prozedurschrittstatus (0074,1000) nicht festlegen. Der Status des Prozedurschritts wird mithilfe der Transaktion Status ändern oder der Anforderungsabbruchtransaktion verwaltet.

Aktualisieren von Statuscodes für Workitem-Transaktionsantworten

Code BESCHREIBUNG
200 (OK) Das Zielarbeitselement wurde aktualisiert.
400 (Bad Request) Es ist ein Problem mit der Anforderung aufgetreten. Beispiel: (1) Das Zielarbeitselement befand sich im COMPLETED Zustand oder CANCELED . (2) Die Transaktions-UID fehlt. (3) Die Transaktions-UID ist falsch. (4) Das Dataset entsprach nicht den Anforderungen.
401 (Unauthorized) Der Client wird nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Das Zielarbeitselement wurde nicht gefunden.
409 (Conflict) Die Anforderung ist nicht mit dem aktuellen Status des Zielarbeitselements vereinbar.
415 (Unsupported Media Type) Die bereitgestellte Content-Type wird nicht unterstützt.

Aktualisieren der Workitem-Transaktionsantwortnutzlast

Der Ursprungsserver muss Headerfelder unterstützen, wie in Tabelle 11.6.3-2 erforderlich.

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

Eine Antwortnutzlast für Fehler kann einen Statusbericht enthalten, der alle Fehler, Warnungen oder andere nützliche Informationen beschreibt.

Ändern des Arbeitselementstatus

Diese Transaktion wird verwendet, um den Status eines Arbeitselements zu ändern. Sie entspricht dem UPS DIMSE N-ACTION-Vorgang "UPS-Zustand ändern". Zustandsänderungen werden verwendet, um den Besitz eines Workitems anzufordern, abzuschließen oder abzubrechen.

Weitere Informationen finden Sie unter: 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 darf nicht das Transaktions-UID-Attribut (0008,1195) enthalten. Dies ist erforderlich, um die Rolle dieses Attributs als Zugriffssperre beizubehalten, wie hier beschrieben.

Methode Pfad BESCHREIBUNG
PUT .. /workitems/{workitem}/state Ändern des Arbeitselementstatus

Der Accept -Header ist erforderlich und muss den Wert application/dicom+jsonaufweisen.

Die Anforderungsnutzlast muss die Change UPS State Data Elements enthalten. Diese Datenelemente sind:

  • Transaktions-UID (0008, 1195) Die Anforderungsnutzlast muss eine Transaktions-UID enthalten. Der Benutzer-Agent erstellt die Transaktions-UID, wenn er einen Übergang zum IN PROGRESS Zustand für ein bestimmtes Workitem anfordert. Der Benutzer-Agent stellt diese Transaktions-UID in nachfolgenden Transaktionen mit diesem Workitem bereit.
  • Prozedurschrittstatus (0074, 1000) Die gesetzlichen Werte entsprechen dem angeforderten Zustandsübergang. Sie sind: IN PROGRESS, COMPLETEDoder CANCELED.

Ändern des Statusstatus des Arbeitselementzustands

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 Zustands des Zielarbeitselements ungültig. (2) Die Transaktions-UID fehlt. (3) Die Transaktions-UID ist falsch.
401 (Unauthorized) Der Client wird nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Das Zielarbeitselement wurde nicht gefunden.
409 (Conflict) Die Anforderung ist nicht mit dem aktuellen Status des Zielarbeitselements vereinbar.

Ändern der Antwortnutzlast des Arbeitselementzustands

  • Antworten enthalten die in Abschnitt 11.7.3.2 angegebenen Kopfzeilenfelder.
  • Eine Erfolgsantwort darf keine Nutzlast aufweisen.
  • Eine Antwortnutzlast für Fehler kann einen Statusbericht enthalten, der alle Fehler, Warnungen oder andere nützliche Informationen beschreibt.

Suchen von Arbeitselementen

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

Methode Pfad BESCHREIBUNG
GET .. /workitems? Suchen nach Arbeitselementen

Die folgenden Accept Header werden für die Suche unterstützt:

application/dicom+json

Unterstützte Suchparameter

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

Schlüssel Support Werte Zulässig Anzahl BESCHREIBUNG
{attributeID}= {value} 0...N Suchen Sie in der Abfrage nach Attribut-/Wertabgleich.
includefield= {attributeID} all 0...N Die zusätzlichen Attribute, die in der Antwort zurückgegeben werden sollen. Es können nur Attribute der obersten Ebene angegeben werden, um eingeschlossen zu werden , nicht Attribute, die Teil von Sequenzen sind. Sowohl öffentliche als auch private Tags werden unterstützt. Wenn all bereitgestellt wird, finden Sie unter Suchantwort weitere Informationen dazu, welche Attribute für jeden Abfragetyp zurückgegeben werden. 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 liegen 1 >= x <= 200. Der Standardwert ist 100.
offset= {value} 0...1 Überspringen Sie {value}-Ergebnisse. Wenn ein Offset bereitgestellt wird, das größer als die Anzahl der Suchergebnisse von Suchabfragen ist, wird eine 204 (no content) Antwort zurückgegeben.
fuzzymatching= true/false 0...1 Wenn ein true-Fuzzyabgleich auf alle Attribute mit der Wertdarstellung des Personennamens (Person Name, PN) angewendet wird. Es wird eine Präfixwort-Übereinstimmung eines beliebigen Namensteils innerhalb dieser Attribute ausgeführt. Wenn PatientName z. B. ist John^Doe, johstimmen , do, jo do, Doe und John Doe alle überein. Entspricht jedoch ohnnicht .
Durchsuchbare Attribute

Wir unterstützen die Suche nach diesen Attributen:

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

Wir unterstützen diese Abgleichstypen:

Suchtyp Unterstütztes Attribut Beispiel
Bereichsabfrage Scheduled​Procedure​Step​Start​Date​Time {attributeID}={value1}-{value2}. Für Datums-/Uhrzeitwerte unterstützen wir einen inklusiven Bereich für das Tag. Dies wird UND attributeID <= {value2}zugeordnetattributeID >= {value1}. Wenn {value1} nicht angegeben ist, werden alle Vorkommen von Datums-/Uhrzeitangaben vor und einschließlich {value2} abgeglichen. Ebenso werden, wenn {value2} nicht angegeben ist, alle Vorkommen von {value1} und nachfolgende Datums-/Uhrzeitangaben abgeglichen. 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-Übereinstimmung PatientName Entspricht einer beliebigen Komponente des Namens, die mit dem -Wert beginnt.

Hinweis

Obwohl wir keinen vollständigen Sequenzabgleich unterstützen, unterstützen wir die genaue Übereinstimmung mit den oben aufgeführten Attributen, die in einer Sequenz enthalten sind.

Attribut-ID

Tags können auf verschiedene Arten für den Abfrageparameter codiert werden. Wir haben den Standard teilweise implementiert, wie in PS3.18 6.7.1.1.1 definiert. 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 Attributen, die zurückgegeben werden:

  • Alle Attribute in DICOM PowerShell 3.4 Tabelle CC.2.5-3 mit einem Rückgabeschlüsseltyp von 1 oder 2
  • Alle Attribute in DICOM PowerShell 3.4 Tabelle CC.2.5-3 mit dem Rückgabeschlüsseltyp 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 es wurden keine Ergebnisse zurückgegeben.
400 (Bad Request) Das war ein Problem mit der Anforderung. Beispiel: Ungültige Abfrageparametersyntax. Der Antworttext enthält Details zum Fehler.
401 (Unauthorized) Der Client wird nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Weitere 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.

  • Ausgelagerte Ergebnisse sind so optimiert, dass sie zuerst eine übereinstimmende neueste Instanz zurückgeben. Dies kann zu doppelten Datensätzen auf nachfolgenden Seiten führen, wenn neuere Daten hinzugefügt wurden, die der Abfrage entsprechen.
  • Beim Abgleich wird die Groß-/Kleinschreibung und der Akzent für PN-VR-Typen nicht beachtet.
  • Beim Abgleich wird die Groß-/Kleinschreibung und der Akzent für andere Zeichenfolgen-VR-Typen nicht beachtet.
  • Wenn es ein Szenario gibt, in dem das Abbrechen eines Workitems und dasselbe Abfragen gleichzeitig erfolgen, schließt die Abfrage höchstwahrscheinlich das Workitem aus, das aktualisiert wird, und der Antwortcode lautet 206 (Partial Content).

Nächste Schritte

Weitere Informationen finden Sie unter