DICOM Conformance-Anweisung für Azure Health Data Services (2023)

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

MethodePfadBESCHREIBUNG
POST.. /StudienSpeichern von Instanzen.
POST.. /studies/{study}Speichern Sie Instanzen für eine bestimmte Studie.

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

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

  • application/dicom+json

Die folgenden Content-Type Kopfzeilen werden unterstützt:

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

Hinweis

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

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

  • StudyInstanceUID
  • SeriesInstanceUID
  • SOPInstanceUID
  • SOPClassUID
  • PatientID

Hinweis

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

Jede gespeicherte Datei muss eine eindeutige Kombination aus StudyInstanceUID, 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

CodeBESCHREIBUNG
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:

TagNameBESCHREIBUNG
(0008, 1190)RetrieveURLDie Abrufen-URL der Studie, wenn die StudyInstanceUID in der Speicheranforderung bereitgestellt wurde und mindestens eine Instanz erfolgreich gespeichert wird.
(0008, 1198)FailedSOPSequenceDie Reihenfolge der Instanzen, die nicht gespeichert werden konnten.
(0008, 1199)ReferencedSOPSequenceDie 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):

TagNameBESCHREIBUNG
(0008, 1150)ReferencedSOPClassUIDDer eindeutige SOP-Klassenbezeichner der Instanz, die nicht gespeichert werden konnte.
(0008, 1155)ReferencedSOPInstanceUIDDer eindeutige SOP-Instanzbezeichner der Instanz, die nicht gespeichert werden konnte.
(0008, 1197)FailureReasonDer Grundcode, warum diese Instanz nicht gespeichert werden konnte.

Jedes Dataset in der ReferencedSOPSequence Datei enthält die folgenden Elemente:

TagNameBESCHREIBUNG
(0008, 1150)ReferencedSOPClassUIDDer eindeutige SOP-Klassenbezeichner der Instanz, die nicht gespeichert werden konnte.
(0008, 1155)ReferencedSOPInstanceUIDDer eindeutige SOP-Instanzbezeichner der Instanz, die nicht gespeichert werden konnte.
(0008, 1190)RetrieveURLDie 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

CodeBESCHREIBUNG
272Die Speichertransaktion hat die Instanz aufgrund eines allgemeinen Fehlers bei der Verarbeitung des Vorgangs nicht gespeichert.
43264Die DICOM-Instanz hat die Überprüfung fehlgeschlagen.
43265Die angegebene Instanz StudyInstanceUID entspricht nicht der angegebenen StudyInstanceUID Speicheranforderung.
45070Eine DICOM-Instanz mit demselben StudyInstanceUID, SeriesInstanceUIDund SopInstanceUID wurde bereits gespeichert. Wenn Sie den Inhalt aktualisieren möchten, löschen Sie diese Instanz zuerst.
45071Eine 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.

MethodePfadBESCHREIBUNG
GET.. /studies/{study}Ruft alle Instanzen innerhalb einer Studie ab.
GET.. /studies/{study}/metadataRuft 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}/metadataRuft 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}/metadataRuft die Metadaten für eine einzelne Instanz ab.
GET.. /studies/{study}/series/{series}/instances/{instance}/frames/{frames}Ruft ein oder mehrere Frames aus einer einzelnen Instanz ab. Verwenden Sie zum Angeben mehrerer Frames ein Komma, um jeden Frame zu trennen. Beispiel: /studies/1/series/2/instance/3/frames/4,5,6

Abrufen von Instanzen innerhalb einer Studie oder Datenreihe

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

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

Abrufen einer Instanz

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

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

Frames abrufen

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

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

Abrufen der Übertragungssyntax

Wenn sich die angeforderte Übertragungssyntax von der ursprünglichen Datei unterscheidet, wird die ursprüngliche Datei in die angeforderte Übertragungssyntax transcodiert. Die originale Datei muss eines der folgenden Formate sein, um die Transcodierung erfolgreich auszuführen; andernfalls schlägt die Transcodierung möglicherweise fehl:

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

