DICOM-Konformitätserklärung für Azure Health Data Services (2023)

Artikel
01/28/2023
24Minuten Lesedauer

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

Studiendienst
- Store (STOW-RS)
- Abrufen (WADO-RS)
- Suche (QIDO-RS)
- Löschen
Worklist-Dienst (UPS Push and Pull SOPs)
- Erstellen eines Arbeitselements
- Abrufen des Arbeitselements
- Aktualisieren von Arbeitsaufgaben
- Ändern des Arbeitselementstatus
- Anforderungsabbruch
- Suchen von Arbeitselementen

Darüber hinaus werden die folgenden nicht standardmäßigen API(s) unterstützt:

Änderungsfeed
Erweiterte Abfragetags

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:

Speichern von Fehlerursachencodes

Code	BESCHREIBUNG
`272`	Die Speichertransaktion hat die Instanz aufgrund eines allgemeinen Fehlers bei der Verarbeitung des Vorgangs nicht gespeichert.
`43264`	Bei der Überprüfung der DICOM-Instanz ist ein Fehler aufgetreten.
`43265`	Die bereitgestellte Instanz `StudyInstanceUID` stimmte nicht mit der in der Speicheranforderung angegebenen `StudyInstanceUID` überein.
`45070`	Eine DICOM-Instanz mit demselben `StudyInstanceUID`, `SeriesInstanceUID`und `SopInstanceUID` wurde bereits gespeichert. Wenn Sie den Inhalt aktualisieren möchten, löschen Sie zuerst diese Instanz.
`45071`	Eine DICOM-Instanz wird von einem anderen Prozess erstellt, oder der vorherige Versuch, zu erstellen, ist fehlgeschlagen, und der Bereinigungsprozess hatte noch keine Chance, eine Bereinigung durchzuführen. Löschen Sie zuerst die -Instanz, bevor Sie versuchen, erneut zu erstellen.

Warnungsursachencodes speichern

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 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 für das Abrufen gespeicherter Studien, Reihen, 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/{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}/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 Reihe

Die folgenden Accept Header werden zum Abrufen von Instanzen innerhalb einer Studie oder einer Reihe unterstützt:

