DICOM Conformance-Anweisung v1

  • Artikel

Hinweis

API Version 2 ist die neueste API-Version und sollte anstelle von v1 verwendet werden. Ausführliche Informationen finden Sie in der DICOM-Konformitätserklärung v2 .

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

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

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

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

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

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

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

Präambelbereinigung

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

Studienservice

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

Store (STOW-RS)

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

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

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

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 erzwingt keine Attribute, die mit vorhandenen Daten für POST-Anforderungen in Konflikt geraten. Alle Daten werden wie bereitgestellt gespeichert. Bei Upsert-Anforderungen (PUT) werden die vorhandenen Daten durch die neuen empfangenen Daten ersetzt.

Erforderliche Attribute speichern

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

  • StudyInstanceUID
  • SeriesInstanceUID
  • SOPInstanceUID
  • SOPClassUID
  • PatientID

Hinweis

Alle UIDs müssen zwischen 1 und 64 Zeichen lang sein und nur alphanumerische Zeichen oder die folgenden Sonderzeichen enthalten: ., -. PatientID wird basierend auf dem LOVR Typ überprüft.

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

Es werden nur Syntaxen mit expliziten Wertdarstellungen akzeptiert.

Store-Antwortstatuscodes

Code Beschreibung
200 (OK) Alle SOP-Instanzen in der Anforderung werden gespeichert.
202 (Accepted) Einige Instanzen in der Anforderung werden 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 Untersuchungsinstanzbezeichner entspricht beispielsweise nicht dem erwarteten UID-Format.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
406 (Not Acceptable) Die angegebene Accept Kopfzeile wird nicht unterstützt.
409 (Conflict) Keine der Instanzen in der Speichertransaktionsanforderung wurde gespeichert.
415 (Unsupported Media Type) Die bereitgestellte Version Content-Type wird nicht unterstützt.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Speicherantwortnutzlast

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

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

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

Tag Name Beschreibung
(0008, 1150) ReferencedSOPClassUID Der eindeutige SOP-Klassenbezeichner der Instanz, die nicht gespeichert werden konnte.
(0008, 1155) ReferencedSOPInstanceUID Der eindeutige SOP-Instanzbezeichner der Instanz, die nicht gespeichert werden konnte.
(0008, 1197) FailureReason Der Grundcode, warum diese Instanz nicht gespeichert werden konnte.
(0074, 1048) FailedAttributesSequence Die Sequenz davon ErrorComment enthält den Grund für jedes fehlgeschlagene Attribut.

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

Tag Name Beschreibung
(0008, 1150) ReferencedSOPClassUID Der eindeutige SOP-Klassenbezeichner der 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 für den Store

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

Store-Warnungsursachencodes

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

Speicherfehlercodes

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

Abrufen (WADO-RS)

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

Methode Pfad Beschreibung
GET .. /studies/{study} Ruft alle Instanzen innerhalb einer Studie ab.
GET .. /studies/{study}/metadata Ruft die Metadaten für alle Instanzen innerhalb einer Studie ab.
GET .. /studies/{study}/series/{series} Ruft alle Instanzen innerhalb einer Datenreihe ab.
GET .. /studies/{study}/series/{series}/metadata Ruft die Metadaten für alle Instanzen innerhalb einer Datenreihe ab.
GET .. /studies/{study}/series/{series}/instances/{instance} Ruft eine einzelne Instanz ab.
GET .. /studies/{study}/series/{series}/instances/{instance}/metadata Ruft die Metadaten für eine einzelne Instanz ab.
GET .. /studies/{study}/series/{series}/instances/{instance}/rendern Ruft eine Instanz ab, die in einem Bildformat gerendert wird.
GET .. /studies/{study}/series/{series}/instances/{instance}/frames/{frames} Ruft einen oder mehrere Frames aus einer einzelnen Instanz ab. Wenn Sie mehrere Frames angeben möchten, verwenden Sie ein Komma, um die einzelnen Frames zu trennen. Beispiel: /studies/1/series/2/instance/3/frames/4,5,6.
GET .. /studies/{study}/series/{series}/instances/{instance}/frames/{frame}/rendern Ruft einen einzelnen Frame ab, der in einem Bildformat gerendert wird.

Abrufen von Instanzen innerhalb einer Studie oder Datenreihe

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

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

Abrufen einer Instanz

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

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

Frames abrufen

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

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

Abrufen der Übertragungssyntax

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

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

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

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

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

  • application/dicom+json

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

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

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

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

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