Eine nicht unterstützte transfer-syntax Datei führt zu 406 Not Acceptable.

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

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

  • application/dicom+json

Das Abrufen von Metadaten gibt keine Attribute mit den folgenden Wertdarstellungen zurück:

VR-NameBESCHREIBUNG
OBAnderes Byte
OdWeiteres Double
OFAnderer Float
OlAndere Lange
OvAndere 64-Bit-Sehr lange
OwAnderes Wort
UNUnbekannt

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

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

MethodePfadBESCHREIBUNG
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üsselSupport-Wert(n)Zulässige AnzahlBESCHREIBUNG
{attributeID}={value}0...NSuchen Sie nach Attribut-/Wertabgleich in der Abfrage.
includefield={attributeID}
all
0...NDie 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..1Ganzzahliger 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..1Ergebnisse überspringen {value} .
Wenn ein Offset größer als die Anzahl der Suchergebnisse ist, wird eine Antwort von 204 (keine Inhalte) zurückgegeben.
fuzzymatching=true / false0..1Wenn 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üsselwortStudieReihenInstanz
StudyInstanceUIDXXX
PatientNameXXX
PatientIDXXX
PatientBirthDateXXX
AccessionNumberXXX
ReferringPhysicianNameXXX
StudyDateXXX
StudyDescriptionXXX
SeriesInstanceUIDXX
ModalityXX
PerformedProcedureStepStartDateXX
SOPInstanceUIDX

Suchabgleich

Wir unterstützen die folgenden übereinstimmenden Typen.

SuchtypUnterstütztes AttributBeispiel
BereichsabfrageStudyDate/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 ÜbereinstimmungAlle unterstützten Attribute{attributeID}={value1}
Fuzzy MatchPatientName, ReferringPhysicianNameEntspricht 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:

