- Artikel
- 23Minuten 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 Service (UPS Push and Pull SOPs)
- Workitem erstellen
- Workitem abrufen
- Aktualisieren von Arbeitsaufgaben
- Workitem-Status ändern
- Stornierung anfordern
- Sucharbeitselemente
Darüber hinaus werden die folgenden nicht standardmäßigen API(en) 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:
https://<service_url>/v<version>/studies
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-Auflistung.
Präamble Sanitization
Der Dienst ignoriert die 128-Byte-Dateivorschrift und ersetzt den Inhalt durch NULL-Zeichen. Dadurch wird sichergestellt, dass keine Dateien, die über den Dienst übergeben werden, anfällig für die böswillige Präambel-Sicherheitsanfälligkeit sind. Dies bedeutet jedoch auch, dass Präambeln, die zum Codieren von Dualformatinhalten wie TIFF verwendet werden, nicht mit dem Dienst verwendet werden können.
Studiendienst
Der Studiendienst ermöglicht Benutzern das Speichern, Abrufen und Suchen nach DICOM Studies, Series und Instances. 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, Datenreihen und Instanzen in der Anforderungsnutzlast zu speichern.
Methode | Pfad | BESCHREIBUNG |
---|---|---|
POST | .. /Studien | Speichern von Instanzen. |
POST | .. /studies/{study} | Speichern Sie Instanzen für eine bestimmte Studie. |
Der Parameter study
entspricht dem DICOM-Attribut "StudyInstanceUID". Wenn sie angegeben ist, wird jede Instanz, die nicht zur bereitgestellten Studie gehört, mit einem 43265
Warncode abgelehnt.
Die folgenden Accept
Kopfzeilen für die Antwort werden unterstützt:
application/dicom+json
Die folgenden Content-Type
Kopfzeilen 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, gespeichert zu werden:
StudyInstanceUID
SeriesInstanceUID
SOPInstanceUID
SOPClassUID
PatientID
Hinweis
Alle Bezeichner müssen zwischen 1 und 64 Zeichen lang sein und nur alpha numerische Zeichen oder die folgenden Sonderzeichen enthalten: .
, -
.
Jede gespeicherte Datei muss eine eindeutige Kombination aus StudyInstanceUID
, SeriesInstanceUID
und .SopInstanceUID
Der Warnungscode 45070
wird zurückgegeben, wenn eine Datei mit denselben Bezeichnern bereits vorhanden ist.
Es werden nur Syntaxen mit expliziten Wertdarstellungen übertragen.
Store-Antwortstatuscodes
Code | BESCHREIBUNG |
---|---|
200 (OK) | Alle SOP-Instanzen in der Anforderung wurden gespeichert. |
202 (Accepted) | Einige Instanzen in der Anforderung wurden gespeichert, andere sind jedoch fehlgeschlagen. |
204 (No Content) | In der Store-Transaktionsanforderung wurden keine Inhalte bereitgestellt. |
400 (Bad Request) | Die Anforderung wurde schlecht formatiert. Der angegebene Bezeichner der Studieninstanz hat z. B. nicht dem erwarteten UID-Format entsprechen. |
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 Version Content-Type wird nicht unterstützt. |
503 (Service Unavailable) | Der Dienst ist nicht verfügbar oder beschäftigt. Versuchen Sie es später noch mal. |
Speicherantwortnutzlast
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 Speicheranforderung bereitgestellt wurde und mindestens eine Instanz erfolgreich gespeichert wird. |
(0008, 1198) | FailedSOPSequence | Die Reihenfolge der Instanzen, die nicht gespeichert werden konnten. |
(0008, 1199) | ReferencedSOPSequence | Die Sequenz der gespeicherten Instanzen. |
Jedes Dataset in der FailedSOPSequence
Datei weist die folgenden Elemente auf (wenn die DICOM-Datei, die versucht, gespeichert zu werden, 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. |
Jedes Dataset in der ReferencedSOPSequence
Datei enthält die folgenden Elemente:
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 Abrufen-URL dieser Instanz auf dem DICOM-Server. |
Beispielantwort mit Accept
Kopfzeile 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"] } }] }}
Fehlerursachencodes speichern
Code | BESCHREIBUNG |
---|---|
272 | Die Speichertransaktion 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 angegebenen StudyInstanceUID Speicheranforderung. |
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, zu erstellen, ist fehlgeschlagen, und der Bereinigungsprozess hat noch keine Chance, zu bereinigen. Löschen Sie die Instanz zuerst, bevor Sie versuchen, erneut zu erstellen. |
Abrufen (WADO-RS)
Diese Abruftransaktion 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 in 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}/frames/{frames} | Ruft ein oder mehrere Frames aus einer einzelnen Instanz ab. Verwenden Sie zum Angeben mehrerer Frames ein Komma, um jeden Frame zu trennen. Beispiel: /studies/1/series/2/instance/3/frames/4,5,6 |
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 wird, 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
Kopfzeilen 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 wird,1.2.840.10008.1.2.1
wird als Standard verwendet)multipart/related; type="application/dicom"
(wenn die Transfersyntax nicht angegeben wird,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 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 wird,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 wird,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 sein, um die Transcodierung erfolgreich auszuführen; 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 (Expliziter 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)
Eine nicht unterstützte transfer-syntax
Datei führt zu 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
Das Abrufen von Metadaten gibt keine Attribute mit den folgenden Wertdarstellungen zurück:
VR-Name | BESCHREIBUNG |
---|---|
OB | Anderes Byte |
Od | Weiteres Double |
OF | Anderer Float |
Ol | Andere Lange |
Ov | Andere 64-Bit-Sehr lange |
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. Zwei Arten von Antworten sind möglich, wenn die Daten vorhanden sind:
- Die Daten wurden seit der letzten Anforderung nicht geändert:
HTTP 304 (Not Modified)
Die Antwort wird ohne Antworttext gesendet. - Die 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 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 geändert. Der Antworttext wird in diesem Fall nicht hinzugefügt. Weitere Informationen finden Sie im obigen Abschnitt Abrufen der Metadatencacheüberprüfung (für Studie, Serie oder Instanz). |
400 (Bad Request) | Die Anforderung wurde schlecht formatiert. Der angegebene Bezeichner der Studieninstanz hat beispielsweise nicht dem erwarteten UID-Format entsprechen, 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. |
406 (Not Acceptable) | Der angegebene Accept Header wird nicht unterstützt. |
503 (Service Unavailable) | Der Dienst ist nicht verfügbar oder beschäftigt. Versuchen Sie es später noch mal. |
Suche (QIDO-RS)
Die Abfrage basiert auf der ID für DICOM Objects (QIDO) ermöglicht es Ihnen, nach Studien, Reihen und Instanzen nach Attributen zu suchen.
Methode | Pfad | BESCHREIBUNG |
---|---|---|
Nach Studien suchen | ||
GET | .. /Studien?... | Nach Studien suchen |
Nach Datenreihen suchen | ||
GET | .. /Serie?... | Nach Datenreihen suchen |
GET | .. /studies/{study}/series?... | Suchen nach Datenreihen 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
Kopfzeilen 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-Wert(n) | Zulässige Anzahl | BESCHREIBUNG |
---|---|---|---|
{attributeID}= | {value} | 0...N | Suchen Sie nach Attribut-/Wertabgleich in der Abfrage. |
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. Wann all wird angegeben. Weitere Informationen dazu, welche Attribute für jeden Abfragetyp zurückgegeben werden, finden Sie in der Suchantwort .Wenn eine Mischung aus {attributeID} und all bereitgestellt wird, wird der Server standardmäßig verwendet all . |
limit= | {value} | 0..1 | Ganzzahliger Wert, um die Anzahl der in der Antwort zurückgegebenen Werte einzuschränken. 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 ist, 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 wird eine Präfixwort-Übereinstimmung eines beliebigen Namensteils innerhalb des PatientName-Werts ausführen. Wenn PatientName beispielsweise "John^Doe" ist, dann "joh", "do", "jo do", "do", "Doe" und "John Doe" alle übereinstimmen. "ohn" entspricht jedoch nicht. |
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 |
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 unterstützen wir einen inklusiven Bereich auf dem Tag. Dies wird zugeordnet attributeID >= {value1} AND attributeID <= {value2} . Wenn {value1} nicht angegeben ist, werden alle Vorkommen von Datums- und Uhrzeitangaben vor und einschließlich {value2} abgeglichen. Auch {value2} wenn nicht angegeben, werden alle Vorkommen und {value1} nachfolgenden Datums-/Uhrzeiten übereinstimmen. Eine 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. |
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 |
Beispielabfragensuche nach 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.
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
die folgenden Attribute zusammen mit Standardattributen enthalten sind. 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 diesen folgenden Attributen werden zurückgegeben:
- Alle Übereinstimmungsabfrageparameter und UIDs in der Ressourcen-URL.
IncludeField
Attribute, die auf dieser Ressourcenebene unterstützt werden.- Wenn die Zielressource
All Series
lautet,Study
werden auch Levelattribute zurückgegeben. - Wenn die Zielressource
All Instances
lautet,Study
Series
werden auch Attribute der Ebene zurückgegeben. - Wenn die Zielressource
Study's Instances
lautet,Series
werden auch Levelattribute zurückgegeben.
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, 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. |
503 (Service Unavailable) | Der Dienst ist nicht verfügbar oder beschäftigt. Versuchen Sie es später noch mal. |
Zusätzliche Hinweise
- Die Abfrage mit der
TimezoneOffsetFromUTC (00080201)
Verwendung wird nicht unterstützt. - Die Abfrage-API gibt nicht zurück
413 (request entity too large)
. Wenn der angeforderte Abfrageantwortlimit außerhalb des zulässigen Bereichs liegt, wird eine schlechte Anforderung zurückgegeben. Alles, was innerhalb des zulässigen Bereichs angefordert wird, wird aufgelöst. - Wenn die Zielressource "Study/Series" ist, gibt es ein Potenzial für inkonsistente Metadaten auf Studien-/Serienebene in mehreren Instanzen. Beispielsweise könnten zwei Instanzen unterschiedlichen PatientName haben. In diesem Fall gewinnt das neueste, und Sie können nur auf den neuesten Daten suchen.
- Seitenergebnisse werden optimiert, um zuerst übereinstimmende Instanz zurückzugeben, dies kann zu doppelten Datensätzen auf nachfolgenden Seiten führen, wenn neuere Daten, die der Abfrage entsprechen, hinzugefügt wurden.
- Die Übereinstimmung ist groß- und akzentfrei für PN-VR-Typen.
- Die Übereinstimmung ist Groß-/Kleinschreibung und Akzent vertraulich für andere Zeichenfolgen-VR-Typen.
- Nur der erste Wert wird von einem einzelnen wertigen Datenelement indiziert, das falsch über mehrere Werte verfügt.
Löschen
Diese Transaktion ist nicht Teil des offiziellen DICOMweb™ Standard. 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 Datenreihe in einer Studie. |
Delete | .. /studies/{study}/series/{series}/instances/{instance} | Löschen einer bestimmten Instanz in einer Reihe. |
Parameter , , series
und instance
entsprechen den DICOM-Attributen StudyInstanceUID
study
, SeriesInstanceUID
und SopInstanceUID
entsprechend.
Es gibt keine Einschränkungen für die Kopfzeile, Content-Type
Kopf- oder Textkörperinhalte der AnforderungAccept
.
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 wurde schlecht formatiert. |
401 (Unauthorized) | Der Client wird 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. |
503 (Service Unavailable) | Der Dienst ist nicht verfügbar oder beschäftigt. Versuchen Sie es später noch mal. |
Antwortlast 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 Worklist-Diensts (UPS-RS). Dieser Dienst bietet Zugriff auf eine Arbeitsliste mit Arbeitselementen, die jeweils einen Unified Procedure Step (UPS) darstellen.
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} | 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 | Arbeitselement abbrechen |
POST | {s}/workitems/{instance}/abonnenten/{AETitle}{?deletelock} | Erstellen des Abonnements |
POST | {s}/workitems/1.2.840.10008.5.1.4.34.5/ | Abonnement anhalten |
Delete | {s}/workitems/{instance}/abonnenten/{AETitle} | Löschen eines Abonnements |
GET | {s}/abonnenten/{AETitle} | Kanal "Abonnement öffnen" |
Erstellen von Arbeitselement
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 Nutzlastdatensatz das Workitem im SOPInstanceUID
Attribut enthalten.
Content-Type
Die Und Kopfzeilen Accept
sind in der Anforderung erforderlich und müssen beide über den Wert application/dicom+json
verfügen.
Es gibt eine Reihe von Anforderungen im Zusammenhang mit DICOM-Datenattributen im Kontext einer bestimmten Transaktion. Attribute sind möglicherweise erforderlich, um vorhanden zu sein, erforderlich, nicht vorhanden, erforderlich, leer zu sein oder nicht leer zu sein. Diese Anforderungen finden Sie in dieser Tabelle.
Hinweise zu Datasetattributen:
- SOP-Instanz-UID: Obwohl die obige Referenztabelle besagt, dass DIE SOP-Instanz-UID nicht vorhanden sein sollte, ist diese Anleitung speziell für das DIMSE-Protokoll und wird in DICOMWeb™ anders behandelt. DIE SOP-Instanz-UID sollte im Dataset vorhanden sein, wenn nicht im URI.
- Bedingte Anforderungscodes: Alle bedingten Anforderungscodes einschließlich 1C und 2C werden 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 die oben genannten Anforderungen nicht. |
401 (Unauthorized) | Der Client wird nicht authentifiziert. |
403 (Forbidden) | Der Benutzer ist nicht autorisiert. |
409 (Conflict) | Das Workitem ist bereits vorhanden. |
415 (Unsupported Media Type) | Die bereitgestellte Content-Type Version wird nicht unterstützt. |
503 (Service Unavailable) | Der Dienst ist nicht verfügbar oder beschäftigt. Versuchen Sie es später noch mal. |
Erstellen der Antwortlast
Eine Erfolgsantwort hat keine Nutzlast. Die Location
Kopfzeilen und Content-Location
Antwortheader enthalten einen URI-Verweis auf das erstellte Arbeitselement.
Eine Fehlerantwort-Nutzlast enthält eine Nachricht, die den Fehler beschreibt.
Stornierung anfordern
Diese Transaktion ermöglicht es dem Benutzer, eine Kündigung 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 festlegen 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 daher werden Abbruchanforderungen an Arbeitselemente zurückgegeben, 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 der Kündigung eines geplanten Arbeitselements |
Die Content-Type
Kopfzeile ist erforderlich und muss den Wert application/dicom+json
aufweisen.
Die Anforderungsnutzlast kann Aktionsinformationen enthalten, die im DICOM-Standard definiert sind.
Anforderungsstatuscodes für die Abbruchantwort
Code | BESCHREIBUNG |
---|---|
202 (Accepted) | Die Anforderung wurde vom Server akzeptiert, aber der Status "Target Workitem" wurde 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 inkonsistent mit dem aktuellen Zustand des Zielarbeitselements. Beispielsweise befindet sich das Zielarbeitselement im STATUS "GEPLANT" oder "ABGESCHLOSSEN" . |
415 (Unsupported Media Type) | Die bereitgestellte Content-Type Version wird nicht unterstützt. |
Anforderungs-Antwort-Nutzlast
Eine Erfolgsantwort hat keine Nutzlast, und eine Fehlerantwort-Nutzlast enthält eine Nachricht, 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 von Workitem
Diese Transaktion ruft ein Workitem ab. Es 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 Workitem auf dem Ursprungsserver vorhanden ist, wird das Workitem in einem zulässigen Medientyp zurückgegeben. Das zurückgegebene Workitem enthält nicht das Transaktions-UID -Attribut (0008.1195). Dies ist erforderlich, um die Rolle dieses Attributs als Zugriffssperre beizubehalten.
Methode | Pfad | BESCHREIBUNG |
---|---|---|
GET | .. /workitems/{workitem} | Anforderung zum Abrufen eines Arbeitselements |
Die Accept
Kopfzeile ist erforderlich und muss den Wert application/dicom+json
aufweisen.
Abrufen von Arbeitsitem-Antwortstatuscodes
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 Arbeitsitem-Antwort-Nutzlast
- Eine Erfolgsantwort verfügt über eine einzelne Teil-Nutzlast, die das angeforderte Arbeitselement im ausgewählten Medientyp enthält.
- Das zurückgegebene Workitem enthält nicht das Transaktions-UID -Attribut (0008, 1195) des Workitem, da das nur dem Besitzer bekannt sein sollte.
Aktualisieren von Arbeitsaufgaben
Diese Transaktion ändert Attribute eines vorhandenen Workitems. Es 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 derzeit im ZEITPLANzustand zu aktualisieren, ist das Transaction UID
Attribut nicht vorhanden. Für ein Workitem im IN PROGRESS-Zustand muss die Anforderung die aktuelle Transaktions-UID als Abfrageparameter enthalten. Wenn sich das Workitem bereits in den Status "ABGESCHLOSSEN " oder " ABGEBROCHEN" befindet, lautet 400 (Bad Request)
die Antwort .
Methode | Pfad | BESCHREIBUNG |
---|---|---|
POST | .. /workitems/{workitem}? {transaktions-uid} | Workitem-Transaktion aktualisieren |
Die Content-Type
Kopfzeile ist erforderlich und muss den Wert application/dicom+json
aufweisen.
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 Elemente, die geändert werden sollen. Wenn mehrere Attribute als Gruppe aktualisiert werden müssen, führen Sie dies als mehrere Attribute in einer einzelnen Anforderung aus, nicht als mehrere Anforderungen.
Es gibt eine Reihe von Anforderungen im Zusammenhang mit DICOM-Datenattributen im Kontext einer bestimmten Transaktion. Attribute sind möglicherweise erforderlich, um vorhanden zu sein, erforderlich, nicht vorhanden, erforderlich, leer zu sein oder nicht leer zu sein. Diese Anforderungen finden Sie in dieser Tabelle.
Hinweise zu Datasetattributen:
Bedingte Anforderungscodes: Alle bedingten Anforderungscodes einschließlich 1C und 2C werden optional behandelt.
Die Anforderung kann den Wert des Prozedurschrittstatus (0074.1000)-Attributs nicht festlegen. Der Prozedurschrittstatus wird mithilfe der Änderungsstatus-Transaktion oder der Anforderungsabbruch-Transaktion verwaltet.
Aktualisieren der Statuscodes der Workitem-Transaktionsantwort
Code | BESCHREIBUNG |
---|---|
200 (OK) | Das Zielarbeitselement wurde aktualisiert. |
400 (Bad Request) | Es gab ein Problem mit der Anforderung. Beispiel: (1) das Zielarbeitselement war im COMPLETED oder CANCELED Zustand. (2) Die Transaktions-UID fehlt. (3) Die Transaktions-UID ist falsch. (4) Das Dataset hat die Anforderungen nicht erfüllt. |
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 inkonsistent mit dem aktuellen Status des Zielarbeitselements. |
415 (Unsupported Media Type) | Die bereitgestellte Version Content-Type wird nicht unterstützt. |
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 Fehlerantwortnutzlast kann einen Statusbericht enthalten, der Fehler, Warnungen oder andere nützliche Informationen beschreibt.
Workitem-Status ändern
Diese Transaktion wird verwendet, um den Status eines Workitem-Objekts zu ändern. Er entspricht dem UPS DIMSE N-ACTION-Vorgang "Change UPS State". Statusänderungen werden verwendet, um den Besitz, die Fertigstellung oder das Abbrechen eines Workitem-Objekts anzufordern.
Weitere Informationen finden Sie unter: https://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_11.7
Wenn das Workitem auf dem Ursprungsserver vorhanden ist, wird das Workitem in einem akzeptablen Medientyp zurückgegeben. Das zurückgegebene Workitem darf das Attribut "Transaction UID(0008.1195)" nicht enthalten. Dies ist erforderlich, um die Rolle dieses Attributs als Zugriffssperre beizubehalten, wie hier beschrieben.
Methode | Pfad | BESCHREIBUNG |
---|---|---|
PUT | .. /workitems/{workitem}/state | Workitem-Status ändern |
Der Accept
Header ist erforderlich und muss den Wert application/dicom+json
haben.
Die Anforderungsnutzlast enthält die Change UPS State Data Elements. Diese Datenelemente sind:
- Transaktions-UID (0008, 1195) Die Anforderungsnutzlast enthält eine Transaktions-UID. Der Benutzer-Agent erstellt die Transaktions-UID beim Anfordern eines Übergangs zum
IN PROGRESS
Status für ein bestimmtes Workitem. Der Benutzer-Agent stellt die Transaktions-UID in nachfolgenden Transaktionen mit diesem Workitem bereit. - Prozedurschrittstatus (0074, 1000) Die gesetzlichen Werte entsprechen dem angeforderten Zustandsübergang. Sie sind:
IN PROGRESS
,COMPLETED
, oderCANCELED
.
Ändern der Statuscodes des Workitem-Status
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 ist nicht authentifiziert. |
403 (Forbidden) | Der Benutzer ist nicht autorisiert. |
404 (Not Found) | Das Zielarbeitselement wurde nicht gefunden. |
409 (Conflict) | Die Anforderung ist inkonsistent mit dem aktuellen Status des Zielarbeitselements. |
Change Workitem State Response Payload
- Antworten enthalten die Kopfzeilenfelder, die in Abschnitt 11.7.3.2 angegeben sind.
- Eine Erfolgsantwort hat keine Nutzlast.
- Eine Fehlerantwortnutzlast 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? | Suchen nach Workitems |
Die folgenden Accept
Kopfzeilen 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 nach Attribut-/Wertabgleich in der Abfrage. | ||
includefield= | {attributeID} all | 0...N | Die zusätzlichen Attribute, die in der Antwort zurückgegeben werden sollen. Nur Attribute auf oberster Ebene können angegeben werden, um eingeschlossen zu werden – nicht Attribute, die Teil von Sequenzen sind. Sowohl öffentliche als auch private Tags werden unterstützt. Wann all angegeben wird, finden Sie unter "Suchantwort" , um weitere Informationen zu den Attributen für jeden Abfragetyp zu erhalten. 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 einzuschränken. Der Wert kann zwischen dem Bereich 1 >= x <= 200 liegen. Standardmäßig auf 100 . | ||
offset= | {value} | 0...1 | {value}-Ergebnisse überspringen. 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 dem Personennamen (PN) Value Representation (VR) angewendet wird. Es führt eine Präfixwortgleichung eines beliebigen Namensteils innerhalb dieser Attribute aus. Wenn PatientName John^Doe es sich beispielsweise um , dann joh do , jo do , Doe und John Doe alle Übereinstimmungen handelt. Wird jedoch ohn nicht übereinstimmen. |
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 übereinstimmenden Typen:
Suchtyp | Unterstütztes Attribut | Beispiel |
---|---|---|
Bereichsabfrage | ScheduledProcedureStepStartDateTime | {attributeID}={value1}-{value2} . Für Datums-/Uhrzeitwerte unterstützen wir einen inklusiven Bereich im Tag. Dies wird dem attributeID >= {value1} AND attributeID <= {value2} zugeordnet. Wenn {value1} nicht angegeben wird, werden alle Vorkommen von Datumsangaben/Uhrzeiten vor und einschließlich {value2} übereinstimmen. Auch wenn {value2} nicht angegeben wird, werden alle Vorkommen von {value1} und nachfolgenden Datums-/Uhrzeiten übereinstimmen. Eine 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, der mit dem Wert beginnt. |
Hinweis
Während der vollständige Sequenzabgleich nicht unterstützt wird, unterstützen wir die genaue Übereinstimmung auf den oben aufgeführten Attributen, die in einer Sequenz enthalten sind.
Attribut-ID
Tags können auf mehrere Arten für den Abfrageparameter codiert werden. Wir haben den Standard teilweise implementiert, wie in PS3.18 6.7.1.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 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 wurden
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 Antwortlast 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) | Dies war ein Problem mit der Anforderung. Beispielsweise ungültige Abfrageparametersyntax. Der 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 beschäftigt. Versuchen Sie es später noch mal. |
Weitere Hinweise
Die Abfrage-API wird nicht zurückgegeben 413 (request entity too large)
. Wenn der angeforderte Abfrageantwortlimit außerhalb des zulässigen Bereichs liegt, wird eine schlechte Anforderung zurückgegeben. Alles, was innerhalb des zulässigen Bereichs angefordert wird, wird aufgelöst.
- Seitenergebnisse werden optimiert, um zuerst übereinstimmende Instanz zurückzugeben, dies kann zu doppelten Datensätzen auf nachfolgenden Seiten führen, wenn neuere Daten, die der Abfrage entsprechen, hinzugefügt wurden.
- Die Übereinstimmung ist groß- und akzentlos für PN VR-Typen.
- Die Übereinstimmung ist groß- und akzentempfindlich für andere Zeichenfolgen-VR-Typen.
- Wenn es ein Szenario gibt, in dem das Abbrechen eines Arbeitselements und die Abfrage gleichzeitig geschieht, wird die Abfrage wahrscheinlich das Arbeitselement ausschließen, das aktualisiert wird, und der Antwortcode wird
206 (Partial Content)
angezeigt.
Nächste Schritte
Weitere Informationen finden Sie unter
Übersicht über den DICOM-Dienst