- 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:
StudyInstanceUIDSeriesInstanceUIDSOPInstanceUIDSOPClassUIDPatientID
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, SeriesInstanceUIDund .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, 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 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.1multipart/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.1wird als Standard verwendet)multipart/related; type="application/dicom"(wenn die Transfersyntax nicht angegeben wird,1.2.840.10008.1.2.1wird als Standard verwendet)application/dicom; transfer-syntax=1.2.840.10008.1.2.1multipart/related; type="application/dicom"; transfer-syntax=1.2.840.10008.1.2.1application/dicom; transfer-syntax=1.2.840.10008.1.2.4.90multipart/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.1wird als Standard verwendet)multipart/related; type="application/octet-stream"; transfer-syntax=1.2.840.10008.1.2.1multipart/related; type="image/jp2";(wenn die Transfersyntax nicht angegeben wird,1.2.840.10008.1.2.4.90wird 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=alldie 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.
IncludeFieldAttribute, die auf dieser Ressourcenebene unterstützt werden.- Wenn die Zielressource
All Serieslautet,Studywerden auch Levelattribute zurückgegeben. - Wenn die Zielressource
All Instanceslautet,StudySerieswerden auch Attribute der Ebene zurückgegeben. - Wenn die Zielressource
Study's Instanceslautet,Serieswerden 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 , , seriesund instance entsprechen den DICOM-Attributen StudyInstanceUIDstudy, SeriesInstanceUIDund 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+jsonverfü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:
SCHEDULEDIN PROGRESSCANCELEDCOMPLETED
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+jsonaufweisen.
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+jsonaufweisen.
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+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 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+jsonhaben.
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 PROGRESSStatus 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 <= 200liegen. 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 PatientNameJohn^Doees sich beispielsweise um , dann johdo, jo do, Doe und John Doe alle Übereinstimmungen handelt. Wird jedoch ohnnicht ü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
FAQs
What is Azure DICOM service? ›
The DICOM service is a managed service within Azure Health Data Services that ingests and persists DICOM objects at multiple thousands of images per second.
What is medical imaging server for DICOM Azure? ›The Medical Imaging Server for DICOM is an open source DICOM server that is easily deployed on Azure. It allows standards-based communication with any DICOMweb™ enabled systems, and injects DICOM metadata into a FHIR server to create a holistic view of patient data.
What is Azure Health Data Services? ›Azure Health Data Services is a suite of purpose-built technologies for protected health information (PHI) in the cloud. It's built on the global open standards Fast Healthcare Interoperability Resources (FHIR)® and Digital Imaging Communications in Medicine (DICOM).
What is DICOM compliance? ›DICOM is a message standard (i.e., a specification for interchange of information between computer systems). DICOM is a comprehensive specification of information content, structure, encoding, and communications protocols for electronic interchange of diagnostic and therapeutic images and image-related information.
What is DICOM used for in healthcare? ›Digital Imaging and Communications in Medicine (DICOM) is a clinical messaging syntax used to exchange medical images between medical equipment and information systems.
Is DICOM Hipaa compliant? ›Dicom Systems Unifier platform can de-identify DICOM, XML, TIFF, JPEG, PDF, and other image formats complying with HIPPA safe harbor de-identification of Protected Health Information (PHI) requirements.
What information is required when configuring a DICOM server? ›IP-number (or host name) of the computer on which the DICOM server is running, Port number on which the server is listening, Application Entity Title (AET) which has been given to the server.
How is DICOM used with medical images? ›The DICOM standard is concerned with five main functions in medical imaging: to transmit and persist images and related data between endpoints; to query and retrieve files; to perform specific actions like printing or archiving; to support digital imaging workflows; and to provide high quality images for diagnostics.
What is the difference between Azure monitor and Azure service health? ›Azure Monitor helps you understand how your applications are performing and proactively identifies issues affecting them and the resources they depend on. Azure Service Health helps you stay informed and take action when Azure service issues like outages and planned maintenance affect you.
What are the two types of health data? ›Types. Health data are classified as either structured or unstructured.
What are the 4 major categories of data found in health organizations? ›
Claims data falls into four general categories: inpatient, outpatient, pharmacy, and enrollment.
Which database maintains files in DICOM? ›Oracle Multimedia DICOM extends Oracle Database reliability, availability, and data management to media objects in medical applications. Oracle Multimedia DICOM supports Digital Imaging and Communications in Medicine (DICOM), the standard for medical images.
What are the disadvantages of using DICOM? ›Implementing a DICOM Header Can be Difficult
Out of which some are optional and mandatory to use. The scanner vendors might find this difficult to choose the tags in the DICOM header. However, some pathologists find this as a major disadvantage because it contains the patient's information and other details.
The current version of DICOM is called DICOM version 3.0. Typically, updated versions of the DICOM standard are published every other year.
What are the 2 components of DICOM? ›Two fundamental components of DICOM, described in detail in Chapter 47, are information object class and service class. The information objects define the contents of a set of images and their relationship (e.g., patients, modalities, studies).
How often are DICOM standards updated? ›With updates typically occurring every two to three months, the DICOM Standard is one of the most rapidly evolving standards in the world.
How do I view DICOM medical imaging data? ›DICOM files are images that come digitally from medical scans, such as MRIs and ultrasounds. You can view these files with a free online viewer called Jack Image viewer on any computer. If you'd prefer an app, you can download MicroDicom (PC only) or open the files in Adobe Photoshop (PC and Mac).
Is Azure database HIPAA compliant? ›Azure has enabled the physical, technical, and administrative safeguards required by HIPAA and the HITECH Act inside the in-scope Azure services, and offers a HIPAA BAA as part of the Microsoft Product Terms (formerly Online Services Terms) to all customers who are covered entities or business associates under HIPAA ...
Can DICOM be encrypted? ›Encryption is one way to keep these data confidential. DICOM does not specify the encryption in detail (it refers to other Standards for that), but several the DICOM Standard can facilitate encryption, including the transfer of encrypted DICOM objects, and reading of encrypted DICOM objects on the receiver's end.
What scanning apps are HIPAA compliant? ›What's nice about iFax is you get to scan and fax documents using only one app. It's also HIPAA-compliant and uses military-grade encryption, making it one of today's most secure apps for scanning and faxing documents online. iFax works on iOS and Android.
What port is used for DICOM? ›
Port 104 is the standard port for DICOM communications, and you may want to use this unless the supplier of your remote DICOM node tells you otherwise. Note, however, that you may need Administrator access (root permission) to use port 104.
How are images stored in DICOM? ›A DICOM file consists of a header and image data sets packed into a single file. The information within the header is organized as a constant and standardized series of tags. By extracting data from these tags one can access important information regarding the patient demographics, study parameters, etc.
How do I set up a DICOM server? ›- Open the side menu by tapping the 3 horizontal lines in the top left corner and select Settings.
- Scroll down and select DICOM Server Settings.
- Tap the plus + icon to add a new server and enter the appropriate information.
- Select Save when finished.
- Tap C-ECHO to test the connection to the server.
The main advantage with DICOM is that it is a standard. Using a standard for file format and communication allows the pathology department to connect scanners and PACS from different vendors and replace them without incompatibility problems.
What is the main advantage of DICOM data format? ›Waveforms are DICOM objects that can be managed along with images. Consequently, DICOM provides a standard way to archive and transfer audio files along with the images. Waveforms can be referenced from within a report in the same way an image is referenced.
Why is the DICOM format most suitable for medical images? ›DICOM formatting ensures that all of the metadata associated with the file stays intact. It is the primary reason why this format is preferred when transferring and storing medical imaging between devices supporting DICOM.
What is DICOM and why is it important? ›DICOM® — Digital Imaging and Communications in Medicine — is the international standard for medical images and related information. It defines the formats for medical images that can be exchanged with the data and quality necessary for clinical use.
What is azure information protection scanner? ›Azure Information Protection unified labeling scanner overview. The AIP scanner can inspect any files that Windows can index. If you've configured sensitivity labels to apply automatic classification, the scanner can label discovered files to apply that classification, and optionally apply or remove protection.
What is the difference between DICOM and PACS? ›The difference between PACS and DICOM is that PACS is a medical image storage and archive hub, fed by medical modalities such as X-ray scanners and MRI machines, while DICOM represents the international communication standard – not a device or structure – used by healthcare professionals in storing, processing, ...
What is azure monitor used for? ›Azure Monitor is a comprehensive monitoring solution for collecting, analyzing, and responding to telemetry from your cloud and on-premises environments. You can use Azure Monitor to maximize the availability and performance of your applications and services.
Does Azure have a vulnerability scanner? ›
The integrated vulnerability assessment solution supports both Azure virtual machines and hybrid machines. To deploy the vulnerability assessment scanner to your on-premises and multicloud machines, connect them to Azure first with Azure Arc as described in Connect your non-Azure machines to Defender for Cloud.
What are the prerequisites for the Azure Information Protection scanner? ›You must have a service account to run the scanner service on the Windows Server computer, as well as authenticate to Azure AD and download the Azure Information Protection Policy. Your service account must be an Active Directory account and synchronized to Azure AD.
How do I use Azure information protection scanner? ›Sign in to the Azure portal as a supported administrator, and navigate to the Azure Information Protection pane. In the Scanner menu on the left, and select Content scan jobs, and then select your content scan job.
What are the disadvantages of DICOM? ›What are the disadvantages of using DICOM? One disadvantage is the number of optional fields that it allows. There are more than 2000 attributes that can be added to a DICOM file. This increases the possibility of errors if data is inconsistently entered or is incomplete or inaccurate.
How does PACS and DICOM work together? ›PACS use digital imaging and communications in medicine (DICOM) to store and transmit images. DICOM is both a protocol for transmitting images and a file format for storing them. Medical imaging devices communicate with the application server through the DICOM protocol.
How do I send DICOM files to PACS? ›You can send images to PACS either from the main viewer window or from your local database. To send images from the viewer, click the arrow next to the Export button, select Send to PACS . You can send All opened studies , the Current study or only the Current series .