WertBeispiel
{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

TagAttributname
(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

TagAttributname
(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

TagAttributname
(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

TagAttributname
(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

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

Zusammen mit diesen folgenden Attributen werden zurückgegeben:

  • Alle Übereinstimmungsabfrageparameter und UIDs in der Ressourcen-URL.
  • IncludeField Attribute, die auf dieser Ressourcenebene unterstützt werden.
  • Wenn die Zielressource All Serieslautet, Study werden auch Levelattribute zurückgegeben.
  • Wenn die Zielressource All Instanceslautet, StudySeries werden auch Attribute der Ebene zurückgegeben.
  • Wenn die Zielressource Study's Instanceslautet, Series werden auch Levelattribute zurückgegeben.

Suchantwortcodes

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

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

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

Antwortstatuscodes

CodeBESCHREIBUNG
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:

VerbPfadBESCHREIBUNG
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}/cancelrequestArbeitselement 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.

MethodePfadBESCHREIBUNG
POST.. /workitemsErstellen 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

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

Erstellen der Antwortlast

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

Eine Fehlerantwort-Nutzlast enthält eine Nachricht, die den Fehler beschreibt.

Stornierung anfordern

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

Es gibt vier gültige Workitem-Status:

  • SCHEDULED
  • IN PROGRESS
  • CANCELED
  • COMPLETED

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

MethodePfadBESCHREIBUNG
POST.. /workitems/{workitem}/cancelrequestAnfordern 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

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

MethodePfadBESCHREIBUNG
GET.. /workitems/{workitem}Anforderung zum Abrufen eines Arbeitselements

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

Abrufen von Arbeitsitem-Antwortstatuscodes

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

MethodePfadBESCHREIBUNG
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

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

MethodePfadBESCHREIBUNG
PUT.. /workitems/{workitem}/stateWorkitem-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 PROGRESS Status für ein bestimmtes Workitem. Der Benutzer-Agent stellt die Transaktions-UID in nachfolgenden Transaktionen mit diesem Workitem bereit.
  • Prozedurschrittstatus (0074, 1000) Die gesetzlichen Werte entsprechen dem angeforderten Zustandsübergang. Sie sind: IN PROGRESS, COMPLETED, oder CANCELED.

Ändern der Statuscodes des Workitem-Status

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

MethodePfadBESCHREIBUNG
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üsselSupportWerteZulässigAnzahlBESCHREIBUNG
{attributeID}={value}0...NSuchen Sie nach Attribut-/Wertabgleich in der Abfrage.
includefield={attributeID} all0...NDie 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...1Ganzzahliger 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/false0...1Wenn 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:

SuchtypUnterstütztes AttributBeispiel
BereichsabfrageScheduled​Procedure​Step​Start​Date​Time{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 ÜbereinstimmungAlle unterstützten Attribute{attributeID}={value1}
Fuzzy MatchPatientNameEntspricht 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:

WertBeispiel
{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:

CodeBESCHREIBUNG
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 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 Azure API for FHIR? ›

Azure API for FHIR is a managed, standards-based, compliant API for clinical health data that enables solutions for actionable analytics and machine learning.

What is Microsoft cloud for healthcare? ›

Microsoft Cloud for Healthcare brings together trusted capabilities to customers and partners that enhance patient engagement, empower health team collaboration, and improve clinical and operational data insights to improve decision-making and operational efficiencies.

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.

What are the 5 basic DICOM file movement operations? ›

DICOM addresses five general application areas: (1) network image management, (2) network image interpretation management, (3) network print management, (4) imaging procedure management, (5) off-line storage media management.

What are the two types of data in healthcare? ›

Types. Health data are classified as either structured or unstructured. Structured health data is standardized and easily transferable between health information systems.

What are the 3 important services offered by Azure? ›

This gives users the flexibility to use their preferred tools and technologies. In addition, Azure offers four different forms of cloud computing: infrastructure as a service (IaaS), platform as a service (PaaS), software as a service (SaaS) and serverless functions.

What are the 4 major categories of data found in health organizations? ›

Claims data falls into four general categories: inpatient, outpatient, pharmacy, and enrollment.

What are the 3 types of APIs? ›

Today, there are three categories of API protocols or architectures: REST, RPC and SOAP. These might be dubbed "formats," each with unique characteristics and tradeoffs and employed for different purposes. REST.

What is the difference between an API and FHIR? ›

EHR APIs are primarily designed to answer specific questions that cover common workflows or data exchange requests in the clinical setting, while FHIR is clearly developed around resources.

Is FHIR a REST API? ›

The FHIR RESTful API

FHIR uses REST as the basis for data exchange in its API. Health care data types such as medications, observations, and patients are represented by their own Resources.

What is DICOM stand for? ›

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.

Why do we need DICOM? ›

DICOM is most commonly used for storing and transmitting medical images enabling the integration of medical imaging devices such as scanners, servers, workstations, printers, network hardware, and picture archiving and communication systems (PACS) from multiple manufacturers.

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

Is DICOM a server? ›

The DICOM server software acts as a filing system to store all images in an organized manner. Images from the DICOM server can either be sent to the digital workstation for interpretation or can be printed. Some advanced DICOM server software applications also allow direct uploading and online sharing of images.

Top Articles
Latest Posts
Article information

Author: Nathanael Baumbach

Last Updated: 02/14/2023

Views: 5932

Rating: 4.4 / 5 (55 voted)

Reviews: 86% of readers found this page helpful

Author information

Name: Nathanael Baumbach

Birthday: 1998-12-02

Address: Apt. 829 751 Glover View, West Orlando, IN 22436

Phone: +901025288581

Job: Internal IT Coordinator

Hobby: Gunsmithing, Motor sports, Flying, Skiing, Hooping, Lego building, Ice skating

Introduction: My name is Nathanael Baumbach, I am a fantastic, nice, victorious, brave, healthy, cute, glorious person who loves writing and wants to share my knowledge and understanding with you.