You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The [DICOM® service](overview.md) automatically uploads DICOM files to Azure Data Lake Storage when using STOW-RS. This way, users can query their data either using DICOMweb™ APIs, like WADO-RS, or Azure Blob/Data Lake APIs. However, with storage indexing DICOM files will be automatically indexed by the DICOM service after uploading the data directly to the ADLS Gen 2 file system. Whether the files were uploaded using STOW-RS, an Azure Blob SDK, or even `AzCopy`, they can be accessed using either DICOMweb™ APIs or directly through the ADLS Gen 2 file system.
15
15
@@ -26,10 +26,6 @@ The DICOM service indexes an ADLS Gen 2 file system by reacting to Blob or Data
26
26
27
27
First, create an [Azure Storage Queue](../../storage/queues/storage-queues-introduction.md) in the same Azure Storage Account connected to the DICOM service The DICOM service will also need access to the queue; it will need to be able to dequeue messages as well as enqueue its own messages for errors and complex tasks. So, make sure the same managed identity used by the DICOM service, either user-assigned or system-assigned, has the [**Storage Queue Data Contributor**](../../storage/queues/assign-azure-role-data-access.md) role assigned.
28
28
29
-
#### [Azure Portal](#tab/queue-portal)
30
-
31
-
#### [ARM](#tab/queue-arm)
32
-
33
29
### Publish Storage Events to the Queue
34
30
35
31
With the Storage Queue in place, events must be published from the Storage Account to an Azure Event Grid System Topic and routed to queue using an Azure Event Grid Subscription. Before creating the event subscription, be sure to grant the role **Storage Queue Data Message Sender** to the event subscription so that it is authorized to send messages. The event subscription can either use a user-assigned or system-assigned managed identity from the system topic to authenticate its operations.
@@ -38,7 +34,7 @@ By default, event subscriptions send all of the subscribed event types to their
38
34
- The message must be a Base64 `CloudEvent`
39
35
- The event type must be `Microsoft.Storage.BlobCreated` or `Microsoft.Storage.BlobDeleted`
40
36
- The file system must be the same one configured for the DICOM service
41
-
- The file path must be within `AHDS/<workspace-name>/dicom/<dicom-service-name>`
37
+
- The file path must be within `AHDS/<workspace-name>/dicom/<dicom-service-name>[/<partition-name>]`
42
38
- The file must be a DICOM file as defined in Part 10 of the DICOM standard
43
39
- The operation must not have been performed by the DICOM service itself
44
40
@@ -47,61 +43,274 @@ Thankfully, the event subscription can be configured to filter out irrelevant da
47
43
- Optionally, the subject ends with `.dcm`
48
44
- Under advanced filters, the key `data.clientRequestId` does not begin with `tag:<workspace-name>-<dicom-service-name>.dicom.azurehealthcareapis.com,`
49
45
50
-
#### [Azure Portal](#tab/events-portal)
51
-
52
-
#### [ARM](#tab/events-arm)
53
-
54
-
1. Use the Azure CLI command [`az deployment group create`](../../azure-resource-manager/bicep/deploy-cli.md) to deploy a system topic and event subscription like below:
55
-
56
46
### Enable Storage Indexing
57
47
58
-
Once the event grid subscription has been successfully configured, it's time to let the DICOM service know from where to read the storage events.
48
+
Once the event grid subscription has been successfully configured, it's time to let the DICOM service know from where to read the storage events. Storage indexing is available starting in version `2025-04-01-preview` for Azure Resource Manager (ARM) which introduced a new property `storageConfiguration.storageIndexingConfiguration.storageEventQueueName`. It is currently unavailable to configure via the Azure Portal.
59
49
60
-
#### [ARM](#tab/dicom-arm)
61
-
62
-
Storage indexing is available starting in the preview ARM version `2025-04-01-preview` which introduced a new property within `storageConfiguration` called `storageIndexingConfiguration.storageEventQueueName`. Deploy, or redeploy, a DICOM service using this new property with the Azure CLI command [`az deployment group create`](../../azure-resource-manager/bicep/deploy-cli.md):
50
+
The example ARM template below can be deployed using the Azure CLI command [`az deployment group create`](../../azure-resource-manager/bicep/deploy-cli.md). It includes all of the necessary resources for a DICOM service:
@@ -111,7 +320,7 @@ Storage indexing is available starting in the preview ARM version `2025-04-01-pr
111
320
112
321
If there is an error when processing an event, the problematic event will be enqueued in a "poison queue" called `<queue-name>-poison` in the same Storage Account. Details about every processed event can be found in the `AHDSDicomAuditLogs` and `AHDSDicomDiagnosticLogs` tables by filtering for all logs where `OperationName = 'index-storage'`. The audit logs will only record when the operation started and completed whereas the diagnostic table will provide details about each operation including any errors, if any. Operations may be correlated across the tables using `CorrelationId`.
113
322
114
-
Failures are divided into two types: `User` and `Server`. User errors include
323
+
Failures are divided into two types: `User` and `Server`. User errors include any problem connecting to the storage account or with the DICOM file itself, while server errors include any unexpected error that prevents processing. Unlike server errors, user errors are not retried by the DICOM service.
115
324
116
325
## Next Steps
117
326
*[Interact with data using DICOMweb™](dicomweb-standard-apis-with-dicom-services.md)
0 commit comments