Abrufen gerenderter Bilder (z. B. Frame)

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

  • image/jpeg
  • image/png

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

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

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

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

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. Inhalt wird dem Antworttext in diesem Fall nicht hinzugefügt. Weitere Informationen finden Sie im abschnitt "Abrufen der Metadatencacheüberprüfung" (für Studie, Datenreihe oder Instanz).
400 (Bad Request) Die Anforderung wurde schlecht formatiert. Der angegebene Untersuchungsinstanzbezeichner stimmte beispielsweise nicht mit dem erwarteten UID-Format überein, oder die angeforderte Transfersyntaxcodierung wird nicht unterstützt.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Die angegebene DICOM-Ressource konnte nicht gefunden werden, oder für gerenderte Anforderung enthielt die Instanz keine Pixeldaten.
406 (Not Acceptable) Der angegebene Accept Header wird nicht unterstützt, oder für gerenderte und transcodierte Anforderungen war die angeforderte Datei zu groß.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Suche (QIDO-RS)

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

Methode Pfad Beschreibung
Nach Studien suchen
GET .. /Studien?... Suchen nach Studien
Nach Datenreihen suchen
GET .. /Serie?... Nach Datenreihen suchen
GET .. /studies/{study}/series?... Suchen nach Reihen in einer Studie
Suchen nach Instanzen
GET .. /Instanzen?... Nach Instanzen suchen
GET .. /studies/{study}/instances?... Suchen nach Beispielen 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 in der Abfrage nach Attribut-/Wertabgleich.
includefield= {attributeID}
all		 0...N Die anderen Attribute, die in der Antwort zurückgegeben werden sollen. Sowohl öffentliche als auch private Tags werden unterstützt.
Wenn all angegeben, lesen Sie die Suchantwort , um weitere Informationen darüber zu erhalten, welche Attribute für jeden Abfragetyp zurückgegeben werden.
Wenn eine Mischung aus {attributeID} und all bereitgestellt wird, verwendet der Server standardmäßig all.
limit= {value} 0..1 Ganzzahliger Wert, um die Anzahl der in der Antwort zurückgegebenen Werte zu begrenzen.
Der Wert kann zwischen dem Bereich 1 >= x <= 200 liegen. Standardmäßig auf 100 festgelegt.
offset= {value} 0..1 Ergebnisse überspringen {value} .
Wenn ein Offset größer als die Anzahl der Suchergebnisse bereitgestellt wird, wird eine Antwort von 204 (keine Inhalte) zurückgegeben.
fuzzymatching= true / false 0..1 Wenn true fuzzy matching auf das PatientName-Attribut angewendet wird. Es führt eine Präfixwort-Übereinstimmung eines beliebigen Namensteils innerhalb des PatientName-Werts durch. Wenn "PatientName" beispielsweise "John^Doe" lautet, dann "joh", "do", "jo do", "Doe" und "John Doe" alle übereinstimmen. "ohn" stimmt jedoch nicht überein.

Durchsuchbare Attribute

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

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

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 ist zugeordnet attributeID >= {value1} AND attributeID <= {value2}. Wenn {value1} nicht angegeben, werden alle Vorkommen von Datums- und Uhrzeitangaben vor und einschließlich {value2} übereinstimmen. Ebenso werden, wenn {value2} nicht angegeben, alle Vorkommen und {value1} nachfolgende Datums-/Uhrzeiten übereinstimmen. Einer dieser Werte muss jedoch vorhanden sein. {attributeID}={value1}- und {attributeID}=-{value2} sind gültig, {attributeID}=- ist jedoch ungültig.
Genaue Übereinstimmung Alle unterstützten Attribute {attributeID}={value1}
Fuzzy Match PatientName, ReferringPhysicianName Entspricht einer beliebigen Komponente des Namens, die mit dem Wert beginnt.

Attribut-ID

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

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

Beispielabfragesuche für Instanzen:

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

Suchantwort

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

Standard-Studientags