multipart/related; type="application/dicom"; transfer-syntax=*
multipart/related; type="application/dicom"; (Wenn keine Transfersyntax 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 Übertragungssyntax nicht angegeben ist, 1.2.840.10008.1.2.1 wird als Standard verwendet)
multipart/related; type="application/dicom" (wenn die Übertragungssyntax 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

Abrufen von Frames

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 Übertragungssyntax 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 Übertragungssyntax 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 Originaldatei 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 Implicit)
1.2.840.10008.1.2.1 (Little Endian Explicit)
1.2.840.10008.1.2.2 (Explizites 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 (NUR JPEG 2000 Verlustfrei)
1.2.840.10008.1.2.4.91 (JPEG 2000)
1.2.840.10008.1.2.5 (RLE Lossless)

Ein nicht unterstützter transfer-syntax Führt zu 406 Not Acceptable.

Abrufen von Metadaten (für Studien, Reihen oder Instanzen)

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	Anderes Byte
OD	Sonstiges Double
OF	Andere Float-Vorgänge
OL	Andere Lange
OV	Andere 64-Bit-Sehr lang
OW	Anderes Wort
UN	Unbekannt

Abrufen der Überprüfung des Metadatencaches für (Studie, Serie oder Instanz)

Die Cachevalidierung 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 die gleichen 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 dem aktualisierten ETag gesendet. Erforderliche Daten werden auch als Teil des Texts 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. In diesem Fall wird dem Antworttext kein Inhalt 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 falsch formatiert. Beispielsweise entsprach der angegebene Bezeichner der Studieninstanz nicht dem erwarteten UID-Format, oder die angeforderte Übertragungssyntaxcodierung 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.

Suche (QIDO-RS)

Abfragen basierend auf DER ID für DICOM-Objekte (QIDO) ermöglichen es Ihnen, nach Studien, Reihen und Instanzen nach Attributen zu suchen.

Methode	Pfad	BESCHREIBUNG
Suche nach Studien
GET	.. /Studien?...	Suchen nach Studien
Nach Serie suchen
GET	.. /Serie?...	Nach Serie 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	Unterstützungswert(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 `all`der Server standardmäßig .
`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	Überspringen Sie `{value}` Ergebnisse. Wenn ein Offset bereitgestellt wird, das größer als die Anzahl der Suchergebnisse von Suchabfragen ist, wird die Antwort 204 (kein Inhalt) zurückgegeben.
`fuzzymatching=`	`true` / `false`	0..1	Wenn der Fuzzyabgleich true auf das Attribut PatientName angewendet wird. Es wird eine Präfixwort-Übereinstimmung eines beliebigen Namensteils innerhalb des Werts "PatientName" bewirkt. Wenn PatientName z. B. "John^Doe" lautet, stimmen "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	Studie	Reihen	Instanz
`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
`Modality`		X	X
`PerformedProcedureStepStartDate`		X	X
`SOPInstanceUID`			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 Serientags

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

Zusammen mit den folgenden Attributen werden zurückgegeben:

Alle Abfrageparameter und UIDs in der Ressourcen-URL stimmen überein.
IncludeField Attribute, die auf dieser Ressourcenebene unterstützt werden.
Wenn die Zielressource ist All Series, Study werden auch Ebenenattribute zurückgegeben.
Wenn die Zielressource ist All Instances, werden auch Attribute Study und Series der Ebene zurückgegeben.
Wenn die Zielressource ist Study's Instances, Series werden auch Ebenenattribute zurückgegeben.
NumberOfStudyRelatedInstances Aggregiertes Attribut wird in Study der Ebene includeFieldunterstützt.
NumberOfSeriesRelatedInstances Aggregiertes 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 keine Ergebnisse zurückgegeben.
`400 (Bad Request)`	Der Server konnte die Abfrage nicht ausführen, da die Abfragekomponente ungültig war. Antworttext enthält Details des Fehlers.
`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 die angeforderte Abfrageantwortgrenze 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, besteht das Potenzial für inkonsistente Metadaten auf Studien-/Reihenebene über mehrere Instanzen hinweg. Beispielsweise könnten zwei Instanzen unterschiedliche patientName aufweisen. In diesem Fall gewinnt das neueste, und Sie können nur nach den neuesten Daten suchen.
Ausgelagerte Ergebnisse sind so optimiert, dass sie zuerst übereinstimmende neueste Instanz zurückgeben. Dies kann zu doppelten Datensätzen auf nachfolgenden Seiten führen, wenn neuere Daten, die der Abfrage entsprechen, hinzugefügt wurden.
Beim Abgleich wird für PN-VR-Typen die Groß-/Kleinschreibung und der Akzent berücksichtigt.
Beim Abgleich wird die Groß-/Kleinschreibung beachtet und der Akzent für andere Zeichenfolgen-VR-Typen beachtet.
Nur der erste Wert wird von einem einzelnen wertigen Datenelement 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, Serien 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/{instances}	Löschen Sie eine bestimmte Instanz innerhalb einer Reihe.

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

Es gibt keine Einschränkungen für den Header-, Content-Type Header- oder Textinhalt der Accept Anforderung.

Hinweis

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

Antwortstatuscodes

Code	BESCHREIBUNG
`204 (No Content)`	Wenn alle SOP-Instanzen gelöscht wurden.
`400 (Bad Request)`	Die Anforderung war schlecht formatiert.
`401 (Unauthorized)`	Der Client wird nicht authentifiziert.
`403 (Forbidden)`	Der Benutzer ist nicht autorisiert.
`404 (Not Found)`	Wenn die angegebene Reihe nicht innerhalb einer Studie 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.

Antwortnutzlast löschen

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

Arbeitslistendienst (UPS-RS)

Der DICOM-Dienst unterstützt die Push- und Pull-SOPs des Worklist Service (UPS-RS). Dieser Dienst bietet Zugriff auf eine Arbeitsliste, die Arbeitselemente enthält, die jeweils einen einheitlichen Prozedurschritt (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{? BetroffeneSOPInstanceUID}	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 Arbeitselementzustands
POST	{s}/workitems/{instance}/cancelrequest	Arbeitselement abbrechen
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}	Abonnementkanal öffnen

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 über den Wert verfügen application/dicom+json.

Es gibt mehrere Anforderungen im Zusammenhang mit DICOM-Datenattributen im Kontext einer bestimmten Transaktion. Attribute müssen vorhanden sein, müssen nicht vorhanden sein, müssen leer sein oder 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 nicht im URI vorhanden 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 gab ein Problem mit der Anforderung. 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 erfolgreiche Antwort 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.

Stornierung anfordern

Diese Transaktion ermöglicht es dem Benutzer, die Kündigung eines nicht im Besitz befindlichen Workitems anzufordern.

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

SCHEDULED
IN PROGRESS
CANCELED
COMPLETED

Diese Transaktion wird nur für Workitems im SCHEDULED Zustand erfolgreich ausgeführt. Jeder Benutzer kann den Besitz eines Arbeitselements beanspruchen, indem er seine Transaktions-UID festlegt und seinen Status auf IN PROGRESSändert. Ab dann kann ein Benutzer das Workitem nur noch ändern, indem er die richtige Transaktions-UID bereitstellt. Während UPS Überwachungs- und Ereignis-SOP-Klassen definiert, die die Weiterleitung von Abbruchanforderungen und anderen Ereignissen ermöglichen, implementiert dieser DICOM-Dienst diese Klassen nicht. Daher werden IN PROGRESS Abbruchanforderungen für Arbeitselemente zurückgegeben, die einen Fehler zurückgeben. Ein eigenes Arbeitselement 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 über den Wert verfügen application/dicom+json.

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

Statuscodes für Anforderungsabbruchantworten

Code	BESCHREIBUNG
`202 (Accepted)`	Die Anforderung wurde vom Server akzeptiert, aber der Zielarbeitselementstatus hat sich noch nicht unbedingt geändert.
`400 (Bad Request)`	Es gab ein Problem mit der Syntax der Anforderung.
`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 mit dem aktuellen Zustand des Zielarbeitselements inkonsistent. 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 erfolgreiche Antwort hat 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.

Workitem abrufen

Diese Transaktion ruft ein Arbeitselement 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 Attribut Transaction UID (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 über den Wert verfügen application/dicom+json.

Abrufen von Arbeitselementantwortstatuscodes

Code	BESCHREIBUNG
`200 (OK)`	Die Workitem-Instanz wurde erfolgreich abgerufen.
`400 (Bad Request)`	Es gab ein Problem mit der Anforderung.
`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 weist eine einzelne Teilnutzlast auf, die das angeforderte Arbeitselement im ausgewählten Medientyp enthält.
Das zurückgegebene Arbeitselement darf nicht das Attribut Transaction UID (0008, 1195) des Arbeitselements enthalten, da dies nur dem Besitzer bekannt sein sollte.

Aktualisieren von Arbeitsaufgaben

Diese Transaktion ändert die 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 Arbeitselement 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}	Workitem-Transaktion aktualisieren

Der Content-Type Header ist erforderlich und muss über den Wert verfügen application/dicom+json.

Die Anforderungsnutzlast enthält ein Dataset mit den Änderungen, die auf das Workitem-Ziel 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 vorhanden sein, müssen nicht vorhanden sein, müssen leer sein oder nicht leer sein. Diese Anforderungen finden Sie in dieser Tabelle.

Aktualisieren von Arbeitselementtransaktionsantwortstatuscodes

Code	BESCHREIBUNG
`200 (OK)`	Das Zielarbeitselement wurde aktualisiert.
`400 (Bad Request)`	Es gab ein Problem mit der Anforderung. Beispiel: (1) Das Zielarbeitselement hatte den `COMPLETED` Status 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 mit dem aktuellen Zustand des Zielarbeitselements inkonsistent.
`415 (Unsupported Media Type)`	Die bereitgestellte `Content-Type` wird nicht unterstützt.

Aktualisieren der Nutzlast der Workitem-Transaktionsantwort

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

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

Eine Nutzlast der Fehlerantwort 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 Arbeitselements zu beanspruchen, abzuschließen oder zu stornieren.

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

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

Der Accept Header ist erforderlich und muss über den Wert verfügen application/dicom+json.

Die Anforderungsnutzlast muss die Änderungs-UPS-Zustandsdatenelemente enthalten. Diese Datenelemente sind:

Transaktion 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 von Statuscodes für den Arbeitselementstatus

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 mit dem aktuellen Zustand des Zielarbeitselements inkonsistent.

Ändern der Antwortnutzlast des Arbeitselementzustands

Antworten enthalten die in Abschnitt 11.7.3.2 angegebenen Headerfelder.
Eine erfolgreiche Antwort darf keine Nutzlast aufweisen.
Eine Nutzlast der Fehlerantwort kann einen Statusbericht enthalten, der alle Fehler, Warnungen oder andere nützliche Informationen beschreibt.

Suchen nach Arbeitselementen

Mit dieser Transaktion können Sie nach Arbeitselementen 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
`{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, die eingeschlossen werden sollen , nicht Attribute, die Teil von Sequenzen sind. Sowohl öffentliche als auch private Tags werden unterstützt. Wenn `all` angegeben, 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`. Standardmäßig auf festgelegt `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`, `joh`stimmen , `do`, `jo do`, `Doe` und `John Doe` alle überein. Entspricht jedoch `ohn`nicht .

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	`ScheduledProcedureStepStartDateTime`	`{attributeID}={value1}-{value2}`. Für Datums-/Uhrzeitwerte unterstützen wir einen inklusiven Bereich für das Tag. Dies wird UND `attributeID <= {value2}`zugeordnet`attributeID >= {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

Übersicht über den DICOM-Dienst