Tag Attributname
(0008, 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

Andere Reihentags

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

Die folgenden Attribute werden zurückgegeben:

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

Suchantwortcodes

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

Code Beschreibung
200 (OK) Die Antwortnutzlast enthält alle übereinstimmenden Ressourcen.
204 (No Content) Die Suche wurde erfolgreich abgeschlossen, aber keine Ergebnisse zurückgegeben.
400 (Bad Request) Der Server konnte die Abfrage nicht ausführen, da die Abfragekomponente ungültig war. Der Antworttext enthält Details des Fehlers.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Sonstige Hinweise

  • Abfragen mithilfe der TimezoneOffsetFromUTC (00080201) Abfrage werden nicht unterstützt.
  • Die Abfrage-API gibt nicht zurück 413 (request entity too large). Wenn der angeforderte Abfrageantwortgrenzwert außerhalb des zulässigen Bereichs liegt, wird eine ungültige Anforderung zurückgegeben. Alles, was innerhalb des zulässigen Bereichs angefordert wird, wird aufgelöst.
  • Wenn die Zielressource "Studie/Serie" ist, gibt es ein Potenzial für inkonsistente Metadaten auf Studien-/Reihenebene über mehrere Instanzen hinweg. Beispielsweise könnten zwei Instanzen unterschiedliche PatientName haben. In diesem Fall gewinnen die neuesten Gewinne, und Sie können nur nach den neuesten Daten suchen.
  • Seitenergebnisse sind so optimiert, dass zuerst übereinstimmungsgleiche Instanzen zurückgegeben werden. Dies kann zu doppelten Datensätzen auf nachfolgenden Seiten führen, wenn neuere Daten hinzugefügt wurden, die der Abfrage entsprechen.
  • Beim Abgleich wird die Groß-/Kleinschreibung beachtet, und bei PN VR-Typen wird die Groß-/Kleinschreibung nicht beachtet.
  • Beim Abgleich wird die Groß-/Kleinschreibung beachtet, und bei anderen Zeichenfolgen-VR-Typen wird die Groß-/Kleinschreibung beachtet.
  • Nur der erste Wert wird von einem einzelnen wertigen Datenelement indiziert, das falsch mehrere Werte aufweist.

Löschen

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

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

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

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

Hinweis

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

Antwortstatuscodes

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

Antwortnutzlast löschen

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

Worklist Service (UPS-RS)

Der DICOM-Dienst unterstützt die Push- und Pull-SOPs des Arbeitslistendiensts (UPS-RS). Der Worklist-Dienst bietet Zugriff auf eine Arbeitsliste, die Workitems enthält, 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
NACHRICHT {s}/workitems{? BetroffeneSOPInstanceUID} Erstellen eines Arbeitselements
NACHRICHT {s}/workitems/{instance}{?transaction} Ein Arbeitselement aktualisieren
GET {s}/workitems{?query*} Suchen nach Arbeitselementen
GET {s}/workitems/{instance} Abrufen einer Arbeitsaufgabe
PUT {s}/workitems/{instance}/state Ändern des Arbeitsaufgabenstatus
NACHRICHT {s}/workitems/{instance}/cancelrequest Arbeitsaufgabe abbrechen
NACHRICHT {s}/workitems/{instance}/subscribers/{AETitle}{?deletionlock} Abonnement erstellen
NACHRICHT {s}/workitems/1.2.840.10008.5.1.4.34.5/ Abonnement aussetzen
DELETE {s}/workitems/{instance}/subscribers/{AETitle} Löschen eines Abonnements
GET {s}/abonnenten/{AETitle} Öffnen des Abonnementkanals

Arbeitselement erstellen

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

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

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

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

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

Hinweis

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

Hinweis

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

Erstellen von Antwortstatuscodes

Code Beschreibung
201 (Created) Das Zielarbeitselement wurde erfolgreich erstellt.
400 (Bad Request) Es gab ein Problem mit der Anforderung. Die Anforderungsnutzlast erfüllte beispielsweise nicht die Anforderungen.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
409 (Conflict) Das Arbeitselement ist bereits vorhanden.
415 (Unsupported Media Type) Die bereitgestellte Version Content-Type wird nicht unterstützt.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Erstellen der Antwortnutzlast

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

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

Absage anfordern

Mit dieser Transaktion kann der Benutzer den Abbruch eines nicht zugeordneten Workitem anfordern.

Es gibt vier gültige Workitem-Status:

  • SCHEDULED
  • IN PROGRESS
  • CANCELED
  • COMPLETED

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

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

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

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

Statuscodes für anforderungsabbruchsantwort

Code Beschreibung
202 (Accepted) Die Anforderung wurde vom Server akzeptiert, der Status "Target Workitem" ist jedoch unverändert.
400 (Bad Request) Es gab ein Problem mit der Syntax der Anforderung.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Das Zielarbeitselement wurde nicht gefunden.
409 (Conflict) Die Anforderung ist mit dem aktuellen Status des Zielarbeitselements inkonsistent. Beispielsweise befindet sich das Zielarbeitselement im SCHEDULED Oder COMPLETED Zustand.
415 (Unsupported Media Type) Die bereitgestellte Version Content-Type wird nicht unterstützt.

Anforderungsabbruchantwortnutzlast

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

Arbeitselement abrufen

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

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

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

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

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

Abrufen von Antwortstatuscodes für Arbeitselemente

Code Beschreibung
200 (OK) Die Workitem-Instanz wurde erfolgreich abgerufen.
400 (Ungültige Anforderung) Es gab ein Problem mit der Anforderung.
401 (Nicht autorisiert) Der Client ist nicht authentifiziert.
403 (Unzulässig) Der Benutzer ist nicht autorisiert.
404 (Nicht gefunden) Das Zielarbeitselement wurde nicht gefunden.

Abrufen der Arbeitselementantwortnutzlast

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

Workitem aktualisieren

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

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

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

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

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

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

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

Hinweis

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

Hinweis

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

Aktualisieren der Statuscodes für die Transaktionsantwort von Workitem

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

Workitem-Transaktionsantwortnutzlast aktualisieren

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

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

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

Arbeitselementstatus ändern

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

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

Wenn das Arbeitselement auf dem Ursprungsserver vorhanden ist, wird das Arbeitselement in einem akzeptablen Medientyp zurückgegeben. Das zurückgegebene Workitem-Objekt 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 Arbeitselementstatus ändern

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

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

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

Ändern der Antwortstatuscodes des Workitem-Zustands

Code Beschreibung
200 (OK) Die Workitem-Instanz wurde erfolgreich abgerufen.
400 (Bad Request) Die Anforderung kann aus einem der folgenden Gründe nicht ausgeführt werden: (1) Die Anforderung ist aufgrund des aktuellen Status des Zielarbeitselements ungültig. (2) Die Transaktions-UID fehlt. (3) Die Transaktions-UID ist falsch.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
404 (Not Found) Das Zielarbeitselement wurde nicht gefunden.
409 (Conflict) Die Anforderung ist mit dem aktuellen Status des Zielarbeitselements inkonsistent.

Change Workitem state response payload

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

Sucharbeitselemente

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

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

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

Suchtyp Unterstütztes Attribut Beispiel
Bereichsabfrage Scheduled​Procedure​Step​Start​Date​Time {attributeID}={value1}-{value2}. Für Datums-/Uhrzeitwerte unterstützen wir einen inklusiven Bereich auf dem Tag. Dies ist zugeordnet attributeID >= {value1} AND attributeID <= {value2}. Wenn {value1} nicht angegeben, werden alle Vorkommen von Datums- und Uhrzeitangaben vor und einschließlich {value2} übereinstimmen. Ebenso werden, wenn {value2} nicht angegeben, alle Vorkommen und {value1} nachfolgende Datums-/Uhrzeiten übereinstimmen. Einer dieser Werte muss jedoch vorhanden sein. {attributeID}={value1}- und {attributeID}=-{value2} sind gültig, {attributeID}=- ist jedoch ungültig.
Genaue Übereinstimmung Alle unterstützten Attribute {attributeID}={value1}
Fuzzy Match PatientName Entspricht einer beliebigen Komponente des Namens, die mit dem Wert beginnt.

Hinweis

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

Attribut-ID

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

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

Beispielabfrage:

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

Suchantwort

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

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

Suchantwortcodes

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

Code Beschreibung
200 (OK) Die Antwortnutzlast enthält alle übereinstimmenden Ressourcen.
206 (Partial Content) Die Antwortnutzlast enthält nur einige der Suchergebnisse, und der Rest kann über die entsprechende Anforderung angefordert werden.
204 (No Content) Die Suche wurde erfolgreich abgeschlossen, aber keine Ergebnisse zurückgegeben.
400 (Bad Request) Es gab ein Problem mit der Anforderung. Beispiel: Ungültige Abfrageparametersyntax. Der Antworttext enthält Details des Fehlers.
401 (Unauthorized) Der Client ist nicht authentifiziert.
403 (Forbidden) Der Benutzer ist nicht autorisiert.
503 (Service Unavailable) Der Dienst ist nicht verfügbar oder ausgelastet. Versuchen Sie es später noch einmal.

Weitere Notizen

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

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

Hinweis

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